Es hat doch nicht lange gedauert. Inzwischen steht auch die festlegbare Startzeit - innerhalb von 24h. Allerdings erscheint für die Verarbeitung dieses Auftrags das Tasmota Regelwerk stark überfordert - oder ich beherrsche dieses (noch) nicht gut genug.
Ich musste mich also beugen und habe, wieder einmal, einen Adapter in Node-RED erstellt. Dieser nimmt die MQTT-Nachricht, bspw. von der App MQTT Dash, entgegen und ermittelt aus der in der Payload enthaltenen Startzeit die verbleibenden Sekunden bis zum Start. Dieser Wert wird dann veröffentlicht, der entsprechend lauschende µC mit Tasmota empfängt die Nachricht und stellt einen RuleTimer auf diesen Wert.
Damit jedes dafür eingerichtete Frontend (bspw. MQTT Dash, auch auf mehreren Smartphones) diese Startzeit anzeigen kann, auf welche der µC gestellt ist, antwortet letzterer mit dem Timerwert. Dies nimmt wieder ein Node-RED Adapter entgegen, ermittelt daraus die Uhrzeit und sendet eine Nachricht mit der Uhrzeit in der Payload. Jedes online Frontend erhält diese Nachricht und stellt sie dar - auch ein später online gehendes Frontend.
Wenn nun irgendwoher jemand vor der Startzeit die Bewässerung aktiviert, bleibt diese Startzeit wirksam. Mit dem Start der Bewässerung auf Grund der Uhrzeit wird eine Nachricht mit dem Text "erledigt" von µC gesendet. So kann man im Frontend immer sehen, was bzgl. Bewässerung anliegt oder auch nicht (mehr) anliegt. Ich würde eine "erledigt" Meldung mit dem Abschalten der Bewässerung bevorzugen, falls das Einschalten auf Grund der Uhrzeit erfolgte. Dieses zu implementieren, packe ich leider mit den Rule Möglichkeiten noch nicht.
Vorteil dieser Implementation gegenüber meiner ersten ausschließlich per Node-RED und einem shelly 1 ohne Tasmota:
Der µC erhält einen Auftrag und arbeitet danach autark. Er löst die Bewässerung aus und beendet diese nach der eingestellten Dauer - auch wenn die Kommunikation unterbrochen sein sollte.
Die Tasmota Rules
Nach meinen vergeblichen Versuchen, möglichst viel der Nachrichtverarbeitung in Tasmota Rules zu implementieren habe ich schließlich einen Node-RED Adapter erstellt, der diese Verarbeitung sicher und sehr gut bewerkstelligt. Dies hat zur Folge, dass die nun noch erforderlichen Regeln sehr einfach sind.
RuleTimer2 mit der Payload (%value%) initialisieren und diesen Wert zurückmelden - mit retain:on event#start do backlog ruletimer2 %value%; publish2 %mem1%/%topic%/start %value% endon
Wenn RuleTimer2 abgelaufen ist, Power1 auf High setzen und die Nachricht "erledigt" senden - mit retain:
(Das Monoflop wird automatisch gestartet, die Rules sorgen für alles weitere - u.a. senden von MQTT Nachrichten.)on rules#timer=2 do backlog;power1 1;publish2 %mem1%/%topic%/event/start erledigt endon
Was den Ausgang Power1 auf Low fallen lässt, ist unerheblich. Als Ursache kommen ein Tastendruck, ein Abschalten vom Smartphone aus oder auch eine Alexa Anweisung wie "Wasser aus" in Frage. Ebenso ist die Ursache des Startens (Power1 1) unerheblich. So gibt es die meisten Freiheiten. Power1 ist wie im ersten Beitrag erläutert durch die Regeln immer ein Monoflop mit eingestellter Dauer.
Selbstverständlich kann man auch auf der Tasmota Konsole die Startanweisung oder auch die Sekunden bis zum Start eingeben, was allerdings wenig komfortabel ist:
Power1 1 //schaltet das Monoflop ein
event start=7200 //lässt das Monoflop in 2h einschalten
Flow mit den Adaptern zur Kommunikation mit Tasmota
Nur eine Abbildung, Flow derzeit nicht herunterladbar.
Diese Abbildung soll nur einen Eindruck vermitteln. Die Topics im Flow (links) enthalten Platzhalter (+), damit die Adapter für mehrere Geräte nutzbar sind. Allerdings ist darauf zu achten, dass es dabei nicht zu Unverträglichkeiten kommt. So wäre bspw. ein Topic "zuhause/Treppenhaus/start", welches nicht mit einer Startzeit assoziiert ist, zu vermeiden und hierfür statt "start" ein anderes Wort zu wählen.
Die nutzbringende Anwendung
Nach etlichen Tests und Verbesserungen läuft die Bewässerungsanlage endlich. Sie besteht derzeit aus einer fest montierten und einer mobilen Anlage. Die Rasenberegnung läuft seit Sommer 2018 verlässlich. Deshalb habe ich auch davon eine Aufnahme beigefügt.
Die Aufnahmen von links nach rechts: Die beiden Bewässerungsgeräte (rechts) werden per Shelly 1 (Tasmota geflasht) und softwaretechnisch per Tasmota-Rules gesteuert.
Rasenberegnung (12V Magnetventil mit Absperr-Kugelhahn und Anschlusskästchen), Gartenbewässerung fest (12V Magnetventil mit Schlauch anschlüssen und Anschlusskästchen), Bewässerung mobil (12V Magnetventil, im Rohr steckt der Shelly, Rohr ist mit Montagekleber auf dem Boden der Box dicht verklebt)
Für die mobile Bewässerung habe ich mangels 3D Drucker einen Elektro-Anschlusskasten verwendet. Meine Magnetventile sind sehr robust und sparsam im Verbrauch. Sie werden auch nicht warm. Allerdings brauchen sie relativ viel Platz. Das Rohr in der rechten Abbildung soll den Shelly halbwegs vor Wasser schützen. Ganz überzeugt mich meine Konstruktion nicht, vielleicht baue ich den Shelly später in eine eigene kleine IP 66 Box. Platz genug sollte vorhanden sein.
Demnächst will ich motorbetriebene Kugelventile testen, Diese sollten bei länger andauernden Bewässerungen (30 min und länger) besonders effizient sein, weil sie auch im offenen Zustand annähernd keinen Strom ziehen. Selbstverständlich müssen diese selbstschließend sein. Afaik dient hierzu ein Kondensator, der die erforderliche Energie zum schließen bereitstellt.
In der Android App MQTT Dash (obige Abbildung) stehen vier Kacheln zur Verfügung. Von links oben nach rechts unten: Ad hoc Bewässerung ein/aus, Dauer bzw. Restdauer der Bewässerung in Minuten, Schaltuhreinstellung/-aktivierung (innerhalb der nächsten 24h), Dauer der Schaltuhr gesteuerten Bewässerung.
Genau genommen liegt der Dauersteuerung eine einstellbare Periodendauer ab 4s zu Grunde, die wir in der Anwendung auf 60s belassen, eine Periode dauert also normalerweise eine Minute. Nach jeder Periode (1 Minute) wird in der Kachel oben rechts die Restdauer aktualisiert. Die Schaltuhr lässt sich bei Bedarf per leerer Eingabe jederzeit deaktivieren. Auf eine feste Wochentag-Schaltung legen wir keinen Wert.
2020-04-29
