Beiträge von akreienbring

Tja, du Glücklicher! Bei mir wurden die Shellies nicht einmal vom Script Editor gefunden. Ich glaube, dass die VSCode Erweiterung nicht weiterentwickelt wurde und daher möglicherweise mit der aktuellen Firmware nicht mehr funktioniert.

Zitat

verweigert sich Shelly (noch) hartnäckig...

Hast du dir mal Script.eval angeschaut?

Ich geselle mich zur Gruppe der "PM Mini Gen3 schaltet sich von selbst ein" leidgeprüften. Ziemlich sicher sind das irgendwelche "Impulse" aus dem Stromnetz. Hab ich jetzt durch einen Gen2 ersetzt.

Mal sehen, ob das wieder vorkommt...

Ohne es versucht zu haben, dennoch meine Gedanken dazu:

Ohne ein übergeordnetes System wird das wahrscheinlich schwierig bis unmöglich. Denn die Frage ist: Wie kommst du an den Code? Der muss entweder geladen werden (REST Zugriffe) auf deine Domain oder von außen geschrieben (Script.PutCode...).

Ein einfaches Laden (wie in HTML / Javascript) sehe ich hier nicht.

Hallo, ich habe in letzter Zeit gute Erfahrungen mit node.js (pur Javascript) gemacht. Die Kommunikation mit den Shellies läuft über die rpc Aufrufe oder über die outbound und inbound Websockets. (Nebst Authenfifizierung, wenn mit Passwort geschützt.

Auf den Shellies lauften Scripte, die dann bei Bedarf auch mit der node.js Lösung Daten austauschen.

Beschreib mir gerne mal, was du brauchst. Evtl. kann ich unterstützen.

Danke! Vielleicht sollte ich dazu sagen, dass die Antwort in meinem speziellen Fall vernachlässigt werden kann. Mir geht's gerade vorallem um das Setzen von Switch / RGBW Werten.

Zitat

Aufrufe möglichst reduzieren. (tlw. machen bei zuvielen Calls die Gegenseite temporär dicht)

DAS stimmt! Ich setze die white, brightness, rgb Werte mit Hilfe von (Javascript) Slidern und übertrage sie direkt an den Shelly. Ohne einen Schutz verweigert der Shelly ruckzuck die Arbeit.

Falls mal jemand das Problem hat: debouncing hilft. Es verringert die Anzahl der Requests an den Shelly.

Hat jemand noch eine Einschätzung zur Performance der verschiedenen Möglichkeiten?

Dies ist zwar nicht wirklich eine Scripting-, sonder mehr eine API Frage. Aber wo wäre sie besser aufgehoben?

Bekanntlich gibt es mindestens drei Wege mit den (Gen2) Shellies zu kommunizieren (RPC Calls auszuführen)

• GET Request
• POST Request
• Websocket

Habt ihr Erfahrung mit der Performance der einzelnen Methoden? Ich kann mir vorstellen, dass ein offener Websockt schneller ist, als einzeln abgesetzt HTTP Requests. Hab's aber eben noch nicht getestet...

Danke vorab

Zum RPC Call Limit gibt es einen Workaround in der Toolbox von Dekat. Er puffert die Calls, wenn nötig.

Hab auf die Schnelle aber nur diesen Beitrag dazu gefunden:

Beitrag

Shelly Script Toolbox _[v1.0]_

Eine universelle Toolbox für Shelly-Skripts.

Wie benutzt man die Toolbox?

Kurzfassung:

• Kopiere einfach den Toolbox-Code ans Ende deines Scripts und definiere eine Main() Funktion über der Toolbox.
• Die Main()-Funktion sollte den Hauptcode enthalten, z.B. das erstellen eines Endlos-Timers Schleife oder eines Ereignis-/Status Handlers. etc.

Beispiel für Call():

• Um das Call() Tool zu verwende kannst du die Call() Funktion einfach wie eine normale Shelly.call() Funktion nutzen.
• Weitere Informationen zur

…

_[Deleted]_

5. Februar 2024 um 17:16

Vielleicht kommst du von da aus weiter.

Hallo, ohne weitere Informationen (was wird wie und wie oft aufgerufen, etc) ist es schwer zu sagen woher der Fehler bei dir kommt.

Ich habe den jedenfalls auch schon gesehen, wenn zuviele GET / POST Requests an den Shelly gesendet werden. Wenn das bei dir auch der Fall ist, dann hilft nur die Requests zu reduzieren / verlangsamen.

Hallo,

da das o.g. Script die Basic Auth verwendet, wird es mit den Digest geschützten Shellies nicht funktionieren. In der von dir verlinkten Doku ist ein Beispiel genannt:

https://github.com/ALLTERCO/gen2-…tp-digest-auth/

Ich habe das vor Kurzem für Node.js implementiert, grundsätzlich sollte das aber auch im Script funktionieren, frisst dort aber eine Menge Ressourcen.

Es geht mir nicht darum Fehler abzufangen. Klar kann ich die fangen und behandeln Aber da ich die Ursache ermitteln will, ist das sogar eher kontraproduktiv. Das oben beschriebene Vorgehen funktioniert übrigens tadellos.

Ich "überwache" (bei mir ist eine Node.js App) derzeit 8 Shellies. Mit dem UDP Protokoll kann man prima den Shelly ermitteln (IP Adresse) der logged. Wenn ein Script stoppt, wird die (zuvor gepufferte) Fehlermeldung mir als Message gesendet.

Das Hauptproblem aus meiner Sicht: Man bekommt die Fehler nicht mit. Ein Script wird auf Grund eines Fehlers gestoppt. Und wenn du nicht gerade am Rechner sitzt, verschwindet die Information über die Ursache im Datennirwana.

Siehe oben: Eine Anfrage beim Shelly Support dazu blieb unbeantwortet

Ja, eine solche Console habe ich auch. Und ich werde mal mit folgender Idee starten: Wenn man sich den output im Fehlerfall anschaut

78654 2095288.286 101 2|Uncaught TypeError: Assignment to a constant
78655 2095288.286 101 2|at counter += 1;
78656 2095288.288 101 2|^
78657 2095288.290 101 2|in function called from system
78658 2095288.291 1 4|' 
78659 2095288.292 1 1|shelly_user_script.:236 type_error: Error in EjsCall
78644 2095268.106 1 2|shelly_notification:162 Status change of script:1: {"id":1,"running":false}

dann ist die letzte Zeile anscheinend die einzige, über die man auf das fehlerhafte Script schließen kann.

Wenn die also kommt, Script ID merken und alle Zeilen darüber, die '2|' enthalten, als Fehler Beschreibung betrachten. Wobei ich immer noch gerne wüsste, was die Zahlen bis zum '|' bedeuten.|

Hallo,

hier:https://shelly-api-docs.shelly.cloud/gen2/General/DebugLogs/ ist beschrieben was ein Shelly so bisweilen (z.b. über UDP) logged.

Frage1: Kann man dem irgendwie entnehmen welches Script im Fall eines Fehlers diesen verursacht hat?
Frage2: Was bedeuten diese Einträge... z.B.: 66 366.319 2 2|? Die werden in unter 'Diagnostics' nicht angezeigt. Aber hat das irgendeine Bedeutung?

Grund der Frage: Ich würde gerne jede log message (insbesondere Fehler) einem Script zuordnen. Eine Anfrage beim Shelly Support dazu blieb unbeantwortet

Vielen Dank vorab an die Experten.

Hallo, hat das noch jemand bekommen? Klingt mir nach Phishing!

Absender ist:

aber das heißt ja evtl. nur, dass es clever gefaked wurde.

Ist immernoch aktuell! Nur, daß man die Einstellung mittlerweile auch über die App ändern kann.

Also gut, da hat sich wohl irgendwann mal was geändert. Das Beispiel funktioniert so nicht mehr.

Wer mehr wissen will:

https://github.com/ALLTERCO/gen2-sample-code/issues/4

Hallo, zur eigentlichen Frage: Wenn in deine Bauform ein Shelly reinpasst, dann ist die nahe Steckdose von Vorteil, weil die eine neutrale Leitung hat (blauer Draht). Die brauchst du, um den Shelly mit Strom zu versorgen).

