Samsung AC gaat telkens "offline"

[paQ]

Ik heb twee Samsung AC's in huis, nu 4.5 jaar oud.
1 gaat telkens "offline".

Hij staat ten tijden van het offline zijn wel gewoon in mijn netwerkapparaten alszijnde verbonden, met ook uitstekende verbinding wifi-technisch.

Ik heb de logboeken van de router eens gewist en het proberen bij te houden op momenten dat ie offline gaat en weer terugkomt. In het algemene logboek komt ie niet voor. (Alleen bij een herstart van router of AC)

Bij "Systeemlogboek - Actieve verbindingen" zie ik hem verschijnen als:
tcp 192.168.108.176:39629 52.212.142.35:443 ESTABLISHED
udp 192.168.108.176:49153 8.8.8.8:53 UNREPLIED

En bij offline is de status CLOSED (tcp denk ik)

Ja. Mooi Maar waarom closed?

in het DHCP lease lisjtje:
Samsung-Room-AC 192.168.108.176 8 [MAC] 23:58:11

Zo te zien dus ook een nieuwe lease gekregen.
Hoe zoek ik vanaf hier verder naar de oorzaak?

edit:
Nu weer "offline"
tcp 192.168.108.176:39633 34.243.120.20:443 CLOSE
PING OK

En kort daarna weer:
tcp 192.168.108.176:39634 52.49.85.161:443 ESTABLISHED

[ Voor 19% gewijzigd door paQ op 25-08-2025 08:55 ]

[Ben(V)]

ALs je hem wel kunt pingen is er niets met je netwerk aan de hand en zit het in die Samsung zelf.
Maar wat is je probleem als hij offline is?
Wat kun je dan niet meer?

TCP sessies worden over het algemeen na een time out (tijdje geen data) gesloten dat is niks vreemd.

[MasterL]

Tja, 1 is gewoon een DNS request naar Google DNS (8.8.8.8) en de TCP verbinding is waarschijnlijk een HTTPS (tunnel) naar een (Samsung) server voor het gebruik van een IOT app ofzo.
Closed is niet raar zeker niet bij dit soort setups, er is zoiets als (TCP) lifetime waarbij na een tijd van inactiviteit een connectie gesloten wordt door een firewall. Dit is ook de reden waarom er keepalives bestaan die om de 30 sec bijvoorbeeld een pakket sturen om de verbinding open te houden.

Ik ga er even voor het gemak vanuit dat er geen WAF/proxy ofzo in gebruik is?
Begin eens met simpele troubleshooting
ping -t 192.168.108.176 -t >> AC.txt en laat dit eens twee uur lopen

Dit kun je ook doen voor je andere AC (op hetzelfde moment?) en zo kijken of het gedrag tussen de twee anders is.

[paQ]

Ben(V) schreef op maandag 25 augustus 2025 @ 09:10:
ALs je hem wel kunt pingen is er niets met je netwerk aan de hand en zit het in die Samsung zelf.
Maar wat is je probleem als hij offline is?
Wat kun je dan niet meer?

TCP sessies worden over het algemeen na een time out (tijdje geen data) gesloten dat is niks vreemd.

Bij offline niet meer te bedienen en mijn 3D HA dashboard geeft dan een draaiende cirkel (zoeken) Dat is gewoon irritant. Het stomme is dat de andere AC dit probleem niet of iig veel minder vaak vertoont. Dus ik ga haast de wifi module van de AC zelf verdenken.

Aan de DHCP leases te zien vernieuwt ie zowat elke 3 min zijn lease.

[MasterL]

Daarom kun je een ping laten lopen om de resultaten te vergelijken als er veel (meer) ICMP drops zijn als op de andere AC weet je wel dat er iets mis is met Wifi, bereik of module.
DHCP request/response om de 3 min is natuurlijk apart tenzij je DHCP lease time op 3 min staat.

[Ben(V)]

ALs de dhcp lease van je dhcp server correct staat (controleer dat) dan is de netwerkcontroller van die Samsung defect want hij verliest blijkbaar zijn IP adres.

[paQ]

MasterL schreef op maandag 25 augustus 2025 @ 09:23:
Daarom kun je een ping laten lopen om de resultaten te vergelijken als er veel (meer) ICMP drops zijn als op de andere AC weet je wel dat er iets mis is met Wifi, bereik of module.
DHCP request/response om de 3 min is natuurlijk apart tenzij je DHCP lease time op 3 min staat.

