Da es aber trotzdem nicht funktioniert hat, habe ich jetzt das 1pm Gen3 eingebaut [...]
Dann ist für die Kopplung mit dem BLU Gerät der unterste Teil des von der KI gelieferten Skripts unzureichend. Ein Shelly ab Gen 3 ist eindeutig dafür die bessere Wahl. Noch viel Freude damit!
Bei Szenen kann ich dir nicht weiterhelfen, weil ich mich damit nicht eingehender beschäftige. Wie mit der Einschalt-Aktion die Bewegungsmeldung gesperrt werden kann, weiß ich derzeit auch nicht, da ich dies nicht testen kann. Ich kann allenfalls etwas zu einem Skript beitragen. Somit werde ich nun auf weiteres warten.
Ob die Lösungen von MIHO gelingen, kann ich nicht einschätzen.
Entscheidend ist das Erkennen der Einschaltquelle oder zwei quellenselektive Aktionen (s. Michael).
Zu den Aktionen
Ich nutze derzeit keinen BLU Taster und kann es nicht testen.
Kleiner Nachteil: Mit jedem Ein- und Ausschalten wird in den nichtflüchtigen Speicher geschrieben.
Größerer möglicher Nachteil: Nach manuellem Ausschalten per BLU Button wird evtl. der Motion für ein sofortiges, temporäres Einschalten sorgen. Dies hängt davon ab, an welcher Stelle du den BLU Button nutzt.
Alternative
Solltest du mit den Aktionen nach Michael keinen Erfolg haben oder dir die Aktionenlösung nicht gefallen, sollte es mit einem Skript gelingen. Falls ein solcher Bedarf besteht, bitte ich um eine entsprechende Mitteilung. Die Skriptlösung braucht nicht in den nichtflüchtigen Speicher zu schreiben. Da ein Skript entweder quellensensitiv oder nachrichtensensitiv arbeiten kann, kann damit voraussichtlich eine Verzögerung der Bewegungswirkung nach dem manuellen Ausschalten implementiert werden.
Eine Lösung per Cloud Szenen ist imho ... na ja, siehe meine Signatur. 
Du nutzt offenbar ausschließlich die App/Cloud Ansicht. Was dir weiter oben gezeigt wurde, ist die Ansicht der vom Shelly gelieferten Website.
-> Web Browser Adresszeile http://<IP Adresse des Plug S> -> Home
Was willst du denn mit der Stromstärke anfangen, außer diese abzulesen?
Zu 1.
Dazu sollte der Shelly dort platziert werden, wo er nicht feucht wird und die Leitungen parallel an den Shelly Eingang geführt werden können. Dann ist die Pumpe ausschließlich über den Shelly schaltbar. Dieser wird per Zapfstellenschalter angesteuert.
Zu 2.
Es gelingt nur eingeschränkt, wenn ein Nutzer den Shelly auch über den virtuellen Button schalten will, weil dieses Schalten nicht verhindert werden kann. Das Einschalten kann dann per Skript zu sofortigem Ausschalten führen.
Wenn das Deaktivieren (ausschließlich) über einen Schalter erfolgen soll, dann kann dieser Schalter in Reihe zu den parallelen Zapfstellenschaltern verdrahtet werden.
Zu 3.
Dazu kann zum Einschalten ein fest einzustellender Timer genutzt werden. Alternativ gibt es einen geeigneten RPC Aufruf.
Fazit
Ohne Bedienung per WebUI, (App, Cloud), genügt die einfache Schaltung mit dem in Reihe verdrahteten Schalter (s. 2. unten).
Mit Bedienung per bspw. WebUI ist neben einem Skript ein zweiter Eingang am Shelly zielführend. An Letzterem ist der Aktivier-/Deaktivierschalter anzuschließen, dessen Zustand das Skript abfragen muss. Ist dieser bspw. auf Aus gestellt, schaltet das Skript die Pumpe nach dem Einschalten sofort wieder aus.
Zusätzlich ist es nützlich, den Zapfstellen Eingang per zweier Aktionen zu aktivieren/deaktivieren, was die Wirkung der Zapfstellenschalter freigibt/sperrt.
So oder so ist ein konfigurierbarer Timer zum schaltenden Ausgang für die maximale Einschaltdauer zu nutzen.
Deine Lösungsansätze schätze ich als wenig relevant ein. Auch das Skript zu stoppen / zu starten ist total überflüssig. Nur "Auto off nach Zeit x einrichten" ist zweckmäßig.
Da steht "Antwort von ...": Antwort von 10.34.76.232
Grien. Ohne hier zuviel diskutieren zu wollen, gestatte mir bitte die folgende Logik anzubringen.
Bei (temporärer) Nichterreichbarkeit eines Zielhost kann doch nur der Quellhost eine solche Antwort mitteilen, oder ?
Problem nur wieder der muss ja 24/7 laufen.
Nicht zwingend. Du kannst ihn auch automatisiert selbst herunterfahren lassen und bspw. per Shelly 1 Gen 3+ und Schedule Job (Zeitplan) einschalten lassen.
Wie erreiche ich denn dann z.b. von zuhause?
Per VPN und zwei VPN unterstützenden Router - Netz zu Netz VPN. Dazu sind jedenfalls die nicht ganz alten von AVM (FRITZ!boxen) geeignet.
Der Shelly i4 kommuniziert per WLAN, ob damit auch Bluetooth Kommunikation zu Aktoren möglich ist, weiß ich derzeit nicht.
Mit Shelly Schaltaktoren ab Generation 3 bist du richtig, da diese BT Kommunikation per Firmware unterstützen.
Was immer gelingt: Je Verbraucher ein Shelly 1(PM) Gen 3+
Bei Bedarf kannst du in einem Schaltschrank/Verteilerschrank auch mehrkanalige Schaltaktoren nutzen, wobei du selbstverständlich auf die von den Verbrauchern genutzten Außenleitern achten musst - oder zumindest solltest, falls die Shelly potentialfrei schalten.
Es gibt auch reine Shelly BT Taster, deren Halter du irgendwo im Saal "ankleben" kannst - Taster herausnehmbar.
Zumindest die Windows Kommandozeile zeigt vor "Zielhost nicht erreichbar." die IP Adresse des pingenden Hosts an.
Ein Raspberry Pi Generation 4 mit USB Laufwerk (nicht SD Karte!) genügt für dein Vorhaben völlig. Dieser wird nicht ausgelastet sein. Ich kann wenigstens 4MB RAM empfehlen. Das USB Laufwerk (evtl. SSD) sollte vorsichtshalber mindestens 128GB Kapazität haben, was für deine Anwendungen vermutlich auch sicher ausreicht.
So ist es.
Ein passendes Skript sollte ich beisteuern können, auch wenn ich dein Equipment nicht habe.
Dazu solltest du offen für dir bisher noch Unbekanntes sein. Kompliziert wird es aus meiner Perspektive nicht.
Edit:
Du verwendest die Abfrage des Shelly Gesamtstatus. Hier geht es aber afaik ausschließlich um die Abfrage des Status eines Eingangs - und das möglichst synchron.
Der in #1 genutzte Aufruf von Shelly.getComponentStatus("input:2") hat offenbar einen Fehler ausgelöst, weil dieser Aufruf nicht verarbeitet wurde. Die Fehlermeldungen sind nicht immer hilfreich, wie man weiß.
Darauf beziehe ich mich und empfahl, stattdessen einen Aufruf mit zwei Parametern zu verwenden - konkret zu #1 in Skriptzeile 2.
let wind = Shelly.getComponentStatus("input", 2);Deine Abfrage in #19 geht imho am Thema dieses Thread vorbei, auch wenn die Messwerterfassung damit zum Ziel führt. Dies ist allenfalls eine Alternative und keine Notwendigkeit. In einem umfangreicheren Skript unterstützen synchrone Abfragen das Einhalten des Limit von 5 zeitgleich ausgeführten RPC. Der Rest ist selbstverständlich Geschmackssache.
Ich verstand es so:
Wenn WLAN am EM ausfällt ...
Andernfalls bliebe noch die Nutzung eines Shelly AP, wenn die Reichweite genügt.
Ein Shelly 3EM ab der zweiten Generation (mit Pro im Namen) ist die bessere Wahl, weil dieser sich aktiv an der Kommunikation mit anderen Shelly Geräten beteiligen kann. Hinzu kommt, dass damit flexible Schedule Jobs möglich sind.
Der Pro 3EM kann bspw. alle 5s (konfigurierbar) eine Nachricht senden, welche von einem anderen Shelly ab Generation 2 per Skript verarbeitet werden kann. Dieses Skript schaltet dann auf aus, wenn nicht innerhalb von bspw. 12s die erwartete Nachricht vom Pro 3EM eintrifft. Darin ist bereits eine kleine Sicherheit eingebaut, falls einmal eine solche Nachricht vom Pro 3EM verloren gehen sollte.
Ich möchte noch einmal auf die technisch eh bessere Variante hinweisen, in welcher statt mit einem mit zwei Parametern aufgerufen wird.
s.a. https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…componentstatus
Shelly.getComponentStatus("input", <Component id>);bzw. allgemein
Shelly.getComponentStatus(<key bzw. component categorie>, <Component id>);Ein String Parameter mit eingebauter Id ist eine schlechte Altlast, vermutlich aus der Frühzeit der Shelly Entwicklung. Diese war vermutlich einer kurzen time to market oder auch einem sparsamen Gebrauch des Stack geschuldet und imho nicht sorgfältig geplant. Die Rückwärtskompatibilität dient typischerweise dazu Reibungsverluste in der Vermarktung und der Kommunikation zu vermeiden, was aber die Beibehaltung von schlechten Implementationen nach sich zieht.
Somit rufe ich dazu auf, die zweiparametrige Lösung überall dort zu verwenden, wo diese funktioniert.
Falls mich jemand nicht verstehen sollte, kann ich gerne einen weitwinkligen Blick auf die Shelly Umgebung versuchen, was relativ viel Text nach sich ziehen würde.
Kurz: Ich schlage jeden mit Argumenten, der die einparametrige Lösung verteidigen will - mit Ausnahme des Shelly Vermarkters, der letztlich die finanziellen Mittel hereinholt.
Nein, weil der Griff von OBEN (12 Uhr) auf unten (6 Uhr) gedreht wird, also nicht um 90 Grad sondern 180 Grad.
Sorry, das meinte ich nicht. Wenn die beiden Endstellungen des Griffs horizontal liegen, dann ist der Drehwinkel nach wie vor 180°.
Hast du auch einmal folgendes versucht?
... Shelly.getComponentStatus("input", <Component id>);Auch auf die Gefahr hin, dass dies bereits erörtert wurde - habe dazu die um 90° gedrehte Griffbefestigung im Gedächtnis, wenn ich die Reaktion von Schubbie richtig verstand.
Gibt es denn keine Möglichkeit, den Vierkant der Türmechanik so zu verändern oder zu ersetzen, dass der Griff in seinen Endstellungen horizontal liegt? Vermutlich ergibt es dann kaum einen Unterschied im Kraftaufwand, aber evtl. in der Handhabung.
bzw. muss sich nach Aktivierung sofort oder nach 1sec wieder ausschalten.
Mit einem Skript gelingt das sofortige wieder Ausschalten, wenn Eingang 1 (=input:0) aus ist. Das täte ich zusätzlich zum Sperren des verkabelten Eingang 1 per Aktion, was thgoebel bereits erwähnte.
Hier ist aber keine Nachricht.
Du hast recht. Wegen einiger "Kümmern" Ambitionen habe ich dich tatsächlich verwechselt, sorry.
