Beiträge von mrsample

Zitat

Ich kenne die Cloud-Anwendung deines betroffenen Shelly nicht. Vielleicht erfolgt eine Kommunikation zwischen Shelly und Cloud in kurzen Abständen, was sich an den timestamps ablesen ließe.

Jedenfalls wäre dies eine Möglichkeit, die per Cloud getriggerten Ereignisse zu erfassen und zu analysieren.

Ich nutze nur die Cloud von Shelly und da sendet der Shelly zu jeder vollen Minute einen Status

-> shelly_notification:163 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[9488.639,9425.725,9639.253],"minute_ts":1709198460,"total":74997.625}}

...das ist alles. Ab und an kommt anscheinend auch noch eine Zeitsynchronisation.

Grüße

Kay

Alles anzeigen

Zitat

Auch nicht temporär zum suchen der Fehlerursache?

Der Fehler tritt nicht mehrmals täglich auf...es kann schonmal auch zwei Wochen dauern. Deshalb möchte ich es nicht solange deaktivieren.

Hallo,

und danke für die Überlegungen.

@De kat: Die Dropbox ist natürlich auch noch eine Option, nur, ich vermute eher, dass die calls nicht von meinem Skript kommen, sondern halt irgendwoher. Deine - so wie

ich das verstehe, sendet ja nur, wenn sie kann, weil sie prüft ob noch calls offen sind-richtig?...das haben wir ja auch vor einiger Zeit schon eingebaut(der Tipp kam von dir ).

eiche : Ich werde das mit Scheduled Job mal ausprobieren. Zu deinen vier Fragen zur Fehlereingrenzung...der Shelly kommuniziert mit der Cloud(das will ich auch nicht deaktivieren), der Rest trifft nicht zu.

Was ist eigentlich der Unterschied zwischen einem Scheduled Job und einer Aktion? Leuchtet mir irgendwie nicht ein...

Grüße

Kay

Hallo und danke für eure Denkanstöße,

nachdem mir De Kat am Anfang des Thread den Tipp mit dem try/ catch-Behandlungen gegeben hatte, laufen die Skripte durch. Also auch der Timer führt

den Code von checkWiFiIP() aus. Das Problem ist aber, dass er die von mir gewünschten calls nicht ausführen kann, da irgendwelche 'Geister-Calls' noch offen sind

und somit die zulässige Grenze der Calls gerissen wird. Leider ist es aber eben so, dass ich nicht weiß warum diese existieren, da keine Zeitpläne(diesen sollen gelten

wohl auch als Calls) oder andere Skripte auf dem Shelly laufen. Die Fehlermeldung ist weiter vorne bereits gepostet. Die Vermutung war bisher, dass es manchmal meine Calls

in einen Timeout laufen und somit ein 'Geister-Call' entsteht.

eiche: Ist eine Schedule Job kein shelly-call? De Kat hatte im Verlauf der Unterhaltung das einmal erwähnt. Falls das nicht so ist, wäre das ein gangbarer Weg.

Danke und Grüße.

Kay

Hat keiner noch eine Idee? Kann man eigentlich 'Geister-Calls' löschen?

Grüße

Kay

...und da isser wieder...

Da kürzlich wieder einmal zu viele offene calls hatte(ich habe wirklich keine Ahnung woher die kommen), habe ich nun doch ein reboot eingebaut. Dafür musste der finally-Zweig im try/ catch herhalten.

...

   catch(e)

   {

     print(e);

   }

   finally

   {

     // reboot shelly if to many calls in process

     if(aC > 2) Shelly.call("Shelly.Reboot");

   }

Nun ist es aber eben leider so, dass ich ein reboot auch nur durch einen call aufrufen kann und so kam es wie es kommen musste...er konnte nicht aufgerufen werden, da zu viele calls offen waren.

Habt ihr dazu noch Ideen? Das letzte verfügbare Update habe ich bereits aufgespielt(weil das ja auch mal eine Vermutung war).

Grüße und danke.

Kay

Hallo De kat,

und ein gesundes Neues wünsche ich noch.

Also ich habe die letzten Änderungen auf alle meine Shellys übertragen und nunmehr seit über zwei Wochen keine 'Hänger' mehr

gehabt.

Perspektivisch werde ich aber sicher noch deinen 10 Minuten reboot-Vorschlag umsetzen(kann ja nicht schaden ).

