kuhniwerle
Mir fiel noch eine Lösung ein. Ich setze kein übergeordnetes System und keinen MQTT Broker voraus.
- Langer Druck => runter
- Kurzer Druck => Status quo abhängig
stehend => rauf
fahrend => stop
Ein Fazit findest du am Ende.
Mit einem langen Druck, wie oben gewünscht, immer zu fahren, dürfte nicht gelingen, da nach einem Stop per Tastendruck vom Nutzer die Fahrrichtung festgelegt werden muss.
Dies gelingt mit der Unterscheidung zwischen kurzem und langem Druck. Auch erscheint mir dies hinreichend intuitiv.
Andernfalls müsste der Nutzer unter Umständen mehrmals drücken, bis die gewünschte Reaktion erfolgt.
Ob dies zielführend gelingen kann, hängt nur noch davon ab, ob der aktuelle Status zeitnah genug erfassbar ist.
Ich habe es remote, bin weit weg, mit einem Shelly Plus 2PM getestet.
Die asynchrone remote Abfrage lautet
http://<IP Adresse>/rpc/cover.getstatus?id=0
Die Antwort in result.state ist einer der folgenden Strings: "opening", "closing", "stopped", "open", "closed"
Somit ist das Ziel per Skript auf einem i4 implementierbar.
Ob hierbei evtl. auftretende Verzögerungen akzeptabel sind, bleibt zu prüfen.
Ein kurzer Tastendruck muss folgende Wirkung haben.
state: "opening" oder "closing" => stop
state: "stopped" oder "closed" => rauf
state: "open" darf bei kurzem Druck keine Wirkung haben. Man könnte dann zwar herunterfahren lassen, dies täte aber vermutlich den Lernerfolg von Nutzern eher behindern.
Da die Antwort bei einer remote Abfrage evtl. zu stark verzögert eintreffen kann und diese nicht synchron verarbeitbar ist, sind ein Skript sowohl auf dem Plus 2PM als auch auf dem i4 empfehlenswert.
Das Skript auf dem Plus 2PM kann vermutlich recht kurz sein. Es braucht dazu nur einen Event- oder StatusHandler, der die zielführende Information selektiert und eine Nachricht mit dem Status per HTTP an den i4 sendet.
Das Skript auf dem i4 speichert die vom Plus 2PM empfangene Info, damit ein kurzer Tastendruck, wie oben angedeutet, zur passenden Nachricht an den Plus 2PM führt.
Die RPC Methoden sind "Cover.Open", "Cover.Close" und "Cover.Stop" - jeweils mit id=0.
Ein langer Tastendruck hat immer ein Herunterfahren zur Folge, also http://<IP Adresse 2PM>/rpc/cover.close?id=0 .
Die Antwort lautet leider immer null. Deshalb ist der Status zusätzlich zu übermitteln.
Auf dem i4 sind im Skript folgende Teile erforderlich.
- Ein HTTP Endpoint, der die Nachricht vom Plus 2PM empfängt und geeignet verarbeitet, d.h. den übermittelten Status speichert.
Alternativ kann vorbereitend die Methode für den nächsten kurzen Tastendruck selektiert werden. - Ein EventHandler, der sowohl den langen als auch den kurzen Tastendruck verarbeitet, Letzteren wie oben erläutert.
Das ist das Prinzip. Ich habe ein begonnenes Skript verworfen, weil ich nicht alles, weit weg von den Shelly, testen kann bzw. dies in meiner Situation relativ aufwändig wäre.
Vielleicht habe ich in wenigen Tagen genügend Muße dazu, dies zu versuchen.
Fazit:
Das, was du als Ziel formuliertest, ist prinzipiell geringfügig abgewandelt implementierbar.
Ob die Reaktionszeiten nach einem Tastendruck erträglich sind, muss im Feldversuch getestet werden. Da ich auch per i4 und Skript steuere, kann ich eine kurze Reaktionszeit in Aussicht stellen.
Selbstverständlich sind die Handhabungen per kurzem und langem Tastendruck auch vertauschbar.
Nachgereicht:
Diese Lösung funktioniert auch dann, wenn zwischendurch eine andere steuernde Quelle genutzt wird, wie Shelly Button 1, Web UI, Sprachassistent (Hey Google, Alexa, Iris, ...), weil der Plus 2PM immer dann seine Nachricht an den i4 sendet, wenn sich sein Status ändert.
Da die Verarbeitung des empfangenen Status auf einen nächsten kurzen Tastendruck vorzubereiten hat, sollte eine Verzögerung von ca. 2s kein Problem darstellen.
