Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[Worlik]

Hallo,

folgendes einfaches Szenario: Aufruf von setState für einen boolean-Value:

setState('wled.0.0123456789ab.on', false, false);

Angenommen die WLED Instanz ist kurzzeitig nicht im Netz/nicht verfügbar, dann wird der Status nachträglich nicht gesetzt. Das führt in meinem Setup immer wieder dazu, dass Lampen eingeschaltet oder ausgeschaltet bleiben. Das resultiert dann in einem aufwändigen Skript, wo ich mir abhängig vom "Hauptbutton" oder der Szene den gewünschten Zielstand merke und diesen immer wieder setze, bis ich einen ack = true bekomme (sprich das Event wird überwacht und ausgewertet). Aufgebohrt habe ich das noch mit einer manuellen Überwachung des Onlinestatus und anderer Zielwerte der jeweiligen Lampe, um den gewünschten Zustand so schnell wie möglich herzustellen.

Ich frage mich, ob ich irgendwie auf dem Holzweg bin, weil mir das irgendwie doch recht aufwändig wirkt. Das Szenario braucht man ja eigentlich ständig, dass ein Zielzustand dann auch erreicht wird, ohne das man diesen speziell überwachen muss. Es geht aber bei mir jetzt noch weiter als AN oder AUS, sondern WLED Instanzen werden natürlich auch über Presets und andere Properties kontrolliert.

Was ist hier die Best-Practice? Konkret geht es um WLED, Shelly (COAP) und Govee Geräte.

PS: Ich habe das in Allgemein gepackt, weil das selbe Problem auch auftritt, wenn man den Status über den Objektbaum setzt. Falls das eher als Skripting-Frage gesehen wird, bitte verschieben.

[OliverIO]

@Worlik

ich glaube das gibt es aktuell so nicht.

primär wäre natürlich zu überprüfen warum eine Instanz/Adapter überhaupt weggeht.
das sollte eigentlich kein Normalzustand sein.

ansonsten müsste man eine Zwischeninstanz haben, die die von dir beschriebene Funktionen durchführt:

• Schreibbefehl entgegen nehmen
• schreiben durchführen
• prüfen ob schreiben erfolgreich war
• ggfs in konfigurierbaren abstand wiederholen
• Abbruch nach x versuchen oder x zeit und Fehlermeldung das anderweitig wieder darauf reagiert werden kann.

das wäre ggfs ein Adapter oder eine Funktionalität im iobroker

[Asgothian]

Ich hatte so etwas im zigbee Adapter eingebaut. Ergebnisse waren ernüchternd. Die Verbindung ist letztendlich nicht so gut, dass man sich darauf verlassen kann, dass

– eine schaltBefehl, der nicht bestätigt wird, nicht ausgeführt wurde.
– ein Gerät, welches nicht erreichbar ist, zufällig nicht erreichbar ist.
– der Schaltbefehl weiterhin gültig ist, wenn die Wiederholung letztendlich das Gerät schaltet.

Am Ende habe ich das wieder entfernt, da muss der Nutzer explizit über Skripte einer Lösung erzeugen. Eine allgemeingültige Lösung die in allen Fällen gut funktioniert habe ich nicht.

[Worlik]

Hey, erstmal danke für euer Feedback. Die Frage, ob man sich auf ack überhaupt verlassen kann habe ich mir auch schon gestellt. Ich würde natürlich die Erreichbarkeit verbessern, oft ist diese aber aus Energiespargründen halt nicht perfekt. Alles ist darauf getrimmt, dass es gerade so eine Verbindung hält und dabei maximal Strom spart. Ich habe auch Konstellationen, wo ein Shelly andere Instanzen überhaupt erst einschaltet und mit Strom versorgt (Beispiel: WLED). Jeder ESP32 verbraucht ungefähr 0,5 - 1 Watt. Egal, ob etwas eingeschaltet ist. Auch das Netzteil eines WLED Strangs saugt am Strom, obwohl gar nichts läuft. Deswegen kann es manchmal 1-2 Sekunden dauern, bis eine WLED-Instanz da ist - allerdings passiert das wegen der Energiesparmaßnahmen auch manchmal mitten im Betrieb, wenn man halt das Licht ausschalten will. Möglicherweise liegt es auch an der Anzahl der Geräte: 95 Shellys, 17 WLED Instanzen und 9 Govee Geräte. Ohne die Energiesparmaßnahmen wäre das eine Grundlast von ~100W.

Was echt schwierig fällt ist die Beobachtung, was genau passiert, wenn mal wieder ein Licht an bleibt, obwohl es aus sein sollte oder auch das es nicht an geht, wenn es an sein sollte. Ich kann nicht alles Dauerloggen, wegen der Anzahl der Geräte ist das auch schwierig zu sehen. Sprich ich kann nur simulieren, indem ich Geräte bewusst vom Netz trenne oder abschalte. Ich habe aber die Vermutung, dass sich das leicht anders Verhält als im realen Betrieb.

Ich habe in den Geschäftsräumen übrigens alles in Homematic, da sind Schaltzustände immer perfekt und werden auch nachgeführt, wenn Geräte nicht im Netz sind. Aber das ist ja auch ein geschlossenes Ökosystem und damit einfacher als die Eigenheiten verschiedener Adapter und Geräte zu berücksichtigen. Problematisch wird es da, wenn die CCU nicht erreichbar war (bei einer Steuerung von iobroker aus).