Vielen Dank für deine hilfreichen Tipps.

Grüße

Kay

Zitat

Naja jetzt hast du jedoch den try Block.. ohne den kann sich sowas natürlich nicht selbst beheben.

Ich meine vor dem try/ catch....Aktionen und Zeitpläne laufen nicht. Ich habe nur eine Szene geschalten die auf die Höhe des Überschusses reagiert.

Grüße

Kay

Zitat

Guten morgen,

achten bitte auch darauf, ob sich der Fehler von selbst behebt, vielleicht liegt es nur an einer Störung deines WLANs oder an ner Wartung der Tango API, wobei ich mir sowas kaum als Fehler Quelle Vorstellen kann.

Zu viele Calls bedeut zu viele offene Shelly Calls.... da ist eigentlich nicht viel Spiel für alternative Interpretationen.

Möglich wäre auch ein Shelly FW Fehler, der sich nur nach x https Calls zeigt, denke das nutzt derzeit kaum jemand.

Bei der https Geschickte könne wir noch verschiedene Zertifikat Einstellungen versuchen.pasted-from-clipboard.png

mit diesen hatte ich auch schon rumprobiert(* und null), allerdings mehr in Richtung der Rückantwort von Tago.io. -> ssl_cli.c:2297 0x3ffe6ea4 server did not confirm our fragment length request, disabling

Der Fehler hatte sich in der Vergangenheit nie von selbst behoben. Die reboot-Variante ist sicher der letzte Weg, den ich allerdings nur zur Not gehen möchte. Eigentlich wollt ich ja den Shelly nutzen, um eine effizientere

Ausnutzung meines Überschusses zu nutzen indem ich ein steuerbares Netzteil entsprechend des Überschusses einstelle. Ich dacht mir halt, die Shelly laufen ja sowieso, also können die auch gleich die Arbeit

machen und ich muss nicht noch extra einen ESP damit beauftragen . Tago.io ist nur eine Vorstufe, um ein Gefühl für die ganze Sache zu bekommen.

Grüße

Kay

Guten Morgen ihr beiden,

danke für eure Denkanstöße .

Zum Timeout(ostfriese)...den hatte ich in der Vergangenheit - bevor ich mich ans Forum wendete - Stück für Stück von 2 auf 15 Sekunden erhöht, leider ohne Erfolg. Ich erwähnte ja in meinem

ersten Post zu diesem Thema, dass ich mich immer gewundert habe, warum denn die Werte nicht mehr bei Tago.io ankamen. Meine Erkenntnis war dann, dass das Skript noch lief

aber eben nichts machte(also das extra 'Restart'-Skript garnichts starten konnte!).

Durch die Superidee von De kat mit den try/catch Blöcken hat es nun wenigsten fast eine Woche Daten gesendet.

Zum https...ich bekomme immer diese Antwort vom Tago.io, wenn ich einen Post mit dem Shelly absetze.

ssl_cli.c:2297 0x3ffe6ea4 server did not confirm our fragment length request, disabling
07:02:19

shelly_pm_ade7880.cp:41 ISR0WatchDogCB (1) on the move!
07:02:21

shelly_http_client.:606 0x3ffe77a8: Finished; bytes 342, code 202, redir 0/3, auth 0, status OK

Allerdings bekomme ich das nicht, wenn ich mit Postmann oder 'nem ESP oder so sende! Könnte da vielleicht der Hase im Pfeffer liegen, ich meine das da etwas mit dem Zertifikathandling und Shelly

nicht so funzt?

Ich habe soeben die neue Version des Skriptes auf dem Shelly gestartet...mal sehen, wie lange es läuft...ich melde mich.

Danke

Kay

Guten Morgen,

also jetzt bin ich raus...mit call ist doch shelly.call gemeint oder meint Shelly da etwas anderes.

Außerhalb ist eigentlich nur die callback-Ebene.

Hier ist der gesamte Code, und, es läuft nun ja auch nur noch dieses eine Skript auf dem Shelly, da ich ja das Überwachungs-Skript ausgeschalten habe. Es gibt auch keine Abfragen

von außen an den Shelly.

// Settings
let tago_apikey  = "xxxx"; // Copy from Tago.io
let tago_jsonurl = "https://api.tago.io/data";
let scalfactor   = 100 / 300; // make percent for the dimmer

