2022-04-23

Der ursprüngliche Anlass war, den Garten ferngesteuert und komfortabel bewässern zu können, auch wenn man/frau nicht zu Hause ist. Die Speicherung und Anzeige der letzten Bewässerung soll den Anwender unterstützen.

Mittlerweile habe ich mich mit den Shelly Plus Geräten und deren Original Firmware beschäftigt. Diese Geräte beinhalten einen ESP 32, der im Vergleich zum ESP 8266 sehr viel mehr Programmier- und Anwendungspotential bietet. Man kann parallel die Shelly Cloud und die lokale Netzwerkkommunikation per MQTT nutzen. Per Scripts lassen sich Anwendung spezifische Verhaltensweisen implementieren. Ich habe für zeitgesteuertes Schalten, wie dies für - auch ferngesteuerte -  Gartenbewässerung zweckmäßig ist, drei virtuelle Geräte implementiert - switch, mono und timer. Prinzipiell ließen sich diese virtuellen Geräte auf verschiedene Hardware verteilen.

Kurzbeschreibung der virtuellen Geräte (VG)

Jedes der folgenden drei VG wird durch eine JavaScript Datei implementiert, die per Shelly Weboberfläche als "Enable" eingestellt ist und demzufolge bei einem Neustart des Shelly geladen und ausgeführt wird.

• switch ist ein Nachrichten gesteuerter Schalter, der sich die letzte Einschaltzeit mit Datum merkt und nach dem Ausschalten diesen Zeitpunkt und die Einschaltdauer mitteilt. Dies tut es unabhängig vom Trigger des Schaltens. Ich nutze drei optionale Quellen für die Triggerung - ein Taster, MQTT Nachrichten und Amazon Echo (Alexa). switch sendet sowohl das Einschalt- als auch das Ausschaltereignis per Nachricht.
• mono (von monoflop) ist ein einstellbarer Timer, der bei Empfang einer "eingeschaltet" Nachricht (von switch) einen Abwärtszähler für die Restdauer mit der eingestellten Dauer initialisiert. Nach jeder Periode, bspw. 1 Minute, zählt es die Restdauer um 1 herunter und teilt diese Restdauer mit. Bei Restdauer von 0 sendet es eine Nachricht, die von switch abonniert ist und letzteres zum ausschalten triggert. Empfängt mono eine "ausgeschaltet" Nachricht (von switch), deaktiviert es sich.
• timer dient dem triggern zu einer eingestellten Schaltzeit mit eingestellter Schaltdauer. Die Schaltzeit wirkt in einem Rahmen von 24 h, sie gilt also innerhalb der folgenden 24 h ab einstellen dieser Zeit. Sobald die Schaltzeit erreicht ist, sendet timer zwei Nachrichten. Eine Nachricht beinhaltet die Dauer, welche mono empfängt, übernimmt und dies rückmeldet. Nach der Rückmeldung sendet timer die Schaltnachricht, die switch empfängt und daraufhin schaltet. Empfängt timer eine leere Schaltzeit, stellt es sich inaktiv und teilt seinen Zustand per Nachricht mit.

Neu:

Diese drei VG sind inzwischen neu gestaltet und erweitert. Sie liegen als switch_n, mono_n und timer_n vor. Anlass sind zwei Shelly Pro 2, die ich zur Bewässerungssteuerung einsetzen will. Ein Pro 2 besitzt zwei Schaltausgänge. Die neuen VG können mehrere Schaltausgänge steuern und entsprechend mehrere Datensätze verwalten. Mit dem Hochfahren (reboot) des Shelly ermittelt switch_n die Anzahl an Schaltausgängen, legt zu jedem Ausgang einen Datensatz an und veröffentlicht diese Anzahl per MQTT. Sobald mono_n und timer_n diese MQTT Nachricht empfangen, legen auch sie entsprechend viele Datensätze an. Die neuen VG können auch ohne Änderung auf einem Shelly Plus 1 verwendet werden. Sollte Allterco Robotics einmal einen Shelly der 2. Generation mit vier Schaltausgängen und Scriptfähigkeit anbieten, dann werden voraussichtlich die drei VG ohne Änderung darauf lauffähig sein.

Zusätzlich habe ich in mono_n mehrere Schaltmodi implementiert.

• 'p' (permanent): dauerhaft schalten, die Einschaltdauer ist deaktiviert
• 'm' (monoflop): temporär schalten, die Einschaltdauer wirkt
• 'o' (once): die Einschaltdauer wirkt einmal, danach liegt 'p' vor - vermutlich kaum genutzt
• Zahl (als String), die Zahl wirkt als Multiplikator für die Einschaltdauer

