Hast du mal daran gedacht, den Scanner "Script.Eval" Methoden nutzen zu lassen? Damit ließen sich statt verschiedener Events auszulösen verschiedene Skript-Funktionen aufrufen.
Damit täte ein anderer Shelly sofort Parameter verarbeiten, ohne das KVS abzufragen. Das KVS liegt im nichtflüchtigen Speicher, der weniger Schreibzugriffe aushält als ein flüchtiger Speicher (RAM), Ob das bedeutungsvoll ist, hängt von der Anwendung ab. Per "Script.Eval" wäre die Reaktionszeit kürzer.
Sorry, there was a mistake in my variant 2 above which now I have corrected.
Unfortunately I don't have any Shelly Pro 3, but Shelly pro 2 and of corse Shelly Plus 1 ... So I can't test such a script. But it will works.
My first variant above just shows the principle.
But the incoming event has an input state which is a boolean value (true or false). Therefore my variant 2 works if you store the state of input:0 to variable in1, of input:1 to variable in2, of input:2 to variable in3.
Ok, I understood, you need a complete script. Maybe I'll program a little script for you today or tomorrow ...
kann man einen Unterputz Buschjäger Taster mit 240V (Phase und Null) ohne einen Draht zur Lampe bzw zum Relais in der Unterverteilung als Aktor 1 mittels Shelly 1 nutzen und via Szene den Aktor 2 zum schalten der Lampe konfigurieren
Zu 1.
Dazu ist ein Shelly i4 prädestiniert, allerdings bei nur einem Taster auch etwas überdimensioniert mit seinen 4 Eingängen. Jedenfalls muss dann der Sensor Shelly an den Aktor eine Nachricht senden, wenn der Anwender auf den Taster drückt, was sehr leicht per Action möglich ist, wie kingof7eleven bereits mitteilte. Der Sensor kann auch long push oder double push unterschiedlichen Actions zuordnen. Szenen sind wegen Cloud Abhängigkeit nicht empfehlenswert. Ein i4 ist dann besonders interessant, wenn dieser mit 4fach Tastern betrieben wird. Dann kannst du jedem Taster eine andere Funktion zuordnen, bspw. andere Verbraucher schalten oder Rollladen hoch- runterfahren. Diese Konstellation mit zwei oder mehr Shelly braucht aber ein funktionierendes WLAN, was bei 2. nicht erforderlich ist.
Insbesondere zum dimmen wären mindestens zwei Taster zielführend, einer für heller, der andere für dunkler - vielleicht ein dritter zum ein-/ausschalten, was aber bspw. auch per long push auf einen von zwei oder beiden Tastern gelänge. Prinzipiell gelingt so etwas auch mit einem einzigen Taster, wenn alle Nutzer bereit sind, sich an push, long push und double push zu gewöhnen.
Das belastet nicht (!) deinen potentialfreien Schaltkontakt, weil damit nicht die Ladungspumpe angetrieben wird sondern nur ein Relais im 1 PM betätigt wird.
Stimmt so nicht ganz.
Über die Stromstärke (nicht Stromhöhe 
) eines Shelly Plus 1PM Eingangs weiß bspw. thgoebel sehr genau bescheid. Dieser über den Eingang fließende Strom ist aber relativ schwach und wenn potentialfrei geschaltet wird, sollte das keine Rolle spielen. Somit ist der erste Teil weitgehend ok.
Der zweite Teil ist aber falsch. Der Strom eines Shelly Eingangs treibt kein Ausgangsrelais an. Das Relais wird von einem Ausgang des Mikrocontrollers, ggf. über einen externen Schalttransistor betrieben.
In jedem Fall ist zu erwarten, dass die ausschließliche Verwendung eines Shelly Plus 1 keinerlei Probleme darstellt. Ein RC Snubber ist aber evtl. empfehlenswert. Dieser kann an den geschalteten Verbraucher oder zwischen die Ausgangsklemmen des Shelly geschaltet werden und dämpft Störimpulse durch Ausschalten von induktiven Verbrauchern.
Bevor die "Richtigen" sich mitteilen, schon mal eine Vorab-Information von mir.
Es handelt sich offensichtlich um einen Dehnungsmessstreifen, was ein resistiver Sensor ist. Die weiteren Beschaltungserfordernisse hängen von dessen Wert und Empfindlichkeit ab.
Du kannst dazu erst einmal den Widerstandswert ohne und mit anwendungsnaher Verformung messen. Dann lässt sich zumindest abschätzen, ob er ohne oder mit zusätzlichen Bauteilen wie Widerstande und Verstärker an einem AddOn nutzbar ist - vermutlich nur mit Verstärker ...
Zusätzlich ist es nützlich zu erfahren, welches AddOn du nutzen willst, ein AddOn der ersten Generation oder ein Plus AddOn (zweite Gen.).
This may be implemented by an event handler in a script at device y. This handler receives any change of an input, store the status (off vs. on) in a variable and checks the three values like this:
if(in1===off && in2===off && in3===off) Shelly.call("HTTP.Get", {url:"http://<IP address of device x>/rpc/Switch.Set?id=0&on=false"});
respectively
if(!in1 && !in2 && !in3) Shellly.call("HTTP.Get", {url:"http://<IP address of device x>/rpc/Switch.Set?id=0&on=false"});
In the second variant the values of in1, in2, in3 must be of type boolean.
Dafür will ich nicht unbedingt am H&T rumorgenln, sondern auf den Shelly Plus 1 gehen, der an der Gastherme hängt und das dort ändern. Beim nächsten Wachzyklus des H&T kriegt der dann diese neuen Werte mitgeteilt.
Genau so kann es gelingen. Dann braucht der Plus 1 die Solltemperatur, die er mit der vom H&T gelieferten vergleicht und auf Grund des Resultats, einer Differenz zwischen Soll- und Ist-Temperatur (vom H&T) die Therme steuert. Wenn du das ohne übergeordnetes System realisieren willst - ohne Cloud am besten sowieso , dann bleibt nur ein Skript auf dem Plus 1. Dabei kann dir geholfen werden. Das Skript kann die Ist-Temperatur vom H&T auf mindestens drei verschiedenen Wegen empfangen.
Bei 2. und 3. kommuniziert der H&T unmittelbar mit dem Plus 1 über das WLAN, ohne Zwischenstation. Hierfür ist erforderlich, dass im H&T eine Action (=Webhook) erstellt werden kann, was ich stark vermute, aber aus verschiedenen Gründen derzeit nicht testen kann. Ich kann 3. empfehlen, weil dies am robustesten ist. 2. ist etwas leichter zu implementieren. Da hierfür eh ein Skript erforderlich ist, kann zwar ein gewünschtes MQTT Topic bzw. ein gewünschter URL vereinbart werden, die eigentliche Steuerung bzw., an Hand der Soll-Temperatur, Regelung muss aber eh das Skript übernehmen, wobei eine simple Zweipunktregelung genügen sollte. Dies ist sehr leicht implementierbar.
Zwei Schaltschwellen dTu, dTo mit Hysterese
dT = Temperaturdifferenz Istwert - Sollwert
dT < dTu => einschalten
dt > dTo => ausschalten
Da jedes Relais "klackt", kann dir nur eine Halbleiterlösung (SSR oder Opto-TRIAC) weiterhelfen und ein Shelly ohne Relaisausgang wie der Plus Uni. Zur Anpassung der Schaltspannung deiner (Reflektions-)Lichtschranke an die digitalen Eingänge eines Plus Uni können andere mehr sagen. Die beiden Ausgänge des Uni müssen die SSR der so steuern.
Ich würde den H&T gerne so einrichten, dass er in einer Wachphase die aktuellen Werte, falls sie die ensprechenden Abweichungen haben, an eine anderen Shelly schickt und mit neuen Parametern versorgt wird.
Dazu sind die RPC Methoden geeignet. Diese können bspw. per HTTP oder per MQTT genutzt werden. Deren Syntax ist zwar für alle Shelly Generation 2+ sehr ähnlich, aber nicht für alle Typen genau gleich. Insbesondere, wenn ein Ziel-Shelly Skripte nutzen kann, gibt es sehr anwendungsorientierte URL. Sobald klar ist, welcher Shelly Typ die Messwerte mitgeteilt bekommen soll, könnte ich etwas konkretere Auskunft geben.
Nachfrage:
Afaik ist ein H&T (ich besitze nur Gen 1 und Gen 2) ausschließlich für Messungen geeignet. Was kann denn ein H&T Gen 3 mit einer "Solltemperatur" anfangen?
Andere Dinge sind Gegenstand der Konfiguration. Hierfür täte ich mit den RPC Methoden "Sys.GetConfig" und "Sys.SetConfig" experimentieren.
'http://<IP Adresse des H&T>/rpc/sys.getconfig' liefert dir alle Konfigurationsparameter. Viele, wenn nicht alle, von diesen lassen sich per "Sys.SetConfig" ändern. Dazu sind Kenntnisse der Syntax, inbesondere der Parameterstruktur erforderlich. Dies ist in der Shelly API Dokumentation relativ gut beschrieben.
In jedem Fall kann es nicht schaden, während solcher Versuche den H&T über USB zu versorgen.
Edit:
Die Web Browser Edge und Firefox stellen die Antworten des Shelly (im JSON Format) übersichtlich dar, vermutlich noch andere Browser, aber nicht alle.
Ich nutze die Shelly smart control App sehr selten und schon gar nicht zum Einrichten eines Shelly. Die Web UI sind recht verlässlich dafür. Alle meine Plus 2PM laufen ohne Probleme, sowohl mit optionaler Cloud als auch ohne. Auf Grund solcher Erfahrungen empfehle ich dir, zunächst die Cloud auszusperren und den Plus 2PM zu testen, ggf. neu einzurichten - ohne App.
Alternativ kannst du einfach mal einen Tag lang warten. Vielleicht hat die Cloud dann deinen Shelly aufgenommen. Aber wozu willst du die Cloud verwenden? Um die Leinwand per Sprachassistent zu fahren? Dazu nutze auch ich die Cloud, aber ausschließlich optional. (siehe auch meine Signatur)
Wenn du eine echte Regelung möchtest, wie du es andeutetest, dann bietet sich entweder eine Phasenanschnittsteuerung oder eine Schwingungspaketsteuerung an.
Hierzu sollten andere mit mehr Equipment-Erfahrungen auf den Plan treten. Zusammen mit einem Skript ist so etwas implementierbar.
Best regards to seillehs and Gspjb . Both initiated the LWT topic.
Ich greife den Thread in der neuen Umgebung noch einmal auf, weil ich inzwischen weitere Tests durchgeführt und insbesondere zum Thema "Last Will and Testament" (LWT) recherchiert habe.
Die kurze Diskussion mit
@AlexAn hat mich zusätzlich dazu angeregt, weiter zu recherchieren und zu verifizieren.
Zunächst dazu zwei Links zur Shelly API Dokumentation:
Meinen Artikel hierzu habe ich überarbeitet.
Auch bei HiveMQ lässt sich dazu einiges finden. Nicht zuletzt kann man auch die man page zu mosquitto_pub heranziehen.
Aus allen diesen Quellen ist zusammengefasst folgendes zu folgern, zumindest mit einer bis an Sicherheit grenzender Wahrscheinlichkeit.
Somit kann ein Subscriber eines LWT Topic sehr zeitnah den aktuellen Online Zustand eines MQTT Client erhalten. Damit kann eine hohe Verlässlichkeit in der MQTT Kommunikation implementiert werden, in einem übergeordneten System wie auch in einem Shelly Skript. Da die Shelly Firmware das LWT selbst verwaltet, ist es sinnfrei, solches per Skript zu implementieren. Stattdessen kann man selbstverständlich jede andere MQTT Nachricht über den Zustand der per Skript implementierten Anwendung, vom Skript ausgehend, senden lassen.
Klar doch, du musst sie eine Stunde lang in eine Schublade legen.
Ich habe derzeit keinen einsatzfähiges BLU Ding, weshalb ich nichts dergleichen testen kann.
Als ich mir die Skriptvorlage ansah, fand ich aber sehr viel Code, der ausschließlich für DAUs erforderlich ist. Deshalb sollte man das Skript erheblich verschlanken können.
Ich hab dann den BLE Scanner ausgelagert. Dieser löst nun Events aus, die die entsprechenden Datenpaket der Devices enthalten.
Du meinst vermutlich Events, welche lokal auf demselben Gateway Shelly verarbeitet werden.
Macht die Sache zwar schlanker, allerdings sind aber auch nur 3 aktive Scripte pro Gateway erlaubt.
Ein EventHandler kann leicht verschiedene Events unterscheiden. Dazu braucht es nicht mehrere Skripte.
Hast du mal daran gedacht, den Scanner "Script.Eval" Methoden nutzen zu lassen? Damit ließen sich statt verschiedener Events auszulösen verschiedene Skript-Funktionen aufrufen. Ich kann nicht einschätzen, ob dies Vorteile bringen kann.
Die Sache mit dem KVS habe ich noch nicht verstanden. Willst du damit KVS-Einträge auf anderen Shelly immer dann schreiben/ändern, wenn von einem BLU Ding eine Bluetooth Nachricht eintrifft? Dann müsste dem anderen Shelly dies ja zusätzlich irgendwie mitgeteilt werden. Und mit einer solchen Mitteilung ließen sich ja Parameter senden, deren Werte mit der Nachricht eines BLU Dings korrespondieren.
Btw, Es ist nicht abwegig, von einem "BLU Ding" zu sprechen. Schließlich gibt es auch den Begriff des Internet of Things (IoT).
Noch irgendwelche Sachen die ich dir "schuldig" bin ?
Außer der LWT Info nichts.
Das Auslösen der beim Broker hinterlegten LWT Nachricht ist ja unstrittig. Diese hast du detailliert aufgeführt in #10.
Es geht aber um die LWT Nachricht selbst, Topic + Payload, die der Broker vom Client erhalten muss, damit er diese in seiner Datenbank hinterlegen kann und zwar nicht als übliche retained Nachricht.
Dies lässt sich relativ leicht testen.
Ich ließ den Shelly online und sendete von einem anderen Client eine Nachricht mit dem LWT Topic des Shelly und der Payload "aha".
Der Subscriber erhielt sofort die Nachricht "aha".
Dann trennte ich den Shelly von der Versorgung und wartete.
Nach der kleinen Ewigkeit von ca. 90s traf die LWT Nachricht des Shelly ein mit der Payload "false".
Somit ist klar, dass es LWT Nachrichten gibt, welche der Broker als solche speichert und nicht wie eine normale retained Nachricht behandelt.
Wäre dies nicht so, hätte der Subscriber nicht die LWT Nachricht des Shelly mit der Payload "false" erhalten können, da der Broker als letzte retained Nachricht mit demselben Topic ein "aha" gespeichert hat.
Also muss der Broker zwischen LWT Nachrichten und normalen retained Nachrichten unterscheiden.
Wann der Shelly diese spezifische LWT Nachricht an den Broker sendet, bleibt noch offen. Er kann dies dann tun, wenn diese im Shelly geändert wurde, wofür ich nur das Ändern des MQTT Prefix kenne. Er kann die LWT Nachricht aber auch nach jedem Booten an den Broker senden. Dies ist tatsächlich unerheblich, da die LWT Nachricht eh vom Broker gespeichert wird. Ich vermute, dass der Shelly mit jedem Booten seine LWT Nachricht sendet, da man ja auch den Broker wechseln kann.
Auch dir und allen Mitlesern Frohe Ostern! 
Ich habe es getestet und es ist auch selbstverständlich.
Man kann mit dem LWT Topic eine Nachricht beliebigen Inhalts senden, die der Broker sofort weiterreicht, bspw. "aha". Das wird aber vom Broker nicht als LWT gewertet.
Wenn ich dann den Shelly temporär von der Versorgung trenne, sendet der Broker dessen LWT Nachricht "false", aber um ca. 90s später.
Nach dem Power On Reset erhält der Subscriber 2 bis 3 Sekunden später eine Nachricht mit dem LWT Topic und der Payload "true" und nach einem erneuten Power Off die Nachricht "false", nur um ca. 90s später.
Alles klar und verständlich.
Du bleibst mir aber die Antwort auf meine Frage schuldig, woher der Broker die LWT Nachricht des Shelly (oder eines anderen Client) kennt, wenn diese nicht vom Client übermittelt wurde.
Dies muss der Client immer dann tun, wenn er eine Verbindung zum Broker aufgebaut hat. Damit der Broker nach dem Verbindungsaufbau die Nachricht "true" sendet, muss ihm dies vom Client zugesandt worden sein. Dem Broker sind die Inhalte von MQTT Nachrichten völlig wurscht, er muss nur "wissen", wann er eine LWT Nachricht an Subscriber senden soll/muss.
Weil das vorher "vereinbart" wurde. Wird im Broker gespeichert sobald du die Einstellungen in der Shelly gespeichert hast.
Das könnte zutreffen. Dann müsste ich per anderem Client und normaler Nachricht die LWT Nachricht des Shelly ändern können. Das werde ich testen.
Der Client kann dem Broker auch gar nichts mitteilen wenn er offline ist oder einen Protokoll Fehler hat.
Genau deshalb trifft die "false" Nachricht erst viel später beim Subscriber ein, nachdem der Shelly "gestorben" ist - wegen Power off.
Wie erklärst du, dass beide Nachrichten, zuerst "false", danach "true" im Abstand von 2 bis 3 Sekunden beim Subscriber eintreffen, wenn der Shelly rebootet wird?
Bei Power off hingegen trifft die "false" Nachricht erst erheblich später ein, bspw. ca. 90s.
