Tradfri: Verbindungsabbruch (noch immer) - Lösungsansatz!

[bb61]

Ich hole den alten Faden mal vor, setze aber einen neuen Topic, nicht nur wg. der inzw. 2 vergangenen Jahre:

===========

also: in Anknüpfung an... (weil sicher auch dort lösungsgebend, zumindest in Teilen):
Re: Tradfri-Gateways verlieren die Verbindung

===========

Ich hatte auch schon vor 2 Jahren ähnliche Abbruch-Probleme, wie dort beschrieben, deshalb letztlich auch alle (damals 12) Tradfri-Schaltsteckdosen durch ein anderes System ersetzt. Aber ich konnte mir nicht leisten, ständig vom Tradfri-System selbstinitiierte Ausfälle zu haben bzw. sogar im gleichen Zusammenhang "unmotivierte" Abschaltungen der hinter den Steckdosen befindliche Anlagen zu bekommen. - Mit dem Alternativsystem (Shelly-Plug, damals nur 7 € teurer als das IKEA-Pendant) läuft es seitdem (>2 Jahre) problemlos!

Aber: Es verblieben einige eher unkritische IKEA-Leuchtmittel, z.B. 8 Vintage-LED-Kerzen in Gruppenschaltung als dimmbare Deckenleuchte, gesteuert sowohl über diese kleinen IKEA-I/0-Dimm-Taster (leider notwendig, warum: kommt gleich), als auch über TRADFRI-Adapter / Alexa-2 als Ein-/Aus-Dimmsteuerung. Die Ikea-App nutze ich dagegen eher nur zur Konfiguration.

Und diese Leuchten machen (zwar selten, aber eben lästig) immer noch ab und an Ausfall-Probleme, typischerweise im mehr-Monats-Zyklus. Bis heute. Bzw. besser: bis gestern Nacht, als ich zufällig auf die nachvollziehbare Ursache (zumindest dafür) stieß.

• 1. Vermutung: unüberwachtes / "automatisches" Update der Gateway-Firmware
     Das hatte ich schon vor 2 Jahren in Verdacht. Auch war innerhalb der letzten 2 Jahre immer mal wieder das Gateway "nicht erreichbar" aus der App. Allerdings funktionierte alles wieder bestens nach einem Power-On/Off am Gateway. Um aber dafür nicht ständig immer auf den Dachboden kriechen zu müssen, habe ich schon vor > 1 Jahr dafür eine Homematic-Schaltsteckdose vors Tradfri-Gateway positioniert, natürlich als andres System über ein anderes Gateway. Zumindest die App war dann auch wieder nach einigen Minuten erreichbar und konnte schalten.
• 2. Letzte Nacht war es mal wieder soweit. Nix ging mehr. UND: Das gleich zur Hand genommene Handy zeigte nun in der App, dass genau dann gerade ein FW-Upgrade des GW lief! (mag sein, dass nach den letzten App- oder FW-Upgrades nun erst jetzt endlich derartige Fehlermeldungen kommen?)
     ABER: Die App und die kleinen Taster (aber eben nur die) schalteten dann wieder die Leuchten, (wie auch schon bei den letzten Ausfällen), nachdem 1. das FW-Update nach mehreren Minuten fertig war (was ich jetzt erstmalig wirklich beobachten konnte) bzw. ich 2. danach das GW per Remote-Schalter kurz von seiner Stromversorgung getrennt hatte. NICHT JEDOCH DIE STEUERUNG PER Tradfri-ADAPTER/Alexa2!
• 3. Restart des Tradfri-Adapters NACH Power-off/on am Gateway mit (WICHTIG!) ausreichender Verzögerung dazwischen
     Regelmäßig fliegt bei dieser Aktion Nr. 2. (=Power OFF/ON), ggf. aber auch schon durch das vorherige Upgrade inkl. Restart selbst, der Adapter weg. Er steht dann in dem Zustand, wo in der Instanzen-Liste der untere der 3 Haken ("Verbunden mit Gerät oder DIenst") NICHT auf OK steht. Nach Reboot des Adapters geht es -meistens- sofort wieder.
• 4. Verzögerungszeit
     Zuerst habe ich nun mit einem einfachen Blockly-Script den Status meines Power-OFF/ON-Schalters direkt mit dem Adapter-Reboot verbunden (System/adapter/Tradfri/0/alive), um den Schalter gleichzeitig für Adapter-Reboot zu nutzen: KEIN ERFOLG! (bzw. doch: genau das bisherige Fehlerbild: Adapter bleibt -reproduzierbar- im "2-von-3-Haken-Modus" hängen!)
     Die Lösung: Die Einschaltflanke VERZÖGERN! Das Ausschalten kann dagegen sofort erfolgen. Unerwartet: Selbst 20 Sekunden Verzögerung brachten noch keinen Erfolg, aber 1 Minute dagegen reproduzierbar (bei mir) erfolgreich! - Das Gateway muss also wirklich komplett durchgestartet sein vor dem Adapter-Restart!
     Natürlich habe ich auch schon länger (einige Monate) einen Adapter-Cron-Job laufen (jede 33. Minute jeder Stunde), was jedoch KEINEN Erfolg. Offenbar weil nur dann per Cron-Job neu gestartet wird, wenn er nicht schon läuft? (2 von 3 Haken stehen ja auf OK!)

