Beiträge von akreienbring

    Habe eine Frage zu Sommer- / Winterzeit.

    Auch ich erzeuge mit dieser Funktion verschiedene Date / Time Formate:

    function getCurrentDateTime(nType, nDateTimeInput) {
     const nCurrentDateTime = (Shelly.getComponentStatus("sys").unixtime + 2 * 3600) * 1000;

     let nDateTime = nDateTimeInput;  
     if(nDateTime == 'undefined') nDateTime = nCurrentDateTime;
     const dDateTime = new Date(nDateTime);

     switch(nType) {
       case 1:
         return nCurrentDateTime; //return as number
         break;
       case 2:
         return dDateTime; //return as date
         break;
       case 3:
         return dDateTime.toISOString(); //return as string
         break;
       case 4:
         return dDateTime.toISOString().slice(0,10) + ' ' + dDateTime.toISOString().slice(11,19); //return date and time
         break;
       case 5:
         return dDateTime.toISOString().slice(11,19); //return only time
         break;
       default:
         log('undefined DateTime Type: ' + nType);
         return 'undefined';
     }
    }

    Problem: Das stimmt nur im Sommer :-) Also während der Sommerzeit. Hat jemand eine Idee wie die Umschaltung automatisch berücksichtigt werden kann?

    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:

    _[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.

    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.

    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 :cursing:

    Vielen Dank vorab an die Experten.

    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?