Ich kann dir generell empfehlen, im EventHandler das Einschalten des Verbrauchers, also Component "switch:0" statt Component "input:0", zu verwenden.
Dann arbeitet das Skript unabhängig von der auslösenden Quelle. Entscheidend ist nur das Einschalten. Somit sollte dir auch die Lösung per HomeKit (mir unbekannt) einfallen.
Btw, auch das Einschalten per Sprachassistent wird auf diese Weise verarbeitet.
Soweit ich Schreddl verstand, sucht er eine unintelligente Lösung per einstellbarem binären Feuchtesensor, welcher möglichst direkt ein einzelnes Ventil steuert.
Dann darf er lange mit der passenden Einstellung experimentieren, weil er nichts aufzeichnen und so kaum etwas auswerten kann. </Sarkasmus> 
Aber möglich ist das und es kann fast jeder nutzen, der feinfühlig genug einen Schraubendreher handhaben kann. (Mir täte so etwas nicht gefallen, muss es ja auch nicht.)
Die entscheidenden Hinweise hat DIYROLLY bereits in #5 gegeben.
Den Schalter schließt du an einem Shelly Eingang (SW) an. Der Shelly schaltet die Pumpe und muss dauerversorgt sein.
Der Rest ist per Software auf einem übergeordneten System oder auf einem skriptfähigen Shelly zu implementieren.
Sicherheitsrelevante Einrichtungen sollten per se nicht auf eine Cloud angewiesen sein.
Was willst du denn mit einem binären Wert feucht vs. trocken anfangen? Willst du einen solchen Sensor etwa nur in einem Topf einsetzen? Der Titel lässt einen anderen Schluss zu.
Ein Feuchtigkeitswert kann ja, für welche Zwecke auch immer, verarbeitet werden und entsprechende Maßnahmen signalisiert oder automatisiert ausgelöst werden. Wirklich trocken täte sehr oft bedeuten, dass eine Pflanze unrettbar verloren wäre, also eine Bewässerung dann eh zu spät käme.
Ich plädiere dafür, dass im weiteren Diskussionsverlauf nur noch Fachjuristen oder Versicherer Antworten geben und ziehe mich deshalb ab nun hier heraus. 
Afaik verwendest du kein übergeordnetes System. Solange eine solche Berechnung + Anzeige keinesfalls sicherheitsrelevant ist, wäre evtl. eine Szene in's Auge zu fassen, womit ich mich aus naheliegenden Gründen wenig auskenne. Per Skript(erweiterung) gelänge so etwas durchaus - bspw. per MQTT Nachricht, oder auch per kleiner Webseite, welche das Skript liefert.
Mir ist aber noch völlig unklar, wie du von 50°C und 60°C auf 54% kommst. Das arithmetische Mittel ist 55°C - und nicht etwa 54°C. Welche Bezugstemperatur willst du festlegen? Bedenke auch, dass ein Mittelwert hierfür nicht sehr aussagekräftig ist und schon gar nicht für eine Sicherheitsabschaltung taugt.
Hast du denn die von dir gewünschte Priorisierung schon implementiert? Vermutlich gelingt dies nicht per Action (=Webhook), weil das Schalten per Kommunikation nicht sperrbar sein dürfte. Vielleicht gelänge solches per Szene, wovor ich aber abrate. Mit einem Skript wird eine solche Priorisierung jedenfalls implementierbar sein.
Zur Abschalttemperatur wissen andere mehr. Ich täte mich darum bemühen, die SSR an anderer Stelle zu platzieren, wenn diese als entscheidende Wärmequelle feststehen. Eine benachbarte Dose/Gehäuse wäre bereits dafür geeignet. Zur Sicherheit sollte darin die Temperatur überwacht und bei Überschreitung von bspw. 60°C abgeschaltet werden. Auch solches gelänge per Skript oder vermutlich auch Action.
Die Firmware 1.3.1 lässt im Web UI keine Änderung von KVS Variablen mehr zu. Damit ist für manche Anwender die KVS Nutzung kaum noch möglich. Hoffentlich wird dies noch geändert. Ob dies per RPC Methode gelingt, habe ich bisher nicht getestet.
Die Firmware 1.3.1 lässt im Web UI keine Änderung von KVS Variablen mehr zu. Damit ist für manche Anwender die KVS Nutzung kaum noch möglich. Hoffentlich wird dies noch geändert.
Mit FW 1.2.2 hatte ich es getestet. Nun habe ich FW 1.3.1 drauf.
Btw, ich habe in meiner Dokumentation die Möglichkeit aufgezeigt, Messdaten und Zeitstempel in zwei Dateien zu speichern, wobei i.d.R. die Zeitstempeldatei nur eine oder bei Stromausfall nur sehr wenige Zeilen umfasst. Erst bei der Übertragung wird der Zeitstempel zu jedem Messwert generiert. Ein Copy & Paste würde damit aufwändiger.
Vielleicht wäre mit deinen Datensätzen auch eine Komprimierung möglich.
just izi abel oder auf engl. just easy ability
Was sagt eine KI dazu?
Haftet diese für ihre Aussagen eigentlich? Oder wer oder was?
Ich lasse nun meinen Test-Shelly mit Skript durchlaufen und will testen, ob es abgebrochen wird - vor 20480 Byte Füllstand in "data".
Soweit ich erinnere, tat ich dies bereits, ohne dass das Skript vorher abgebrochen wurde. Damit konnte ich dieses Limit belassen. ...
Du kannst meinem Skript entnehmen, dass ich dort das Limit auf 20480 setze (=20k). Dieses Limit der Dateigröße hat sich bewährt, ist aber dem Einsatzzweck angepasst. Meine Experimente ergaben, dass bei wesentlich größerer Datei, soweit ich erinnere um die 30k, irgendwann ein Skriptabbruch die Folge war.
Die API Dokumentation schweigt sich darüber aus. Ein Forenmitglied hatte mir einmal mitgeteilt, dass die experimentell maximale Größe bei 48k läge und die verfügbaren Speicherressourcen seit Firmware Version 1.x (?) fest auf die 10 möglichen Skripte aufgeteilt seien. Nach meinen Erfahrungen teilt sich vermutlich diese Größe von ca. 48k auf Skriptlänge und Arbeitsspeicher auf. Um solches herauszufinden, bleiben offenbar nur eigene Experimente.
In einem anderen Projekt scheiterte mein Vorhaben jedenfalls an der ram_size von 260016, welche bei nicht laufendem Skript angezeigt wird. Dies ist aber nicht die maximale Größe einer Datei.
Das Speichern im Shelly hat insbesondere dort seinen Vorteil, wo irgendwelche Informationen zur Auswertung gespeichert werden sollen, wo keine Kommunikation mit anderen Geräten oder Internet verfügbar ist.
Da bis zu 10 Skripte möglich sind, sollte bis zu theoretisch 9*20k Byte Speicherkapazität ohne Probleme nutzbar sein. Solche Versuche habe ich bisher nicht durchgeführt, weil ich dazu keinen Anlass hatte.
Das hat nichts mit dem i4 zu tun, sondern mit dem empfangenden Rollladen-Shelly.
Der URL .../roller/0?go=stop u.ä. gehören zur ersten Generation der Shelly wie der 2.5 und sollte in den Shelly ab zweiter Generation noch abwärtskompatibel sein. In den neueren Shelly gibt es hierfür die wesentlich flexibler nutzbaren RPC-Methoden.
Ich empfehle eine allmähliche Umstellung auf RPC-Methoden bei Shelly ab zweiter Generation.
Du kannst versuchen, die Daten auf mehrere Dateien aufzuteilen.
Afaik wird jedem Skript eine maximale Speicherkapazität zugeordnet.
Wie eine solche Aufteilung zielführend zu strukturieren ist, hängt von den Daten ab, welche du speichern willst.
Ein Rolladen ("Rolladen Haustür") reagiert seit ein paar Wochen nicht mehr auf "Rolladen Haustür schließen". Alexa antwortet dann mit "ich bin mir leider nicht sicher".
Hast du auch mal eine andere Benennung versucht wie bspw. "Rolltür" statt "Rollladen Haustür"?
Hast du ein anderes Gerät mit ähnlich klingendem Namen eingesetzt? "Haustür schließen" ist ein wenig verdächtig.
Das Skript biete ich nicht zum herunterladen an, da es in meiner Fassung recht spezifisch ist und für andere Anwendungen anzupassen wäre. Ich stelle es aber bei Interesse gerne zur Verfügung.
Einige Dinge sind optional, was ich dann jeweils erwähne. Sie können somit bei Nichtbedarf entfernt/weggelassen werden.
Hier der aktuelle Inhalt der von mir für Testzwecke gespeicherten Daten. Vorne steht der Unix Timestamp, nach dem Komma der gemittelte Temperaturmesswert.
1714725000,14.7
1714725900,14.7
1714726800,14.7
1714727700,14.7
1714728600,14.7
1714729500,14.7
1714730400,14.8
1714731300,14.8
1714732200,14.8
1714733100,14.8
1714734000,14.8
1714734900,14.8
1714735800,14.8
1714736700,14.8
1714737600,14.8
1714738500,14.8
1714739400,14.8
1714740300,14.8
1714741200,14.8
1714742100,14.8
1714743000,14.8
1714743900,14.8
1714744800,14.8
1714745700,14.8
1714746600,14.8
1714747500,14.8
1714748400,14.8
1714749300,14.8
1714750200,14.8
1714751100,14.8
1714752000,14.8Das Skript im Anhang dürfte für deine Zwecke nicht 1:1 nutzbar sein.
Ist beim Reset auch die eingespielte Software weg ?
Nein, da die Software im nichtflüchtigen Speicher liegt. Mehr kann ich dazu nicht sagen, weil du deine eingesetzte Software nicht genauer benennst/beschreibst.
gibt es bei Ihnen Module für die Steuerung von elektrischen Rollläden
"Wir" sind Anwender von smart home und IoT, keine Anbieter.
Ergänzend zu obigen "Feststellungen":
Damit will ich eine andere Perspektive aufzeigen und nicht etwa die Skript- + Schedule-Lösung in den Vordergrund stellen, da es viele gibt, die sich nicht mit Shelly Scripting beschäftigen wollen/können.
Ok, ca. 3k Byte können nach meiner Erfahrung locker auf einem Skript fähigen Shelly gespeichert werden.
Du könntest dir mal meine Beschreibung zur lokal auf dem Shelly zu speichernde Messwerte ansehen. Ich habe dazu ein für Messwerte geeignetes Skript erstellt. Für deine Zwecke wäre das Skript anzupassen.
Der wesentliche Unterschied zur Messwertspeicherung liegt vermutlich darin, dass deine Datensätze unterschiedlich lang sind. Ob alle lokal gespeicherten Daten mit einer einzigen MQTT Nachricht übertragen werden können, weiß ich nicht. Deshalb lasse ich die gespeicherten Daten in mehreren Paketen übertragen, wozu ich aber eine feste Zeilenlänge verwende. So können ganze Zeilen als Elemente der Nachrichten übertragen werden.
Falls dir ein Copy & Paste per Web UI genügt, könntest du die Datendatei öffnen und deren Inhalt per Zwischenablage kopieren.
Wenn du Interesse an meinem Skript hast, lasse es mich wissen, am besten per PM (Konversationen)!