Ik laat hem elke 30 sec pingen, en dan is er niets aan de hand, ook niet op de momenten dat hij "offline" is.
Er komt netjes respons.
Hij heeft via DHCP een gekoppeld IP adres, zoals al jaren het geval is.

Ik heb geen idee waarom hij elke 3 min een nieuwe lease krijgt. Zijn broertje (175) doet dat niet
* 192.168.108.175 22:52:28
Samsung-Room-AC 192.168.108.176 23:57:34

30 sec later:
* 192.168.108.175 22:51:45
Samsung-Room-AC 192.168.108.176 23:59:52

[paQ]

dit zijn de pings van online naar offline gaan en zijn.
2025-08-25 09:46:11
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: icmp_seq=0 ttl=255 time=20,142 ms
--- 192.168.108.176 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 20,142/20,142/20,142/0,000 ms
PING OK
----
2025-08-25 09:46:41
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: icmp_seq=0 ttl=255 time=84,829 ms
--- 192.168.108.176 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 84,829/84,829/84,829/0,000 ms
PING OK
----
2025-08-25 09:47:11
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: icmp_seq=0 ttl=255 time=21,399 ms
--- 192.168.108.176 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 21,399/21,399/21,399/0,000 ms
PING OK
----
2025-08-25 09:47:41
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: icmp_seq=0 ttl=255 time=40,233 ms
--- 192.168.108.176 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 40,233/40,233/40,233/0,000 ms
PING OK
----
2025-08-25 09:48:12
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: icmp_seq=0 ttl=255 time=49,210 ms
--- 192.168.108.176 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 49,210/49,210/49,210/0,000 ms
PING OK
----

En nog eens van Online > Offline > online:

2025-08-25 09:52:44 PING 192.168.108.176 (192.168.108.176): 56 data bytes
2025-08-25 09:52:44 64 bytes from 192.168.108.176: icmp_seq=0 ttl=255 time=59,163 ms
2025-08-25 09:52:54 64 bytes from 192.168.108.176: icmp_seq=1 ttl=255 time=92,710 ms
2025-08-25 09:53:04 64 bytes from 192.168.108.176: icmp_seq=2 ttl=255 time=19,535 ms
2025-08-25 09:53:14 64 bytes from 192.168.108.176: icmp_seq=3 ttl=255 time=51,910 ms
2025-08-25 09:53:24 64 bytes from 192.168.108.176: icmp_seq=4 ttl=255 time=81,029 ms
2025-08-25 09:53:34 64 bytes from 192.168.108.176: icmp_seq=5 ttl=255 time=112,733 ms
2025-08-25 09:53:44 64 bytes from 192.168.108.176: icmp_seq=6 ttl=255 time=39,283 ms
2025-08-25 09:53:54 64 bytes from 192.168.108.176: icmp_seq=7 ttl=255 time=73,710 ms
2025-08-25 09:54:04 64 bytes from 192.168.108.176: icmp_seq=8 ttl=255 time=118,129 ms
2025-08-25 09:54:14 64 bytes from 192.168.108.176: icmp_seq=9 ttl=255 time=37,773 ms
2025-08-25 09:54:24 64 bytes from 192.168.108.176: icmp_seq=10 ttl=255 time=69,305 ms
2025-08-25 09:54:34 64 bytes from 192.168.108.176: icmp_seq=11 ttl=255 time=102,154 ms
2025-08-25 09:54:44 64 bytes from 192.168.108.176: icmp_seq=12 ttl=255 time=33,277 ms
2025-08-25 09:54:54 64 bytes from 192.168.108.176: icmp_seq=13 ttl=255 time=61,648 ms
2025-08-25 09:55:04 64 bytes from 192.168.108.176: icmp_seq=14 ttl=255 time=91,649 ms
2025-08-25 09:55:14 64 bytes from 192.168.108.176: icmp_seq=15 ttl=255 time=23,272 ms
2025-08-25 09:55:24 64 bytes from 192.168.108.176: icmp_seq=16 ttl=255 time=21,441 ms
2025-08-25 09:55:34 64 bytes from 192.168.108.176: icmp_seq=17 ttl=255 time=56,129 ms
2025-08-25 09:55:44 64 bytes from 192.168.108.176: icmp_seq=18 ttl=255 time=19,621 ms
2025-08-25 09:55:54 64 bytes from 192.168.108.176: icmp_seq=19 ttl=255 time=51,362 ms
2025-08-25 09:56:04 64 bytes from 192.168.108.176: icmp_seq=20 ttl=255 time=80,479 ms
2025-08-25 09:56:14 64 bytes from 192.168.108.176: icmp_seq=21 ttl=255 time=247,038 ms
2025-08-25 09:56:24 64 bytes from 192.168.108.176: icmp_seq=22 ttl=255 time=41,816 ms
2025-08-25 09:56:34 64 bytes from 192.168.108.176: icmp_seq=23 ttl=255 time=77,144 ms
2025-08-25 09:56:44 64 bytes from 192.168.108.176: icmp_seq=24 ttl=255 time=209,071 ms
2025-08-25 09:56:54 64 bytes from 192.168.108.176: icmp_seq=25 ttl=255 time=37,384 ms
2025-08-25 09:57:04 64 bytes from 192.168.108.176: icmp_seq=26 ttl=255 time=71,593 ms