Ursache (zusammengefasst):

• nachweislich primär durch unüberwachtes (leider auch nicht abschaltbares, manuell auslösbares) Firmware-Upgrade des Gateways (vermutlich auch ebenso wirksam bei den FW-Upgrades der Geräte selbst, wie z.B. bei den o.g. Ikea-Schaltsteckdosen)

• Restart des Gateways erfolgt (sowohl im Abschluß des Upgrades, als auch nach Power-Off/On)

• Auslösung eines Restart des Adapters unter Beachtung eines genügenden Zeitabstandes(!!!), minimal im Minutenabstand zum begonnenem Gateway-Reboot, (bzw. alternativ getriggert durch testweise Wiederverfügbarkeit einer Gateway-Funktion, quasi als "funktionales Ping"?)

Tradfri selbst (Geräte und App) funktionieren für sich (inzwischen) stabil, wohl spätestens durch den zumindest aktuell stattfindende automatische GW-Restart im Abschluß des Upgrades.

Der IoBroker-Tradfri-Adapter selbst funktioniert auch, wenn er spät genug nach GW-Restart auch nochmal gestartet wird. Beide zusammen sind aber offenbar NICHT SYNCHRON genug, was dann als Ursache bei den meist nächtlichen Upgrades am Ende den Adapter regelmäßig killt.

Lösung:
"System/.../Tradfri/0/alive" als Auslöse-Datenpunkt für Adapter-Restart nutzen, dabei beim Einschalten mit genügend Timeout für komplettes Gateway-Reboot,

Als Workaround:
Schalt-Trigger abgeleitet aus State eines Power-On/Off-Schalters fürs Gateway (natürlich in anderer, nicht-Tradfri-Technologie), manuell bedient, so man "wieder mal" Probleme bemerkt

evtl. Final vom Adapter-Entwickler:
Vielleicht eine Information als Trigger direkt ableitbar über erfolgtes Update / Wiederverfügbarkeit des Gateways nach Unterbrechung, ERST DANACH autom. Restart des Adapters? Ggf. auch einstellbarer Timeout-Parameter in Adapter-Konfiguration?

Und/alternativ: Gibt es irgendwelche per Script auslösbare Abfragen, um ein Upgrade -am Besten dessen Ende - zu erkennen? Upgrade-History, Versionsnr. o.ä.?

Dass nur mal als Ansatz, den ich nicht für mich behalten konnte/wollte - Vielleicht hilft es ja dem einen oder anderem, oder auch uns allen.

Gruß bb61

Die Geräte hinter den ehemaligen IKEA-Schaltsteckdosen waren übrigens Raspberrys im Clusterbetrieb, um die notfalls auch remote Power-on-rebooten zu können. Aber ungewollt in Zustand "Aus" gebracht nach FW-Upgrade - das war hier absolut KEINE akzeptable Funktion. - Die Shelly-Plug-Schalter dagegen stellen konfigurierbar und stabil ein definiertes Power-On-Verhalten sicher. - Vielleicht hilft auch das jemandem vor ähnlichem Fehler.

[Homoran]

@bb61 ich habe auch ab und zu diese Meldung des kurzfristig nicht erreichbaren Gateways. Das ist aber bei mir alles.
Da ich keine Steckdosen von ikea verwende kann ich das Problem eines Abschaltens nicht nachvollziehen/ bestätigen/ dementieren.
Die Beleuchtung incl. langdauernder Sonnenauf und untergangszenen laufen problemlos, auch wenn so ein Gatewayconnect in dieser Zeit stattfindet.

[bb61]

das Problem beim Tradfri-Adapter ist, dass der ohne manuelles Restart dann ständig in dem Absturz-Zustand verbleibt, auch über Tage oder Wochen.

[Homoran]

@bb61 sagte in Tradfri: Verbindungsabbruch (noch immer) - Lösungsansatz!:

das Problem beim Tradfri-Adapter ist, dass der ohne manuelles Restart dann ständig in dem Absturz-Zustand verbleibt, auch über Tage oder Wochen.

und genau dieses Problem habe ich ja nicht!
der kommt immer sofort wieder hoch. und das sogar bei zwei Instanzen mit zwei Gateways.

ich sehe nur im log, dass kurz der connect weg war. Hatte schon meinen Switch im Verdacht. Aber ein Firmware Update klingt auch plausibel.

[bb61]

ich kenne dieses Verhalten auch nur beim Tradfri-Adapter. Bei den anderen kommen die hier auch "von alleie" wieder. ielleicht fehlt da intern irgend eine Funktion, aber das kann nur der Entwickler beurteilen. - Das Fehlverhalten ist aber nun sogar nachvollziehbar. Ich konnte ja gestern da sogar zusehen per App während FW-Update am GW lief und anschl. dessen Restart. - Und danach war der Adapter -auch wie immer- abgestürzt.

Und das wiederum konnte nun auch nachgestellt werden. Tritt immer auf, wenn Adapter-Restart mit zu geringem Zeitabstand vom GW-Restart passiert.

Bei anderen Adaptern kenne ich weder solche Adapter-Abstürze noch solche Abhängigkeiten von einem laufendem / wiedergestartetem Gateway.