Die meisten (alten) Gebäude haben diesen Neutralleiter nämlich leider nicht bei den Schaltern.

Und was Matter angeht: Wie ich das verstanden habe, hat sich Allterco für die 'Matterbridge' entschieden. Heißt für mich, dass die Geräte (auch Gen3) Matter nicht nativ unterstützen, sondern die Bridge unterstützen. Vorteil: Das kann dann per FW Update auch für ältere Geräte nachgerüstet werden.

Siehe auch Matter Support aktuelle Situation bei Shelly

und hier: https://github.com/Luligu/matterbridge-shelly

Oder gibt es dazu was Neues?

Hallo Shelly Freunde,

kann jemand was dazu sagen, ob die Shelly Authentifizierung noch so funktioniert, wie sie offensichtlich mal funktioniert hat?

Dokumentiert ist das hier: https://shelly-api-docs.shelly.cloud/gen2/General/Authentication

Und ein 3 Jahre altes Beispiel von Allterco gibt's hier:https://github.com/ALLTERCO/gen2-sample-code

Ich hab das Beispiel implementiert, aber ein mit Passwort geschützter Shelly authentifiziert mich mit der angegebenen Methode einfach nicht. Auch nach dem Senden der Credentials (wie dokumentiert) erhalte ich weiter den Status 401 (unauthorized).

Ich habe die Changelogs durchsucht, aber nichts gefunden

Firmware ist die aktuelle 1.4.2 und implementiert hab ich mit node.js 20 und Javascript.