Servus Richard,
ich denke, du hast nichts übersehen, was die Daten in der Cloud im "Basic Plan" betrifft.
An mehr Daten kommst du über die Cloud, wenn du bezahlst oder ohne Cloud, wenn du z.B. die Daten an ein programmierbares Shelly schickst und dort (per Skript) aufzeichnest.
Grüße
Thomas
Aber wenn man den Auto-Start des Scripts in der Testphase nicht aktiviert, bleibt diese Chance auch ohne Verzögerung. Das ist übrigens dieser Schalter:
Ah ja, sehr schön. Jetzt weiß ich auch, was das für ein Schalter ist, denn Hilfe (Tooltip o.ä.) gibt es leider nicht
Wäre es nicht am Einfachsten den Start von Scripten um 10 Sekunden nach dem Hochfahren zu verzögern, damit Zeit für einen Reset bleibt?
Das würde ich nicht mehr als Fix sondern als Workaround werten. Aber wenn man es sonst nicht hinkriegt akzeptabel. Hoffentlich machen sie das dann nicht mit einer while (t<10sec) - Schleife 
Aber wer testet den Fix, wenn er raus ist?
Freiwillig bestimmt nur jemand, der Notfallmaßnahmen durchführen kann, i.e. jemand mit Klinik
Eigentlich haben die Entwickler doch die ideale Testumgebung (die while(true); Schleife) geliefert bekommen, um das selber zu testen.
Der Bildschirm müsste eigentlich noch etwas weiter nach unten gehen: Bei mir steht darunter sinngemäß eine Zeile "Wenn die Temperatur höher als 0°C ist" und wiederum darunter ein Temperatureingabefeld (Thermometersymbol und daneben ein Eingabefeld, in dem eine "0" steht und geändert werden kann.
Dass du deinen H&T als Thermostat bezeichnest, irritiert mich. Es ist bloß ein Thermo- und Hygrometer...
Nun ja, es darf keine Endlosschleife geben. Siehe auch https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…cking-execution
Richtig, aber ganz ehrlich hätte ich nicht angenommen, dass man das Device dann nicht mehr gezähmt kriegt. Einen funktionierenden Mechanismus (ohne Adapter für einen Bootloadermechanismus zu benötigen!), um so ein Gerät rückzusetzen hatte ich unbedingt angenommen. Aber wie ostfriese wurde ich eines Besseren belehrt. Bin ja mal gespannt, ob BG irgendwann mal was dazu sagt und entweder das Problem eingesteht oder besser in eine der nächsten Firmwareversionen einen wirklich funktionierenden Mechanismus einbaut.
"If a script manages to crash the device the system will detect this and disable the script at the next boot." scheint ja wohl nur angedacht zu sein aber nicht wirklich zu funktionieren, denn dann würde sich das Device ja spätestens beim nächsten Aus/Ein der Spannungsversorgung wieder im WLAN anmelden.
Nun ja, es darf keine Endlosschleife geben. Siehe auch https://shelly-api-docs.shelly.cloud/gen2/Scripts/S…cking-execution
Außerdem ist eine Endlosschleife in einem Shelly Script sinnfrei, weil per Skript kein Polling zielführend ist. Die Firmware verwaltet das Abfragen von Messwerten und Eingangssignalen. Sie teilt solche Werte periodisch oder bei Wertänderungen einem Skript an registrierte callback Funktionen als Event-, Status- oder TimerHandler mit - Letzteres ist faktisch der Fall, auch wenn es in der Dokumentation nicht so genannt wird. Zusätzlich gibt es Schedule Jobs, mit welchen eine periodische Abfrage von Werten per RPC möglich ist. Das sind wesentliche Grundlagen beim programmieren von Shelly Skripten.
Ist mir alles irgendwie bewusst, habe vor mehr als 30 Jahren selbst etliche Jahre im embedded Bereich ohne Betriebssystem entwickelt, da galten ähnliche Regeln für einen sicheren Betrieb, allerdings hatte das Device damals einen Hardwarewatchdog...
Wie gelang dir solches? Hast du als ersten Parameter im Aufruf von Timer.set() eine 0 oder gar einen negativen Wert eingetragen? So etwas war ich noch nie versucht zu testen ...
Oder hast du in der callback Funktion des Timers eine Endlosschleife eingebaut?
Tatsächlich bin ich dran ein Logging von wesentlichen Ereignissen im Device einzubauen, weil ich Dinge überwachen will, die sich auch über Tage hinziehen können.
Da ich nicht ständig einen Rechner dranhängen haben will, möchte ich das Log im RAM speichern und es später per Aufruf einer Skriptfunktion abrufen.
Jetzt ist mir nicht gelungen mehr als ein paar print()-Ausgaben ohne Pause auszugeben, die Grenze scheint bei 7 Ausgaben ohne Pause zu liegen. Macht man mehr print()-Aufrufe in Folge, so sieht man nur die letzten paar auf der Konsole.
Daher hab ich dann erstmals mit einem Timer rumgespielt und da etwas unaufmerksam eine Endlosschleife eingebaut.
Kannst Du die Stelle bitte zitieren? Ich finde die nicht, egal wie oft ich den Post lese. Vielleicht hast Du aber auch meinen einfach nicht richtig gelesen...
Vielleicht auch mal den Reset-Knopf beim stromlos machen und wieder bestromen die ganze Zeit gedrückt halten.
Sorry für die späte Antwort!
Ich hatte entsprechend Beschreibung den Resetknopf >10sec gedrückt nachdem ich die Spannungsversorgung eingeschaltet hatte -> kein Erfolg.
Und in einem weiteren Versuchen den Resetknopf gedrückt gehalten, die Spannungsversorgung eingeschaltet und weiterhin mehr als 10sec gedrückt gehalten -> ebenfalls kein Erfolg.
In einem Shelly Skript gibt es keine Endlosschleife. Ein solches Skript sollte, wenn es etwas zielführendes tun soll, Ereignis gesteuert arbeiten.
Du kannst etwas ähnliches nachbilden per Timer, der eine Funktion periodisch aufruft.
Gibt es keine Endlosschleife oder sollte es keine geben? Mit Letzterem würde ich dir recht geben.
Bei den Versuchen etwas mit Timern zu machen, hab ich einen Fehler gemacht ... und schon kam ich nicht mehr ran.
Dein Skriptskelett in #1 startet sich nicht selbst. Dies wäre ohnehin paradox. Ein laufendes Skript sich selbst starten zu lassen, obwohl es schon läuft?
Na ja, mit startet sich selbst meinte ich den Aufruf der Funktion außerhalb jeder geschweiften Klammer. Wenn ich mich nicht täusche, wird der Interpreter solche Funktionen aufrufen, wenn das Device aus dem Reset hochgelaufen ist.
Dafür gibt es Methoden.
Zum Factory Reset sollte diese Methode führen: Shelly.FactoryReset
Solange der Plus 1 bzw. Shelly ab der zweiten Generation erreichbar ist:
http://<IP Adresse>/rpc/shelly.factoryreset
Ich habe es nicht getestet, rechne aber wegen der eindeutigen Dokumentation damit, dass dies funktioniert.
Edit:
Interessant wäre ein Versuch, dies per Skript zu realisieren:
Folgende Anweisung sollte hierfür genügen.
CodeShelly.call("Shelly.FactoryReset", {});
Danke, aber beim Zustand meines Devices denke ich nicht, dass man damit eine Chance hat. Dafür müsste man das Gerät per Skript noch mit Befehlen beaufschlagen können oder wenigstens im lokalen Netz ansprechen können. Beides geht nicht.
Gab es bei der Gen1 nicht die Möglichkeit eines Resets durch 5x Strom aus und an kurz hintereinander? Einen Versuch wäre es ja wert.
Danke, hatte ich ja zunächst versucht, siehe Kommentar #2.
Stromlos machen, einschalten, kurz danach den Taster für >10 Sec. drücken.
Die LED sollte ausgehen und danach blinken.
Danke, aber hatte ja davon im vorangegangenen Kommentar geschrieben, dass ich das bei diesem Exemplar erfolglos probiert hatte. Aber ich scheine die Methode grundsätzlich zu beherrschen, denn mit einem anderen Exemplar ging es ja.
Mittlerweile habe ich auch in der Anleitung gefunden, dass das Ding einen Reset-Button und eine LED hat, mea culpa, hatte das Gerät vor einem halben Jahr verbaut und damals keine Notwendigkeit gehabt den Button zu benutzen oder die LED zu beobachten.
Nach Strom aus und nach ein paar Sekunden wieder an leuchtet die LED konstant. Drücke ich den Resetbutton für 5 oder auch für 10sec passiert mit der LED nichts, sie leuchtet durchgehend rot.
Bei einem anderen Shelly Plus1 Exemplar reagiert die LED auf das Drücken des Resetbuttons in oben beschriebener Weise.
Daher muss ich annehmen, dass das Device hinüber ist, schade. Hätte nicht gedacht, dass die Dinger so sensibel auf ein ungünstiges Skript reagieren.
Hallo,
jetzt habe ich es geschafft, nach vielem Rumspielen mit (einfachen) Skripten, habe ich wohl eine Endlosschleife produziert.
Ok, wie setzt man ein Shelly Plus 1 zurück?
Da habe ich die Prozedur mit dem je 5x Öffnen und Schließen des Schalters nach Strom aus/an gefunden.
Aber funktioniert diese Prozedur auch, wenn ein Skript gespeichert ist, das sich selbst startet, also z.B.
MyTest() {
// mach eine Endlosschleife (absichtlich ohne Code)
}
MyTest();Jedenfalls bin ich bis jetzt nicht erfolgreich gewesen mit der Schalterprozedur und ich frage mich jetzt, welcher Teil des Gerätes in der 1. Minute dieses Schalter öffnen und schließen kontrolliert. Denn das Skript läuft doch deutlich vor Ablauf einer Minute nach Neustart los, oder?
Letztlich halte ich die Funktionssicherheit mit einem Plus AddOn und Sensor eher gegeben als mit einem H&T.
Weil die Temperatur ohne Kommunikation zwischen Devices ermittelt werden könnte?
Ist denn die Kommunikation zwischen H&T und Plus so unsicher? Klar, es können mal Störungen im WLAN auftreten, aber das H&T sendet alle 5min seinen jeweils aktuellen Messwert und es soll ja nicht mehr gemacht werden, als level-getriggert der Plus-Shelly ein- oder ausgeschaltet werden. Da würde erst mal nicht viel passieren, bis auf zu spätes Ein- oder Ausschalten des Relais.
Verständlich. Du kannst auch einen zusätzlich Shelly mit AddOn statt des H&T dafür nutzen. Dies gelänge sogar mit einem Shelly 1, also der ersten Generation - nur falls dir ein solcher mit AddOn zur Verfügung stehen sollte. Was ist FBH?
Ich habe keine weiteren Shellys.
Mal angenommen, ich würde diesen Weg gehen. Ich hätte trotzdem wieder eine Inter-Shelly-Kommunikation.
Die ließe sich (nach meinen naiven Annahmen) nur vermeiden, wenn ich eine Drahtverbindung zwischen Sensor und Add-On auf dem Shelly herstellen würde. Dafür müsste ich ca. 5m überwinden, da das Shelly im Verteilerkasten der FBH=Fußbodenheizung verbaut ist, während im Wohnraum gemessen werden soll. Wie unempfindlich ist denn die Drahtverbindung gegenüber Störungen?
Ok, nun zu den Tests:
Zunächst nochmal getestet:
00:00-23:59 T<26°C -> alle 5min bekommt das Relais den Auftrag sich einzuschalten und das Skript wird aufgerufen.
Nächster Test:
13:15-13:45 T<26°C -> Temperaturanstieg zu Beginn des Intervalls von 20.8 auf 22.1°C. In der Zeit für das Intervall bekommt das Relais nicht einen einzigen Auftrag, genauso wenig wie das Skript aufgerufen wird.
13:55-14:25 -> ob tatsächlich das T-Kriterium weggelassen wird, kann ich nicht sicherstellen, da ich im GUI für die Action zwingend eine Überprüfung der Temperatur drin haben muss, allerdings konnte ich die URL für das Einschalten des Plus löschen... Von daher ist der Erkenntnisgewinn fraglich. Jedenfalls wird auch in dieser Zeit das Relais nicht eingeschaltet und das Skript wird nicht aufgerufen.
00:00-23:59 T<26°C -> jetzt kommen wieder alle 5min die Aufrufe des Skripts. Das Relais wird nicht eingeschaltet, da ich ja zuvor die URL dafür gelöscht hatte.
Ich habe den Eindruck, dass ich mit den Zeit gesteuerten Actions auf dem H&T nicht weiterkomme.
Jetzt nochmal zu meiner Implementierungsidee von vorher.
Temperatur von HTPlus empfangen (wurde als Parameter ans Skript übergeben)
Aktuelle Zeit auslesen
Durch die Liste der konfigurierten Zeitintervalle iterieren.
Wenn passendes Intervall gefunden:
Temperaturbedingung überprüfen
Bedingung trifft zu:
Aktion ausführen (ShellyPlus1 Relais ein- bzw. ausschalten
Wenn man die Temperatur im Plus zum Empfangszeitpunkt nur speichern würde, so könnte man die Aktionen des Plus nutzen für die Definition der Intervalle, dort im jeweiligen Intervall ein Skript auf dem Plus aufrufen mit der jeweiligen Grenztemperatur des Intervals. Dieses Skript vergleicht die übergebene Temperatur mit der zuletzt gespeicherten Temperatur und schaltet lokal das Relais an oder aus.
Pseudocode:
Skriptaufruf im Plus ausgelöst vom HT: Temperatur von HTPlus empfangen -> Temperatur lokal abspeichern
Aktionen auf Plus:
Wenn im Zeitintervall:
Call Skript SwitchOnConditional()
Call Skript SwitchOffConditional()
SwitchOnConditional()
Grenztemperatur fürs Einschalten < gespeicherte Temperatur?
Plus einschalten
SwitchOffConditional()
Grenztemperatur fürs Ausschalten > gespeicherte Temperatur?
Plus ausschalten
Bin nicht sicher, ob das so möglich ist, denn bei der Konfiguration der Actions auf dem Plus stört mich der Abschnitt "Execute when":
Viele Grüße
Thomas
Hallo eiche, erst mal herzlichen Dank für deine ausführliche und kundige Antwort.
Deine Anmerkungen zur Thematik Zeiten/Stromausfall/Zeitserver lassen bei mir den Entschluss reifen, doch einen permanenten Internetzugang zu nutzen. Allerdings möchte ich trotzdem im Normalbetrieb nicht von der Cloud abhängig sein und suche deshalb nach einer lokalen Lösung.
So jetzt zum Debugging. Beim ersten Versuch habe ich anhand deiner Beschreibung das Skript im ShellyPlus1 so eingebaut und in der Action beim ShellyPlusHT zusätzlich zum Einschalten des ShellyPlus1 den Aufruf des Skripts eingetragen.
Die Action im ShellyPlusHT:
pasted-from-clipboard.png
Die Debugausgaben vom ShellyPlus1: pasted-from-clipboard.png
Für den gleichen Zeitraum das Activitylog aus der Cloud für den Shelly HTPlus:
pasted-from-clipboard.png
Ergebnis dieses Tests: Der Shelly HTPlus liefert alle 5min Temperatur und Feuchtigkeit. Wie zu sehen ist die Temperatur im Zeitraum konstant. Scheinbar ist bei Einsatz eines Netzteils für den HTPlus die Schwelle von 0,5°C Temperaturänderung nicht relevant!
So, nun ein Test mit einem Zeitintervall von 10:25-10:59 (das Intervall wurde ca. 10:14 in der Action aktiv (ich mache die Änderungen am HTPlus immer über die Cloud, um die Temperaturänderungen zu vermeiden, die beim lokalen Aufwecken über die Taste entstehen würden).
Im Debuglog steht das letzte "htTest wurde aufgerufen" um 10:09:01, also noch zu einem Zeitpunkt, wo das Zeitintervall 00:00-23:59 konfiguriert war. Das Debuglog sieht so aus:
pasted-from-clipboard.png
Das Activitylog des HTPlus zeigt durchaus Aktivitäten:
pasted-from-clipboard.png
... aber es kommt nicht mehr zum Triggern der Action
So wie es aussieht, funktionieren die Actions im HTPlus nicht bzw. nicht korrekt, wenn man Zeitintervalle verwendet, die ungleich 00:00-23:59 sind.
Nur mal nebenbei: was bedeutet dieser Logeintrag im ShellyPlus1:
shelly_notification:163 Status change of switch:0: {"id":0,"temperature":{"tC":38.05,"tF":100.50}}
09:49:05
Wie kann ich weitermachen?
Ich sollte wohl ein Ticket beim Hersteller aufmachen, da die Actions im HTPlus nicht korrekt funktionieren.
Ob und wann das repariert wird, steht in den Sternen, die Actions im HTPlus werden wohl kaum verwendet.
Jetzt geht mir gerade was durch den Kopf, weiß nicht, ob das so oder so ähnlich möglich ist:
- Im HTPlus soll von 00:00-23:59 alle 5min nicht einfach nur ein Skriptaufruf ans Plus1 gesendet werden, sonder ihm wird als Parameter die aktuell gemessene Temperatur mitgegeben.
- Die Auswertelogik verschiebt man ins Plus1.
Nun habe ich keine Erfahrung mit diesen Skripten und wäre auf eure Hilfe angewiesen...
Ich denke, das Skript im Plus1 müsste (Pseudocode) in etwa sowas tun:
Temperatur von HTPlus empfangen (wurde als Parameter ans Skript übergeben)
Aktuelle Zeit auslesen
Durch die Liste der konfigurierten Zeitintervalle iterieren.
Wenn passendes Intervall gefunden:
Temperaturbedingung überprüfen
Bedingung trifft zu:
Aktion ausführen (ShellyPlus1 Relais ein- bzw. ausschalten
Meint ihr, sowas wäre machbar?
Warum stehe ich für meinen Anwendungsfall nicht so auf ein Temperatur-Addon?
Wenn ich es richtig verstehe, würde das am ShellyPlus1 aufgesteckt werden und müsste die Temperatur messen.
Der Ort des ShellyPlus1 ist im Verteilerkasten der FBH, die Temperatur müsste aber in einem anderen Raum gemessen werden. Von daher scheint mir der Ansatz mit dem vom Plus1 getrennten Temperatursensor HTPlus besser geeignet zu sein.
Schon mal vielen Dank fürs fleißige Mitlesen und Kommentieren!
Grüße
Thomas
Hallo Zusammen,
beschäftige mich seit ein paar Monaten mit den Shellyprodukten.
Im Einsatz habe ich ein Shelly Plus H&T und zwei Shelly Plus 1, wobei es hier nur um eines von den beiden Relais geht. Die Firmwareversion für alle Shellys ist die 1.2.2.
Folgende, vereinfachte Aufgabenstellung (es sollen Aktionen für weitere Zeitintervalle und Temperaturen ausgelöst werden):
Das Shelly Plus 1 soll einschalten, wenn im Zeitraum 22:00-22:59 die Temperatur von 22,5°C unterschritten wird.
Im Web GUI (Cloud) des Shelly Plus H&T habe ich deshalb erst mal diese Aktion erstellt:
Name: Switch Shelly on
Time: 22:00-22:59
Condition:
When: Temperature Change,
Condition: less than,
Temperature 22,5,
Repeat When 150
URLs: http://192.168.178.16/rpc/switch.set?id=0&on=true
Ausgangszustand für das Shelly Plus 1: ausgeschaltet
*Ergänzung:* Das Shelly Plus H&T wird per USB versorgt und liefert daher alle 5min ein Update.
Die Aktion wird nicht getriggert, obwohl die Uhrzeit zum Testzeitpunkt im angegebenen Zeitintervall liegt und die vom Plus H&T gemessene Temperatur 21,7°C und damit weniger als 22,5°C gemessen wird.
Ändere ich das Zeitintervall auf 00:00-23:59 wird die Aktion getriggert (Shelly Plus 1 wird eingeschaltet).
Hat hier jemand Erfahrung mit den Actions beim Shelly Plus H&T?
Ich scheine nicht der einzige User zu sein, der das Problem mit nicht funktionierenden Zeitangaben bei den Actions des Plus H&T hat, denn es gab kürzlich ein Thema, auf das es aber keine Antworten durch das Forum gab (Shelly Plus H&T and Shelly Plus 1)
Übrigens gelang es mir mit Szenen meine Problemstellung erfolgreich umzusetzen, was aber keine Lösung ist, da am Standort der Shellys kein permanenter Internetzugang ist.
Viele Grüße
Thomas