Im letzten Modus (Zahl) wird mit dem Einschalten die eingestellte Dauer mit dieser Zahl multipliziert, das Ergebnis ist die resultierende Einschaltdauer. Aus einer eingestellten Dauer von 3 Minuten und dem Modus '4' wird eine Einschaltdauer von 3*4=12 Minuten. In der dritten Abbildung (s.u.) erscheint in der dritten Kachel der ersten Zeile (verbleibend) statt "3 m" dann "12 m". Diese Modi nutze ich derzeit mit einer per Shelly Plus 1 geschalteten Lampe. Der Shelly Plus 1 wird per Shelly i4 und MQTT gesteuert. Je nach Dauer des Tastendrucks wird ein Modus gewählt und ein- bzw. ausgeschaltet. Es ist auch möglich, die Dauer eines Tastendrucks in Sekunden als Einschaltdauer in Minuten zu nutzen. Ich habe noch keine Erfahrung damit, ob dieses Anwender freundlich wäre. Vermutlich wäre dies mit etwas Übung intuitiv nutzbar.

Die weitere Beschreibung gilt nach wie vor.

Nutzbarkeit, usability

Mit dem Verhalten dieser VG können Benutzer*innen jederzeit ad hoc ein- bzw. ausschalten, die gewünschte Schaltzeit und -dauer einstellen, die Schaltuhr (timer) deaktivieren und auch mono per Dauer von 0 deaktivieren bzw. inaktiv lassen. Sowohl die eingegebene Schaltzeit als auch die Dauer werden fehlertolerant verarbeitet. Bei ungeeigneten Eingaben werde diese schlicht ignoriert. Die Schaltzeit kann auch in Kurzform eingegeben werden, wie bspw. 9 -> 09:00, :5 -> 00:05.

Zusätzlicher lokaler Zeit-Informationsdienst

Die Firmware des Shelly Plus bietet derzeit keine Erfassung des Tagesdatums. Um im mitgeteilten Einschaltzeitpunkt auch das Tagesdatum mitzuliefern, habe ich auf meinem "smartcenter", einem Raspberry Pi 4 mit Linux, ein kleines Shellscript erstellt, welches bei Empfang einer MQTT Nachricht die aktuelle Zeit mit Tagesdatum - und bei Bedarf auch das Jahr - per MQTT sendet. Dieses Script wird automatisch als Dienst gestartet. Die empfangene Nachricht benötigt eine Zeichenkette im JSON Format, welche u.a. die Formatierung der zu sendenden Zeitinformation enthält. So ist dieser Dienst sehr flexibel nutzbar.

Frontends, Benutzer-Maschinen-Schnittstelle

Ich nutze als Frontend gerne die Android App "mqtt dash", welche auch auf alten Smartphones problemlos arbeitet. Alternativ ist prinzipiell jede App nutzbar, die Konfigurationen von MQTT Nachrichten zulässt. Auch bspw. Node-RED oder openHAB sind geeignet, vermutlich auch FHEM, ioBroker, ...

Ausfallsicherheit

Da die drei VG untereinander per MQTT kommunizieren, funktioniert diese Gruppe nicht mehr als solche bei Ausfall des MQTT Brokers oder einem Netzwerkausfall. Diesen Umstand habe ich bedacht und dokumentiert. An den zweckmäßigen und implementierbaren internen Verhaltensweisen für solche Fälle arbeite ich. Hierfür stehen in der Scriptsprache die Erfassung zweier Zustandsänderungen (connected und disconnected) zur Verfügung, zu welchen geeignete Eventhandler zu erstellen sind. Bisher habe ich folgende Verhaltensweisen bei MQTT-Ausfall implementiert (vermutlich wird es dabei bleiben).

• switch: Bei disconnected wird ausgeschaltet, die Einschaltdauer berechnet und die später zu sendende Nachricht im JSON Format gespeichert, inkl. einer Fehlermeldung. Bei connected wird die gespeicherte Nachricht gesendet.
• mono: Bei disconnected wird der mono Timer beendet. Bei connected wird der aktuelle Zustand von mono gesendet. Das sind die eingestellte Dauer, die Restdauer (hier: 0) und ob mono läuft (hier: false).
• timer: Bei disconnected wird die Startzeit gelöscht, falls timer das Einschalten bereits per Nachricht aktivierte. Andernfalls bleibt die Einschaltzeit erhalten. Bei connected wird der aktuelle Zustand von timer als Nachricht gesendet.

Anwendungen