Lijkt meer een issue met de cloudconnectie. (?)

[ Voor 42% gewijzigd door paQ op 25-08-2025 09:58 ]

[Ben(V)]

Als je om de 3 seconden een dhcp request van dat ding krijgt dat staat of je leasetijd heel laag of dat ding denkt dat zijn leasetijd verlopen is.

Normaal gesproken zal een device pas een dhcp request sturen als de helft van de leasetijd verlopen is.

[MasterL]

@Ben(V) of het bereik is gewoon zo slecht dat de link regelmatig wegvalt en een nieuw DHCP request triggert.
@paQ elke 30 sec is niet genoeg, dit is een moment opname. Laat dit nou eens continu lopen voor een uur:
1: Naar de AC met het probleem.
2: Naar de AC zonder het probleem.
Dit natuurlijk vanaf een bedraad apparaat.

Ik vind je responses ook belachelijk hoog voor een intern netwerk als ik de statistieken erbij pak van mijn AC's (4) komt de hoogste in de afgelopen drie uur niet boven de 40 uit maar dit is normaliter 1-5.
Of je bereik/interferentie is slecht of je module in je AC is stuk maar dit kan je alleen uitsluiten door systematisch te vergelijken en hiermee bedoel ik niet een ping van 10 sec laten lopen.

[Ben(V)]

Een dhcp request wordt niet getriggerd door een connectie die je kwijt raakt, enkel door opstarten of een verlopen leasetijd.
Wat wel kan, is dat hij gewoon werkt tot de halve leasetijd verlopen is en dan dhcp requests gaat sturen waarvan het antwoordt niet aankomt door de slechte wifi connectie en daarom blijft proberen.
Na een tijd houd hij daarmee op en gaat offline.
TS heeft nog steeds geen antwoordt gegeven op de vraag hoe de leasetijd van de dhcp server ingesteld staat.

Die hoge ping tijden zijn in ieder geval niet normaal en duiden op een slecht wifi bereik.

[ Voor 7% gewijzigd door Ben(V) op 25-08-2025 12:41 ]

[paQ]

De kwaliteit van de connectie durf ik eigenlijk wel uit te sluiten.
De afstand tot de (XT12) node is ca 3m vrij in zicht.
De leasetijd staat op 86400 seconden.
Zijn AC broertje hangt twee wifi nodes verderop, en die geeft geen enkele DHCP lease issue.

Bij de renew van de lease faalt de ping