// handle respons from http.request
function handleResponse(result, error_code, error_message) 
{
    if (error_code === 0)
    {
      if(result.message !== "Accepted")
      {
        print(error_code);
          print(error_message);
          print(JSON.stringify(result.body));
          
        print("Accepted hat nicht gefunzt");
      }
    }
}

// Check ip from status
function checkWifiIP() 
{
    try
      {
        let wifi = Shelly.getComponentStatus("wifi");
        
        if(wifi && wifi.status === 'got ip') 
        {
            let status = Shelly.getComponentStatus("em", 0);
            let differ = 0; // add 20.11.23
            //print(JSON.stringify(status));
            /*
            {"user_calibrated_phase":[],"total_aprt_power":143.732000,"total_act_power":85.644000,"total_current":0.616000,"n_current":null,
            "c_pf":-1,"c_aprt_power":16.100000,"c_act_power":5.600000,"c_voltage":233.400000,"c_current":0.069000,"b_pf":-0.710000,
            "b_aprt_power":48.700000,"b_act_power":29,"b_voltage":233.400000,"b_current":0.209000,"a_pf":-0.750000,"a_aprt_power":79,
            "a_act_power":51.100000,"a_voltage":233.400000,"a_current":0.338000,"id":0}
            */ 
            // add 20.11.23 tbd
            if(status.total_act_power < 0 && status.total_act_power > - 600) 
            {
              //HLG 320 has only 300W
              if(status.total_act_power > - 300) differ = status.total_act_power * (- 1) * scalfactor;
              else differ = 300 * scalfactor;
              //print(differ);
            }
            else differ = 0;
            
            // Create JSON
            let tago_json = 
            [
              {
              "variable": "total_act_power",
              "value"   : status.total_act_power,
               "unit"    : "W"
              },
              {
              "variable": "dimmer_setpoint",
                            "value"   : differ,
                            "unit"    : "%"
              }
            ];            

            let tago_header = 
            {
                method : "POST",
                url    : tago_jsonurl,
                body   : tago_json,
                headers: 
                {
                    "Authorization": tago_apikey,
                    "Content-Type":"application/json",
                }, //Default Timeout is 15 sec...
            };    

            Shelly.call("HTTP.Request", tago_header, handleResponse);// Shelly.call HTTP.Request  
        };
    }
    catch(e)
    {
      print(e);
    }
}

var interval = 2 * 60 * 1000;  //Define timespan: minutes * 60 sec * 1000 milliseconds
var tH1 = 0;                   //Global Timer Handler

checkWifiIP();
if(!tH1) tH1 = Timer.set(interval, true, checkWifiIP);

Grüße

Kay

Guten Morgen De kat,

nun hab ich wohl den Morgen vor dem Abend gelobt... . Seit dem Wochenende habe ich wieder die gleiche Symptomatik wie ursprünglich beschrieben.