Bisher habe ich als Anwendung Bewässerungen im Garten fokussiert. Dies werde ich mit Hutschienen Shelly Pro 2 auch reinstallieren. Die Shelly 1 mit Tasmota werden diesen neuen Shelly mit Original Firmware weichen, obwohl die alten Shelly mit Tasmota und vollgestopften Rules sehr gute Dienste geleistet haben. Mich überzeugen aber neben den Scriptmöglichkeiten der neuen Shelly Pro 2 die LAN-Anschlüsse und die einfache Nutzung der Cloud sowie Amazon Echo Geräten zur Sprachsteuerung neben lokaler MQTT Kommunikation. Bei Bedarf lässt sich die Cloud-Anbindung sehr schnell und einfach deaktivieren und ausschließlich MQTT nutzen.

Auch zum schalten beliebiger Geräte, wie Leuchten, lassen sich Shelly 1 Plus Geräte mit oben beschriebenen VG installieren. Man muss ja nicht alle Möglichkeiten dieser VG nutzen, wenn man welche nicht braucht. Um die Einschaltdauer zu deaktivieren, kann man einfach die Dauer auf 0 stellen. Dies gilt auch für die Schaltuhr bezogene Dauer. Dann wird nach dem Einschalten, ggf. zur eingestellten Uhrzeit, ein- und nicht automatisch nach Ablauf der Dauer ausgeschaltet. Ich will gelegentlich für Beleuchtungen noch eine Zufallssteuerung auf Basis von mono implementieren. Diese kann gut bei Abwesenheit von zu  Hause eingesetzt werden.

Screenshots

Von links nach rechts, auf Smartphones von oben nach unten: Der Script Editor im Web Browser, in MQTT Dash eingestellt und angezeigt ... vor dem Einschalten, nach dem Einschalten, nach dem Ausschalten

Die MQTT Dash Screenshots zeigen alle derzeitig implementierten Anwendungsmöglichkeiten. Ein Anwender wird evtl. nicht alle nutzen wollen, sie stehen aber bei Bedarf zur Verfügung.

• Erste Kachelzeile: Einschalten per Anwender ad hoc oder per Schaltuhr sowie Anzeige des Schaltzustands (VG switch) - eingestellte bzw. aktive Dauer des Einschaltens (VG mono) - verbleibende Restdauer des Einschaltens (VG mono),  m = Minuten, s = Sekunden
• Zweite Kachelzeile: Einschalten Uhrzeit (VG timer) - Einschalten Dauer (VG timer) - optional: aktuelle Zeit (ca.), Datum und Uhrzeit per Shellskript von einem Raspberry Pi im Minutentakt geliefert
• Dritte Kachelzeile - Daten des letzten Schaltens: Datum, Uhrzeit des Einschaltens - Dauer in Minuten und Sekunden - Fehler während des letzten Schaltens (leer -> kein Fehler festgestellt)

Mit dem Einschalten per Schaltuhr (VG timer) wird deren Dauer an VG mono übertragen, das diese und die Restdauer per MQTT sendet. Diese Daten werden in der ersten Kachelzeile angezeigt. Die Daten der dritten Kachelzeile werden nach dem Ausschalten aktualisiert, bzw. nach wiederhergestellter MQTT Verbindung.

Anmerkungen

Obiges Verhalten habe ich in der ersten Generation mit Tasmota auf Shelly 1 per Tasmota Rules implementiert. Zusätzlich waren noch Adapter (per Node-RED implementiert) erforderlich. Solche Adapter werden in dieser Generation mit solchen Scripts nicht mehr gebraucht.

Alternativ ließen sich die drei VG ohne interne MQTT Kommunikation implementieren. Dann wären statt senden der Nachrichten Funktionsaufrufe einzusetzen. Allerdings werden für die (ferngesteuerte) Nutzung ohnehin Nachrichten benötigt. Leider bietet die Scriptsprache bisher keine Möglichkeit von Includes, was die Aufteilung des Projektes auf bspw. drei Scripts nicht unterstützt und somit ein langes Script erforderte. Dies würde das Projekt recht unübersichtlich und schlechter pflegbar machen. Diese Einschränkung brachte mich auf die Idee, virtuelle Geräte zu implementieren, die per MQTT kommunizieren.

Wochenpläne, wie sie bereits von der Firmware unter "Schedules" geboten werden, können dort eingesetzt werden. Wir brauchen zur Gartenbewässerung solche Wochenpläne nicht, da das Wetter nicht plan- und bestellbar ist. Für Anwendung in Räumen erscheinen Wochenpläne durchaus zweckmäßig.

--- Fortsetzung folgt vielleicht, evtl. in Gestalt eigener, VG bezogener Beiträge ---