ter referentie via de wireless backhaul naar de router:
PING 192.168.108.1 (192.168.108.1): 56 data bytes
64 bytes from 192.168.108.1: icmp_seq=0 ttl=64 time=5,781 ms
64 bytes from 192.168.108.1: icmp_seq=1 ttl=64 time=2,923 ms
64 bytes from 192.168.108.1: icmp_seq=2 ttl=64 time=2,066 ms
64 bytes from 192.168.108.1: icmp_seq=3 ttl=64 time=3,337 ms
64 bytes from 192.168.108.1: icmp_seq=4 ttl=64 time=4,653 ms
64 bytes from 192.168.108.1: icmp_seq=5 ttl=64 time=4,974 ms
64 bytes from 192.168.108.1: icmp_seq=6 ttl=64 time=2,419 ms
64 bytes from 192.168.108.1: icmp_seq=7 ttl=64 time=4,871 ms
64 bytes from 192.168.108.1: icmp_seq=8 ttl=64 time=3,694 ms
64 bytes from 192.168.108.1: icmp_seq=9 ttl=64 time=4,388 ms
64 bytes from 192.168.108.1: icmp_seq=10 ttl=64 time=3,969 ms
64 bytes from 192.168.108.1: icmp_seq=11 ttl=64 time=4,088 ms
64 bytes from 192.168.108.1: icmp_seq=12 ttl=64 time=2,769 ms
64 bytes from 192.168.108.1: icmp_seq=13 ttl=64 time=2,654 ms
64 bytes from 192.168.108.1: icmp_seq=14 ttl=64 time=2,805 ms
64 bytes from 192.168.108.1: icmp_seq=15 ttl=64 time=2,435 ms
64 bytes from 192.168.108.1: icmp_seq=16 ttl=64 time=2,427 ms

[ Voor 50% gewijzigd door paQ op 25-08-2025 12:52 ]

[MasterL]

Ben(V) schreef op maandag 25 augustus 2025 @ 12:37:
Een dhcp request wordt niet getriggerd door een connectie die je kwijt raakt, enkel door opstarten of een

Dit hangt natuurlijk compleet af van de implementatie van de DHCP client.
Ik heb het niet over een paar missed ICMP responses maar over een loss of link, daarom mijn vraag geef nou eens een output over een langere tijd. Deze komt er niet dus ik ben bij deze ook wel een beetje klaar met dit topic.

De informatie is echt veel te schaars:
Ping naar: 192.168.108.176 (is welke unit)
Ping naar: 192.168.108.175 (is welke unit)
Ping naar: 192.168.108.1 (is welke unit)

Pingen vanuit welke locatie? Hoe is deze aangesloten? Wat is de "route"?

[paQ]

MasterL schreef op maandag 25 augustus 2025 @ 13:21:
[...]

Dit hangt natuurlijk compleet af van de implementatie van de DHCP client.
Ik heb het niet over een paar missed ICMP responses maar over een loss of link, daarom mijn vraag geef nou eens een output over een langere tijd. Deze komt er niet dus ik ben bij deze ook wel een beetje klaar met dit topic.

De informatie is echt veel te schaars:
Ping naar: 192.168.108.176 (is welke unit)
Ping naar: 192.168.108.175 (is welke unit)
Ping naar: 192.168.108.1 (is welke unit)

Pingen vanuit welke locatie? Hoe is deze aangesloten? Wat is de "route"?

Oh ik had juist de indruk dat ik al te veel informatie verstrekte

Ik zal hem eens een uurtje laten pingen en in een txt bestandje stoppen, maar heb er net 15 min naar zitten kijken, en ik zie alleen af en toe de FAIL regel. Rond het moment dat de DHCP lease hernieuwt. Verder geen bijzonderheden.

176 is de probleem AC; 175 is eenzelfde AC op een andere plek. (geen issues met die laatste)
1 is de router (Xt12) die via een dedicated 5GHz backhaul de nodes draadloos verbindt.
De computer vanaf waar ik ping is bedraad met zo'n (wireless) node verbonden

[Ben(V)]

MasterL schreef op maandag 25 augustus 2025 @ 13:21:
[...]

Dit hangt natuurlijk compleet af van de implementatie van de DHCP client.

Nee dat is hoe dhcp is gedefinieerd en dus niet implementatie afhankelijk.
Alle dhcp clients moeten zo werken om aan de standaard te voldoen en dat doen ze ook.
De achtergrond daarvan is dat bij een netwerk hikup de boel gewoon blijft werken en het netwerk niet overloaded wordt door dhcp requests wat broadcasts zijn.
Een bedrijfsnetwerk zou volkomen plat kunnen gaat door zo'n broadcast storm.

[paQ]

Als ik alleen de ping naar *.176 laat lopen, krijg ik geen fails of losses.
Wel zie ik elke 3 min (bij lease renew) dat er een regel of 4 missen (sneaky basterd)

