Jetzt erkläre mir mal jemand, warum das auf allen bis auf einen PLUS UNI läuft...
Könnte das etwas mit der angeschlossenen Hardware zu tun haben? Hast du an den fehlerbehafteten UNI vielleicht einen "einzigartigen" Sensor angeschlossen, den du an den anderen UNIs nicht verwendest?
Die originale Dokumentation von Shelly.getComponentStatus() kommt auch ohne "Call" aus.
Ja, es ist ja völlig eindeutig. Wenn man die von Shelly selbst veröffentlichten Beispielscripte auf GitHub durchsucht, findet man 15 Aufrufe von Shelly.getComponentStatus - und jeder einzelne davon ist synchron, weil es nun einmal eine synchrone Funktion ist.
Die Antwort vom Support hat halt schon eine starken KI-Geruch. Vermutlich gibt es viele Anfragen zum Thema Asynchronität und da ist es schon plausibel, dass eine KI die vorliegende Frage in den falschen Hals kriegt und KI-typisch noch ein bisschen dazuhalluziniert (und eine kontrollierende Supportperson bräuchte fortgeschrittene Scriptingkenntnisse, um das Problem mit der Antwort zu erkennen).
Falls sich hier tatsächlich eine KI verirrt hat, wäre das auch ein schönes Beispiel dafür, wie eine Support-KI gleich doppelt Schaden anrichten kann. Nicht nur wird ein Kunde mit einer falschen Antwort abgekanzelt - auch das zuständige Produktteam erfährt damit nichts von einem (mit hoher Wahrscheinlichkeit) realen Problem mit dem Produkt.
Du hast natürlich recht und das ist jetzt keine Meisterleistung vom Support.
In Ihrem Skript versuchen Sie, das Ergebnis eines asynchronen Aufrufs (Shelly.getComponentStatus) synchron zu verarbeiten
Das ist in aller Eindeutigkeit falsch. Shelly.getComponentStatus IST ein synchroner Aufruf und muss selbstverständlich auch als solcher verarbeitet werden.
Dies ist jedoch in der Regel nicht möglich und führt zur bekannten Fehlermeldung „Too many scopes removed“.
Auch das ist falsch. Die Meldung "Too many scopes removed" habe ich noch nie gesehen und diese Meldung taucht auch dann nicht auf, wenn man einen asynchronen Call falsch abarbeitet (und Google findet für diese Meldung - abgesehen von diesem Thread - keinen einzigen Treffer).
Ich weiß nicht, wie man da noch einmal nachgreifen könnte, aber das ist schon sehr unbefriedigend...
Meiner Meinung nach ist das ein Fall für ein Ticket an den Support. Sämtliche Beispiele von dir sind völlig in Ordnung und sollten problemlos funktionieren.
Spekulation:
In Firmware 1.5 wurde das Verhalten von let (und const) geändert. Variablen, die mit diesen beiden Keywords definiert werden beachten jetzt den Scope, in dem sie angelegt wurden (und Shelly-Javascript verhält sich damit jetzt in dieser Beziehung wie 'normales' JavaScript).
Für mich sieht es so aus, als ob sich der Interpreter verläuft, wenn let verwendet wird und Sensoren im Spiel sind. Möglicherweise hat die erwähnte Änderung da nicht ganz geklappt.
Du könntest das noch testen, indem du die Variablen mit var anstatt mit let definierst. Aber wie gesagt, für mich ist das eindeutig ein Problem auf der Shelly-Seite.
Genau - für mich als elektrotechnisch Ahnungslosen: nach Einfügen dieser Zeile steht der Switch mit diesem Setup für vier Stunden auf OFF und für den Rest der Zeit auf ON.
Hallo Coloschni ,
Freut mich, dass es nützlich ist.
Um die Schalterlogik umzudrehen, müsste man exakt eine Zeile ins Script einfügen und zwar in der Funktion set:
function set(val) {
val = !val; // <---- Diese Zeile muss eingefügt werden
if (Shelly.getComponentStatus("switch", switchID).output === val) return;
let msg = val ? "ON." : "OFF.";
let flag = val ? sendPowerOn : sendPowerOff;
Shelly.call("Switch.Set", { id: switchID, on: val }, function (res, errc) {
if (errc === 0) {
log("Switch " + switchID + " has been turned " + msg, flag);
} else {
log("ERROR: Switch " + switchID + " could not be turned " + msg, flag);
}
});
}Damit wird EIN auf AUS umgedreht und umgekehrt. In allen anderen Aspekten verhält sich das Script genauso wie vorher.
Ist das das was du wolltest oder habe ich dich falsch verstanden?
Ich habe Version 3.0 des Scriptes mit einigen signifikanten Änderungen und Verbesserungen veröffentlicht. Hier ist das Changelog:
Das Web UI des Scriptes sieht nun so aus:
Das Script ist wie immer auf GitHub zu finden: https://github.com/towiat/spotelly
Für Wünsche, Fragen und Anregungen stehe ich wie immer zur Verfügung...
Du kannst HTTP.GET nicht direkt aufrufen - Aufrufe von RPCs müssen über Shelly.call durchgeführt werden. Mit diesem Code sollte es klappen:
Shelly.call("HTTP.GET", { url: WEBHOOK_URL }, function (res, err) {
if (err) {
print("Fehler beim Senden des Requests: ", err);
} else {
print("Webhook gesendet, Antwortcode: ", res.code);
}
});tvbshelly Ah, thanks for clearing that up - now I can stop worrying about having hallucinations...
Is this about the image in entry #2? Because it displays fine for me:
Wenn das "muss" durch ein "kann" ersetzt wird, passt es.
Nein, die Request ID ist zwingend erforderlich:
Ich glaube, die Verwirrung bei den IDs entsteht dadurch, dass das von thgoebel gepostete curl-Beispiel das JSON-RPC Protokoll verwendet.
In diesem Protokoll muss jedem Request eine (frei vergebbare) ID mitgegeben werden, mit der man - wenn nötig - den Request an den Shelly mit dessen Response abgleichen kann. Diese ID hat aber nichts mit der ID des abgefragten Objekts zu tun. Siehe dazu auch das GetConfig Beispiel aus der JSON-RPC Dokumentation:
{
"jsonrpc":"2.0",
"id": 1, // Das ist die (frei vergebbare) ID des Requests
"src":"user_1",
"method":"Switch.GetConfig",
"params": {
"id":2 // Das ist die ID des abgefragten Switches
}
}Bei HTTP GET requests und auch bei direkten Shelly.Call Abrufen gibt es diese ID natürlich nicht und daher sieht das dort dann auch anders aus...
Ich mache hier routinemäßig immer Anführungszeichen drum, dann muss man nicht nachdenken, ob der Key erlaubt ist oder ggf. nicht
Ich hab's mir eh gedacht, aber der Pedant wollte unbedingt raus 
. Ich überlasse das Anführungszeichenthema der Entwicklungsumgebung - die kümmert sich gern darum...
Bei Shelly.call gibt es auch noch eine Kleinigkeit, der Key id muss in Anführungszeichen:
<Pedantenmodus EIN>
Anführungszeichen sind hier nicht nötig. Bei Attributnamen werden Anführungszeichen nur dann benötigt, wenn der Name nicht den JavaScript-Konventionen für Variablennamen entspricht (z. B. weil er Leerzeichen oder Bindestriche enthält).
<Pedantenmodus AUS>
Zusätzlich zu den geteilten Dokumentationen kannst du einen Shelly mit http://ipdesshelly/rpc/Shelly.ListMethods auch direkt nach den RPCs fragen, die dieses konkrete Gerät unterstützt.
Für eine generalisierte Lösung die alle Möglichkeiten abdecken soll, wäre es vielleicht eine gute Idee, generell das JSON-RPC Protokoll zu verwenden, so wie es in der Dokumentation beschrieben ist: https://shelly-api-docs.shelly.cloud/gen2/General/RPCProtocol.
Ich habe eh nichts Schlechtes über UDP gesagt . Aber ich scheine dich falsch verstanden zu haben - mein Eindruck war, dass du eine direkte Antwort auf das UDP Datagram erwartet hast. Aber wie ich sehe, hat sich das Problem eh schon erledigt...
Warum kommt dann per UDP nix zurück ?
Weil UDP ein verbindungsloses Protokoll ist. UDP-Pakete werden "auf gut Glück" losgeschickt und der Zielrechner kann gar nicht antworten, weil das im Protokoll einfach nicht vorgesehen ist - dass dabei Pakete sang- und klanglos verschwinden können, wird bei UDP bewusst in Kauf genommen.
Der entsprechende WIkipedia Artikel sagt das noch deutlicher:
UDP ist ein verbindungsloses, nicht-zuverlässiges und ungesichertes wie auch ungeschütztes Übertragungsprotokoll. Das bedeutet, es gibt keine Garantie, dass ein einmal gesendetes Paket auch ankommt, dass Pakete in der gleichen Reihenfolge ankommen, in der sie gesendet wurden, oder dass ein Paket nur einmal beim Empfänger eintrifft. Es gibt auch keine Gewähr dafür, dass die Daten unverfälscht oder unzugänglich für Dritte beim Empfänger eintreffen. Eine Anwendung, die UDP nutzt, muss daher gegenüber verlorengegangenen und unsortierten Paketen unempfindlich sein oder selbst entsprechende Korrekturmaßnahmen und ggf. auch Sicherungsmaßnahmen vorsehen.
Wie @AlexAn schon gesagt hat: Wenn du eine gesicherte und verifizierbare Kommunikation brauchst, kannst du UDP nicht verwenden, weil das buchstäblich der Idee von UDP widerspricht.
Und an euch beide: 10 s sind 10000 ms und nicht etwa 6000 ms.
Ich habe keine Ahnung, warum du mir das sagst - ich habe den 6000er Timer aus dem Originalscript übernommen und weder angenommen noch behauptet, dass das zehn Sekunden sind.
Titty-Twister Ah, ok - hab noch mal geschaut und da ist ein kleines Hoppala drin. Ich hab versehentlich den Timer auf 60000 gesetzt - damit würde das Script nur in Abständen von einer Minute laufen. Wenn du willst, kannst du das korrigieren, in dem du Timer.set(60000, true, processTimer); auf Timer.set(6000, true, processTimer); änderst.
Titty-Twister Mein Script wäre als kompletter Ersatz für deine Version gedacht gewesen. Aber wenn das Script von eiche deine Anforderungen erfüllt passt das schon so und ich halte mich raus, um den Thread nicht weiter zu verkomplizieren (ich verstehe aus dem Gesprächsverlauf heraus schon nicht, wie wir jetzt bei boolescher Algebra gelandet sind...).