Ich finde die Nachführung von Schaltsignalen ist fürs SmartHome mit das wichtigste, deswegen dachte ich ja auch, dass ich bestimmt nur was übersehe. Das Zigbee Problem hatte ich übrigens auch schon, das liegt wohl am Protokoll. Ein ack kann nur bei einem Protokoll mit richtigem Handshake klappen. Ansonsten ist der Schaltzustand nicht wirklich festzustellen.

[ticaki]

Meiner Meinung nach funktioniert nachführen immer nur für eine Teilmenge der Geräte. Einfaches Beispiel: Shelly wird eingeschaltet - ack verschwindet im nirwana - nutzer schaltet gerät per Taste aus - Statusmeldung verschwindet ebenfalls - adapter schaltet ihn, wenn das Problem behoben ist, wieder an.

Umgehen kann man dass wenn das schalten immer über iobroker stattfindet - nur fraglich, ob man bei einem Gerät das die Verbindung verliert, damit glücklich wird :)

Ein stabliles Netz ist IMHO die einzige Lösung. Hab hier 4 wlan APs.

[Homoran]

@Worlik sagte in setState setzt Zielwert nicht nachträglich:

oft ist diese aber aus Energiespargründen halt nicht perfekt.

Smarthome ist nicht kompatibel mit solchem Energiesparen ;-)

[Worlik]

@ticaki Ja, das beschriebene Problem muss man in der Tat auch berücksichtigen. Zum Glück gibt es ja noch 2 Timestamps an jedem State-Objekt. Darüber kann man eine Entscheidung treffen, welcher Zustand nun wirklich gültig ist. Aber ja, super schwer zu unterscheiden, was nun Benutzer-Wille ist. Ein Shelly der direkt schaltet verhält sich immer anders als einer, der mitgeschaltet wird. Gilt ja auch für die WLED und Govee Instanzen. Bringt halt nichts, wenn der schaltende Shelly kein Netz hat, dann geht vielleicht das Hauptlicht an oder aus, aber mitgeschaltete Geräte, welche nur über den iobroker geschaltet werden nicht. Verwendet man die Shellys detached und überlässt iobroker jeweils die Entscheidung, ist es am logischten aufgebaut. Ist iobroker nicht da, kann man dann aber nicht mal eine Notbeleuchtung im Haus an machen. Wichtig ist glaube ich in jedem Fall, dass nur der letzte Wunsch der User umgesetzt wird. Über den Timestamp. Und das ist aber wieder abhängig davon, ob der Schaltwunsch vom auslösenden Gerät halt in iobroker ankommt.

Ich glaube übrigens nicht, dass mein WLAN grundsätzlich das Problem ist. Ich habe 8 Access Points für Haus und Hof. Es sind vor allem die WLED Instanzen welche Probleme machen. Vielleicht muss ich hier doch mal die ESPs tauschen. Aber ich hätte eigentlich trotzdem gerne, dass der Status perfekt nachgezogen wird, wenn ein Gerät mal nicht erreichbar war. Das muss ja auch funktionieren, wenn man in einem Raum mit AP mal die Sicherung ganz raus nehmen musste und einige Geräte hart disconnected wurden. Genau diese Situation führt immer wieder dazu, dass es ein bisschen dauert, bis alle Geräte wieder am optimalen AP angemeldet sind. Mal gucken, ob ich mir einen Adapter oder vielleicht zunächst auch erstmal nur eine kleine Klasse für global baue, damit ich die wiederverwenden kann. Falls ich mit der Codequalität und dem Ergebnis zufrieden bin, teile ich sie vielleicht hier. ;)

[ticaki]

@Worlik
Wieso sollten 2 Timestamps da irgendwie helfen - in meinem Beispiel schaltet die Nachführung den shelly auf einen veralteten Zustand. Da ein online kommender Shelly seinen aktuellen Zustand als "ist jetzt so" veröffentlicht und die Nachführung keinen Plan hat ob da zwischenzeitlich das licht manuell geschaltet wurde.

Seit meine Krempel in einem eigenen 2.4er Netz hängt hab ich da keine Probleme mehr.

[BananaJoe]

Ich sehe das wie @ticaki , meine Shellys und Tasmotageräte sind nach einem Stromausfall im letzten Status. Und sobald die wieder Strom haben und WLAN, melden dieses den auch wieder an ioBroker.
In ioBroker habe ich durchaus Dinge die ich dann zusammenschalte. Da läuft dann neben dem Trigger der auf akute Änderungen reagiert auch ein regelmäßig Task der ggf. abgleicht wenn 2 Dinge voneinander abweichen die nicht abweichen sollen. Bei 2 Shelly gibt der eine dann vor was der andere haben soll.
Das Problem sehe ich bei mir eher Theoretisch. Im Gegenteil, mit meinem ioBroker und dem MQTT darauf bringe ich das eher mal durcheinander als die Geräte es ohne könnten. Neulich machte ein Bewegungsmelder und eine Lampe Probleme, nach einem Neustart von ioBroker machte die Lampe Disco. Weil ich im Skript nicht auf einen definierten Startzustand geachtet habe - da spielten 2 Shellys zusammen und die hatten dann eine Kombination die laut meinem Skript gar nicht vorkommen dürfte und es lief Amok.