2025-08-25 13:31:47 | 64 bytes from 192.168.108.176: icmp_seq=255 ttl=255 time=87,462 ms
2025-08-25 13:31:48 | 64 bytes from 192.168.108.176: icmp_seq=256 ttl=255 time=216,839 ms
2025-08-25 13:31:49 | 64 bytes from 192.168.108.176: icmp_seq=257 ttl=255 time=110,739 ms
2025-08-25 13:31:50 | 64 bytes from 192.168.108.176: icmp_seq=258 ttl=255 time=27,934 ms
2025-08-25 13:31:55 | 64 bytes from 192.168.108.176: icmp_seq=263 ttl=255 time=128,824 ms
2025-08-25 13:31:56 | 64 bytes from 192.168.108.176: icmp_seq=264 ttl=255 time=209,341 ms
2025-08-25 13:31:57 | 64 bytes from 192.168.108.176: icmp_seq=265 ttl=255 time=275,447 ms


2025-08-25 13:34:47 | 64 bytes from 192.168.108.176: icmp_seq=434 ttl=255 time=49,257 ms
2025-08-25 13:34:48 | 64 bytes from 192.168.108.176: icmp_seq=435 ttl=255 time=91,172 ms
2025-08-25 13:34:49 | 64 bytes from 192.168.108.176: icmp_seq=436 ttl=255 time=85,623 ms
2025-08-25 13:34:50 | 64 bytes from 192.168.108.176: icmp_seq=437 ttl=255 time=21,678 ms
2025-08-25 13:34:51 | 64 bytes from 192.168.108.176: icmp_seq=438 ttl=255 time=54,067 ms
2025-08-25 13:34:56 | 64 bytes from 192.168.108.176: icmp_seq=443 ttl=255 time=27,129 ms
2025-08-25 13:34:57 | 64 bytes from 192.168.108.176: icmp_seq=444 ttl=255 time=157,862 ms
2025-08-25 13:34:58 | 64 bytes from 192.168.108.176: icmp_seq=445 ttl=255 time=69,673 ms


2025-08-25 13:37:49 | 64 bytes from 192.168.108.176: icmp_seq=616 ttl=255 time=193,150 ms
2025-08-25 13:37:50 | 64 bytes from 192.168.108.176: icmp_seq=617 ttl=255 time=215,281 ms
2025-08-25 13:37:51 | 64 bytes from 192.168.108.176: icmp_seq=618 ttl=255 time=29,417 ms
2025-08-25 13:37:56 | 64 bytes from 192.168.108.176: icmp_seq=623 ttl=255 time=33,761 ms
2025-08-25 13:37:57 | 64 bytes from 192.168.108.176: icmp_seq=624 ttl=255 time=99,291 ms
2025-08-25 13:37:58 | 64 bytes from 192.168.108.176: icmp_seq=625 ttl=255 time=6,847 ms

[MasterL]

Ben(V) schreef op maandag 25 augustus 2025 @ 13:34:
[...]


Nee dat is hoe dhcp is gedefinieerd en dus niet implementatie afhankelijk.
Alle dhcp clients moeten zo werken om aan de standaard te voldoen en dat doen ze ook.
De achtergrond daarvan is dat bij een netwerk hikup de boel gewoon blijft werken en het netwerk niet overloaded wordt door dhcp requests wat broadcasts zijn.
Een bedrijfsnetwerk zou volkomen plat kunnen gaat door zo'n broadcast storm.

Ben ik heb geen zin in een uitgebreide discussie waarmee TS uiteindelijk niet geholpen is maar dit zijn mijn ervaringen. Mijn moeder heeft een omvormer op zolder hangen en 1 AP op de beneden verdieping. Houten huis, prima dekking op de begane grond en eerste verdieping maar.... Zolder is een dingentje.
Zie hier (Mikrotik router, Unifi AP, DHCP lease time 12H) heel simpel.



Dus.. Dit is een IRL ervaring dat wat jij beschrijft niet altijd opgaat hoewel dit wellicht wel zou moeten.
Ik lijk hetzelfde gedrag te bespeuren bij TS, vandaar mijn twijfels over de Wifi setup zoals in bovenstaand geval. Een broadcast storm is natuurlijk wel wat anders als in een loop maar dit gebeurt toch niet met 10 dhcp request per sec.

[ Voor 4% gewijzigd door MasterL op 25-08-2025 13:56 ]

[Ben(V)]

