Dein Script stammt aus ChatGPT . Mit dem Http Call wird das nicht funktionieren.
Nein, die Zeile
http://192.168.62.17/rpc/script.eval?id=2&code="htTest(${ev.tC})"stammt aus einer Action in meinem Shelly Plus H&T, die alle 5min eine Funktion htTest(Temperatur) in Skript 2 im Shelly 1 Plus mit der Adresse 192.168.62.17 aufruft.
In meiner naiven Vorstellung existiert die Idee, dass man genau sowas eigentlich auch von einem Shelly 1 Plus senden können müsste.
Codehttp://192.168.62.17/rpc/script.eval?id=2&code="htTest(${ev.tC})"Wenn dein Action auf ein Script verweist das auf dem selben Device ist, darf die IP nicht von sich selbst sein.
Dann muss die IP: 127.0.0.1 genommen werden.
Das Shelly Plus H&T hat die Adresse 192.168.62.15. Dort sende ich die Aktion an das ShellyPlus1 mit Adresse 17.
Jetzt will ich von einem Shelly Plus 1 auf Adresse .16 was an die .17 senden.
Übrigens funktioniert dein Code von oben umgesetzt auf meine Anwendung schon grundsätzlich, ging recht flott.
Vielen Dank Viedotraum für deine schnelle und ausführliche Antwort.
Dein Code deckt sicherlich meinen Anwendungsfall ab und ich werde ihn erstmal so für meine Thematik umsetzen.
Allerdings scheint es noch eine wesentlich einfachere Möglichkeit für die Kommunikation zu geben, wie die Actions zeigen, nur weiß ich leider nicht, wie ich so eine Action im Skript schreiben kann. Aber vielleicht kann mir das ja noch jemand schreiben...
Ich möchte von einem ShellyPlus1 auf einen anderen ShellyPlus1 Daten übertragen. Ich stelle mir das so vor wie mit den Actions, die man z.B. in einem ShellyPlusHT aktivieren kann und damit eine Funktion auf anderen Shellys aufrufen kann.
Funktionierende Beispiel:
Action auf HTPlus1: http://192.168.62.17/rpc/script.eval?id=2&code="htTest(${ev.tC})"
Dies führt auf dem ShellyPlus1 zum Aufruf der Funktion htTest:
function htTest(Temp)
{
console.log ("Temp:"+Temp);
}
Jetzt möchte ich aber einen ähnlichen Aufruf (für das Beispiel hier der gleiche Aufruf htTest(Temp)) von einem Skript auf einem anderen ShellyPlus1 aus auslösen.
Leider habe ich hierfür kein Beispiel im Forum gefunden. Ich habe mich etwas rangetastet mit diesem Code-Schnipsel für das sendende ShellyPlus1:
function callOtherShelly()
{
console.log ("Shelly.call ...");
try{
Shelly.call('http.get', {url: 'http://admin:@192.168.62.17/rpc/script.eval?id=2 & code="htTest(21.5)"'});
}catch(e){print(e);}
console.log ("... Shelly.call");
}
Der Aufruf von callOtherShelly() führt im Debuglog des SenderShelly zu:
shos_rpc_inst.c:243 script.eval via WS_in 192.168.62.2:63021
Shelly.call ...
shelly_ejs_rpc.cpp:41 Shelly.call http.get {"url":"http://admin:@192.168.62.17/rpc/script.eval?id=2 & code=\"htTest(21.5)\""}
... Shelly.call
shos_rpc_inst.c:243 http.get via loopback
shelly_http_client.:308 0x3ffdfc48: HTTP GET http://admin:@192.168.62.17/rpc/script.eval?id=2 & code="htTest(21.5)"
shelly_http_client.:611 0x3ffdfc48: Finished; bytes 0, code 0, redir 0/3, auth 0, status -1: Connection error: -14
Beim EmpfängerShelly gibt es keinen Debuglogeintrag.
Ich hoffe, die Idee für das was ich machen möchte, kommt rüber.
Jetzt wäre es super, wenn ich etwas Hilfe bei der Überwindung der Skripthürde bekommen würde.
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:
Der Inhalt kann nicht angezeigt werden, da Sie keine Berechtigung haben, diesen Inhalt zu sehen.
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...
Für die Verarbeitung von eintreffenden Nachrichten sind ebenfalls zu registrierende callback Funktionen als MQTT Subscriber oder HTTPServer Endpoints geeignet.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.
Im Ernst: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.
Alles anzeigenDafü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.
Alles anzeigenTemperatur 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:
Die Debugausgaben vom ShellyPlus1:
Für den gleichen Zeitraum das Activitylog aus der Cloud für den Shelly HTPlus:
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:
Das Activitylog des HTPlus zeigt durchaus Aktivitäten:
... 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