shelly_ejs_rpc.cpp:41 Shelly.call HTTP.Request {"method":"POST","url":"https://api.tago.io/data","body":[{"variable":"total_act_power","....

07:02:36

Error: Error: Too many calls in progress

Das Skript ist ja nun auf nur noch einen Call reduziert worden(und das auch nur alle zwei Minuten)...kann es vielleicht sein, dass es noch offene POST-Calls im

Hintergrund gibt, die nicht bei Tago.io platziert worden?

Nach einem Neustart funktioniert wieder alles prima.

Grüße

Kay

Hallo De kat,

also bisher läuft alles ohne Probleme seit Sonntag. Ich habe eben sogar die Überwachungsskripte ausgeschalten.

Danke nochmal.

Grüße

Kay

Hui du bist ja flott. Danke, ich werde es mal einpflegen und berichten.

Einen schönen Sonntag noch.

Grüße Kay

Hallo De kat,

danke für die rasche Antwort . So viele calls habe ich garnicht oder sind damit alle calls aus allen Skripten gemeint?

Das mit den try/ catch hatte ich bisher noch garnicht auf dem Schirm, danke. Meinen Code hatte ich nicht hineinkopiert, da das Skript ja auch nach dem

starten nicht mehr funktioniert, sondern erst wieder nach einem Reboot des Shelly. Der Code wird doch zur Laufzeit kompiliert-oder ist das bei der Javamischung

von Shelly anders?

Vielen dank für den Einblick in deine Toolbox und dein Angebot nehme ich gerne war, dass du mal über den Code schaust, vielleicht entdeckst du ja etwas.

Einen schönen Abend noch.

Kay

let interval     = 2 * 60 * 1000; // Define timespan: minutes * 60 sec * 1000 milliseconds

function checkWifiIP() 
{
    Shelly.call("WiFi.GetStatus", null, function (WifiStatus) 
    {
        if (WifiStatus.status === "got ip") 
        {
            let Shellystatus = Shelly.getComponentStatus("switch", 0);
      
            // Create JSON
            let tago_json = 
            [
                  {
                  "variable": "bpower",
                  "value"   : Shellystatus.apower,
                  "unit"    : "W"
                  },
                 {
                  "variable": "bpower_temperatur",
                  "value"   : Shellystatus.temperature.tC,
                  "unit"    : "°C"
                  }
            ];

            let tago_header = 
            {
              method : "POST",
              url    : tago_jsonurl,
              body   : tago_json,
              headers: 
              {
                  Authorization: tago_apikey,
                  'Content-Type': "application/json",
              },
              timeout: 15,
            };    

            Shelly.call("HTTP.Request", tago_header, handleResponse);// Shelly.call HTTP.Request       
        }
    });// Shelly.call WiFi.GetStatus
}

Timer.set(interval, true, checkWifiIP);

Hallo in die Runde,

ich habe einige Shelly pro/ plus-Geräte im Einsatz auf denen verschieden Skripte laufen. Diese fragen den Shelly auf dem sie laufen in regelmäßigen Zeitabständen über
Shelly.call nach dem Status und die gesammelten Werte werden dann nach Tago.io gesendet. Damit mir die Skripte nicht abstürzen, wenn mal keine Wifi-Verbindung steht

habe ich sicherheitshalber eine Abfrage davor gebastelt.

Shelly.call("WiFi.GetStatus", null, function (WifiStatus)

{

if (WifiStatus.status === "got ip")...

...und noch zur Sicherheit - falls das Skript aus einem mir unbekannten Fall abschmiert - ein zweites Skript, was alle zwanzig Minuten schaut, ob das erste Skript noch läuft.

Soweit so gut . Die ganze Sache funzt eigentlich ganz gut, bis mir irgendwann auffällt, dass keine aktuellen Werte mehr bei Tago.io ankommen.

Ich gehe also auf die Weboberfläche des entsprechenden Shelly und schaue, ob die Skripte noch laufen. Das tuen sie dann auch, aber sie arbeiten den Code nicht mehr ab!!

Im log sieht das dann so aus:

shelly_notification:163 Status change of switch:0: {"id":0,"aenergy":{"by_minute":[0.000,0.000,0.000],"minute_ts":1701427199,"total":624.311}}

11:40:00

shelly_ejs_rpc.cpp:41 Shelly.call WiFi.GetStatus null

Wenn man das Skript anhält und wieder neu startet ändert sich auch nichts. Der Shelly tut so, als ob er das Skript abarbeitet. Ich glaube in der Vergangenheit stand auch manchmal

soetwas wie -> 'to many shelly.calls' open oder so ähnlich.

Führe ich dann einen Reboot durch, funktioniert wieder alles wie es soll.

shelly_notification:163 Status change of switch:0: {"id":0,"voltage":115.7}

11:45:29

shelly_http_client.:606 0x3ffe2abc: Finished; bytes 342, code 202, redir 0/3, auth 0, status OK

Hat jemand ähnliche Erfahrungen gemacht? Woran kann das liegen?

Ich habe die aktuellste Firmware auf allen installiert.

Danke und Grüße.

Kay

Guten Morgen,

ok, vielen Dank ...dann muss ich mir wohl etwas einfallen lassen.

Grüße

Hallo,

ich habe hier im Forum in einigen Beispielen gesehen, dass etwas in die console.log(wie anscheinend jede normale Print-Anweisung auch) geschrieben

wird. Wenn man die Konsole in der Skriptansicht offen hat, kann man sie ja prima sehen, jedoch nicht, wenn das Skript mitten in der Nacht abstürzt.

Aus der Doku werd ich irgenwie nicht schlau...muss man da wirklich eine WS-Verbindung aufbauen und immer lauschen?...geht das nicht über eine http-Abfrage

oder ähnliches?

Über Hinweise wäre ich dankbar.

Grüße