Bisher habe ich die Shelly 2.5, welche ich zur Rolladensteuerung einsetze, über iobroker + MQTT gesteuert. Ich nutze bei ihnen die original Firmware, weil ich die Positionskontrolle, die Kalibierierung und die Hindernis-Erkennung sehr schätze. Darum steuere ich jetzt nicht mehr per MQTT:
Scheinbar ein Firmware Bug
Disclaimer: dieser Artikel ist schon etwas älter. Ob es ein Bug war und ob es diesen potentiellen Bug noch gibt, weiß ich nicht. Ich komme mit der Nicht-MQTT Steuerung sehr gut klar, daher habe ich dies beibehalten.
Ab und zu kommt es bei meinen Shellys dazu, dass die WLAN Verbindung abbricht. Dies liegt einfach an der Reichweite des WLANs, die in mancher Wand im Grenzbereich liegt. Dies ist normalerweise kein Problem, da sich die Shellys recht zuverlässig wieder mit dem Router verbinden. Doch manchmal öffnen sich nach der Wiederverbindung wie von Geisterhand die Rollos – also sie fahren unvermittelt nach oben. Viele Tests später ist meine Theorie, dass dies am MQTT liegt, und es hier scheinbar einen Bug in der Firmware gibt.
MQTT + iobroker Objekte
Zweiter Grund: Von NodeRED kommt die Logik meines SmartHomes. So auch die Rolladensteuerung. Über das Setzen/Ändern von iobroker Objekten, sendet man die Befehle per MQTT. Ein Problem: hat das Objekt bereits den gleichen Wert, wie den, den man setzen will, wird der Befehl nicht übertragen. Wurde also zum Beispiel zuletzt das Rollo auf 60% gestellt, das Rollo danach per Wandtaster wieder hochgefahren, kann man es nicht erneut auf 60% einstellen, weil das Befehls-Objekt noch auf 60 steht. Man muss also umständlich auslesen, welcher Wert gerade im Objekt steht, und ggf. z.B. 61 übermitteln.
Darum nutze ich jetzt die HTTP API
Umgestiegen bin ich auf die HTTP API. Über sie rufe ich peridoisch den aktuellen Status ab (tags öfter als nachts) und sende Befehle. Die Vorteile:
- Ich habe einen Adapter weniger im iobroker, spart Arbeitsspeicher.
- Ich umgehe den möglichen Firmware Bug und habe (bisher) keine geisterhaft öffnenden Rollos mehr.
- Ich kann Befehle senden, ohne diese vorher mit dem aktuellen Status abgleichen zu müssen.
- Ich bekomme über den HTTP StatusCode (200) direktes Feedback, ob ein Befehl angekommen ist.
So mache ich es
Zum einen habe ich in Node-RED einen HTTP in-Node erstellt, bei dem sich die Shellys über die I/O URL Actions melden, wenn sie stoppen – also die Rollos eine neue Position eingenommen haben. Der dann angestoßene Abruf der Position hält den Wert im iobroker aktuell.
Zum anderen habe ich einen Subflow erstellt, welcher die Befehle an die Shellys übermitteln. Er benötigt als Argument die IP des betroffenen Shellys und einen Befehl. Dabei verarbeitet der Subflow sowohl Open, Close und Stop als Textbefehle als auch Integer-Werte – zwischen 0 und 100 – für die Position des Rollos in „Prozent geöffnet“. (100% = ganz offen)
Hier das Flow:
Hallo Lukas,
ich habe gerade Deine Seite zufällig entdeckt und stöbere gerade durch Deine interessanten Beiträge.
Shelly und MQTT:
Ich habe bei mir sämtliche Rollladen-Shellys mit Tasmota geflasht und steuere diese ausschließlich über MQTT – was hervorragend funktioniert.
IObroker habe ich allerdings (noch) nicht im Einsatz. Bei mir läuft alles über Node-Red.
Dennoch gibt es zum Thema „Ghost-Switching“ einige generelle Hinweise im Netz. Auch ich hatte dieses Phänomen schon und konnte mich schnell, zuverlässig und nachhaltig davor schützen.
1.) ich lese sehr häufig von Problemen bei Nutzung des IObroker-internen MQTT-Brokers. Bisher offenbar immer erfolgreiche Lösung: Installation eines eigenständigen MQTT-Brokers auf dem Raspi (z.B. Mosquitto – der läuft bei mir nun schon 3 Jahre 24/7 problemlos durch). Der IObroker hat offenbar ein paar Problemchen, sodass man auf den separaten MQTT-Broker umsteigen sollte.
2.) im MQTT-Broker sind womöglich noch ein paar „Retain-Leichen“ vorhanden. Retain-Flags sollten nur in besonderen Ausnahmefällen gesetzt werden und sind mit Vorsicht zu genießen. Die können sogar noch Monate nach Ausführung eines Befehls zuschlagen.
Ich benutze nie ein Retain-Flag. Ich erwarte nach jedem ausgehenden MQTT-Befehl immer eine zurücklaufende Statusmeldung vom Empfänger, die ich als Quittierung bzw. Statusbestätigung in Node-Red verarbeite. Sollte diese ausbleiben, gehe ich je nach Anwendung entsprechende Wege, die ich individuell definiere und programmiere. Die alleinige Retain-Funktion von MQTT ist mir da zu pauschal. Das Ausbleiben solcher Rückmeldungen verwende ich nebenbei auch zur Überwachung der Verbindung bzw. zur Feststellung, ob der Absender über haupt noch lebt.
Falls dennoch Retain-Flags genutzt werden, dann hilft ein „Aufräumen“ des MQTT-Brokers.
Hartes Aufräumen: MQTT-Broker anhalten, dessen Database löschen, Broker wieder starten (der legt seine neue und frische Database automatisch an). Nachteil: alle gewollten (noch unausgeführte) Befehle werden damit gelöscht.
Selektives Aufräumen: über Konsolenbefehle kann man z.B. beim Mosquitto einzelne Topics neu setzen, freigeben, löschen etc.
Ob das auch beim internen IObroker-Broker geht, weiß ich nicht.
Bei mir hat damals die komplette Löschung der MQTT-Broker-Database sowie die rigorose Vermeidung von Retain-Flags perfekt geholfen. Seitdem hatte ich kein einziges mal „Ghost-Switching“ Probleme.
Viele Grüße,
Markus
Vielen Dank für die guten Hinweise!