Eens, maar de ping blijft gewoon heel hoog dus denk ik toch echt een slecht wifi bereik.

[MasterL]

100% eens IMO slecht wifi bereik triggert TCP resets, DHCP request, timeouts etc.

[paQ]

sja ik weet niet zo goed wat ik daar op kan antwoorden


-52dBm

---

Ik heb SSH ingeschakeld op de router.
Pingen vanaf daar:

...@ZenWiFi_Pro_XT12-ABD0:/tmp/home/root# ping 192.168.108.176
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: seq=0 ttl=255 time=7.574 ms
64 bytes from 192.168.108.176: seq=1 ttl=255 time=10.403 ms
64 bytes from 192.168.108.176: seq=2 ttl=255 time=7.385 ms
64 bytes from 192.168.108.176: seq=3 ttl=255 time=9.535 ms
64 bytes from 192.168.108.176: seq=4 ttl=255 time=9.189 ms
64 bytes from 192.168.108.176: seq=5 ttl=255 time=8.162 ms
64 bytes from 192.168.108.176: seq=6 ttl=255 time=12.909 ms
64 bytes from 192.168.108.176: seq=7 ttl=255 time=9.893 ms
64 bytes from 192.168.108.176: seq=8 ttl=255 time=10.731 ms
64 bytes from 192.168.108.176: seq=9 ttl=255 time=9.596 ms
64 bytes from 192.168.108.176: seq=10 ttl=255 time=7.178 ms


edit:
en 10 min later...

@ZenWiFi_Pro_XT12-ABD0:/tmp/home/root# ping 192.168.108.176
PING 192.168.108.176 (192.168.108.176): 56 data bytes
64 bytes from 192.168.108.176: seq=0 ttl=255 time=9.855 ms
64 bytes from 192.168.108.176: seq=1 ttl=255 time=107.581 ms
64 bytes from 192.168.108.176: seq=2 ttl=255 time=27.612 ms
64 bytes from 192.168.108.176: seq=3 ttl=255 time=50.527 ms
64 bytes from 192.168.108.176: seq=4 ttl=255 time=75.439 ms
64 bytes from 192.168.108.176: seq=5 ttl=255 time=101.654 ms
64 bytes from 192.168.108.176: seq=6 ttl=255 time=123.216 ms
64 bytes from 192.168.108.176: seq=7 ttl=255 time=42.018 ms
64 bytes from 192.168.108.176: seq=8 ttl=255 time=69.202 ms
64 bytes from 192.168.108.176: seq=9 ttl=255 time=92.295 ms
64 bytes from 192.168.108.176: seq=10 ttl=255 time=124.919 ms
64 bytes from 192.168.108.176: seq=11 ttl=255 time=117.659 ms
64 bytes from 192.168.108.176: seq=12 ttl=255 time=86.572 ms
64 bytes from 192.168.108.176: seq=13 ttl=255 time=87.805 ms
64 bytes from 192.168.108.176: seq=14 ttl=255 time=180.970 ms
64 bytes from 192.168.108.176: seq=15 ttl=255 time=31.274 ms
64 bytes from 192.168.108.176: seq=16 ttl=255 time=56.119 ms
64 bytes from 192.168.108.176: seq=17 ttl=255 time=131.153 ms
64 bytes from 192.168.108.176: seq=18 ttl=255 time=220.298 ms
64 bytes from 192.168.108.176: seq=19 ttl=255 time=149.129 ms
64 bytes from 192.168.108.176: seq=20 ttl=255 time=213.768 ms
64 bytes from 192.168.108.176: seq=21 ttl=255 time=417.871 ms

[ Voor 90% gewijzigd door paQ op 25-08-2025 17:10 ]

[paQ]

Ik heb na alles 'intern' zoeken het opgegeven en het apparaat opnieuw aan Smartthings proberen toe te voegen. Dat mislukte 2 keer, waarna er best aparte instructies waren om de wifi geheel te resetten.
Opnieuw toegevoegd en dat ging gesmeerd.

Wellicht loop ik voor de muziek uit, maar hij is langer dan 3 min in zijn DHCP lease gebleven
Samsung-Room-AC 192.168.108.176 23:55:04

[paQ]

update: de boel is niet meer offline geweest.
I geef de AC de schuld

Zie voor en na de reset, zo 17:00: