Jahresrückblick 2025 – unser neuer Blogbeitrag ist online! ✨

[arniworx]

@tt-tom
mit systemseitig meine ich den fehler, den iobroker(bzw. der javascript adapter) selbst in das log schreibt.

[tobi19]

@arniworx sagte in Fehlerbehandlung httpGet/httPost:

@tt-tom
mit systemseitig meine ich den fehler, den iobroker(bzw. der javascript adapter) selbst in das log schreibt.

Ich pusche mal diese Frage:
Beim Abfragen von Tasmota/Shelly/.. Devices, welche über WIFI im Netzwerk sind möchte ich nicht bei jeder mislungenen Abfrage einen ERROR im Log sehen.

[bahnuhr]

@tobi19
zeige das Script

[OliverIO]

@arniworx

es gibt zwei Kategorien von Fehlern
1)
Fehler, die mit try/catch abgefangen werden können wie bspw time out Fehler
2)
Fehler, die durch Auswertung HTTP Codes wie bspw 500+ erzeugt werden können

Der erste kann wie schon erwähnt durch try catch abgefangen werden
Der Zweite durch Auswertung des http Codes

[tobi19]

@bahnuhr sagte in Fehlerbehandlung httpGet/httPost:

zeige das Script

    // Tasmota per RestAPI auslesen und auswerten
    try {
        httpGet('http://' + IP + '/cm?cmnd=status%208', { timeout: 5000, responseType: 'text' }, async (err, response) => {
            if (err != null) {
                console.log(err);
            }
            if (response.statusCode == 200) {
                let Power = getAttr(response.data, 'StatusSNS.ENERGY.Power');
                let Energy =getAttr(response.data, 'StatusSNS.ENERGY.Total');
                //console.log(Power + '| ' + Energy)

                setState( dp + Objekt + P, Power,true); 
                update_Total(Objekt, Energy / Scale);
            };
        });
    } 
    catch (e) { console.warn(e); 
    }

Ich bekomme im Log:
2024-08-18 15:43:25.004 info script.js.Test.Test_TV: timeout of 5000ms exceeded
2024-08-18 15:43:25.004 error script.js.Test.Test_TV: httpGet(url=http://192.168.178.133/cm?cmnd=status 8, error=timeout of 5000ms exceeded)

Die Info durch meine if abfrage ausgelöst, den Error intern durch den javascript Adapter ausgelöst.
try/catch sollte eine warning generieren, die aber nicht im Log steht.

Hier fehlt mir Wissen oder intern wird ein Fehler ins Log geschrieben, den ich nicht verhindern kann.

Danke

[Ro75]

@tobi19 sagte in Fehlerbehandlung httpGet/httPost:

2024-08-18 15:43:25.004 info script.js.Test.Test_TV: timeout of 5000ms exceeded
2024-08-18 15:43:25.004 error script.js.Test.Test_TV: httpGet(url=http://192.168.178.133/cm?cmnd=status 8, error=timeout of 5000ms exceeded)

Ich hänge mich mal dran. Ich habe bei httpget auch Fehlermeldungen. Wenn ich selbst keine Fehlerbehandlung eingebaut hätte, wäre das ja ok. Aber wenn ich eine Fehlerbehandlung drin habe, dann soll doch bitte die interne Meldung nicht ins Protokoll.

Ro75.

[mcm1957]

@ro75 said in Fehlerbehandlung httpGet/httPost:

@tobi19 sagte in Fehlerbehandlung httpGet/httPost:

2024-08-18 15:43:25.004 info script.js.Test.Test_TV: timeout of 5000ms exceeded
2024-08-18 15:43:25.004 error script.js.Test.Test_TV: httpGet(url=http://192.168.178.133/cm?cmnd=status 8, error=timeout of 5000ms exceeded)

Ich hänge mich mal dran. Ich habe bei httpget auch Fehlermeldungen. Wenn ich selbst keine Fehlerbehandlung eingebaut hätte, wäre das ja ok. Aber wenn ich eine Fehlerbehandlung drin habe, dann soll doch bitte die interne Meldung nicht ins Protokoll.

Ro75.

Wenn das so ist und es dich stört dann erstell doch einen Feature Request sofern noch kein diesbezüglicher existiert - ohne Issue wird sich da nichts ändern. Das Forum ist KEIN Platz um konkrete Verbesserungsvorschläge anzubringen.

[Ro75]

@mcm1957 sagte in Fehlerbehandlung httpGet/httPost:

und es dich stört

ja und es "stört" nicht nur mich. Ein Feature Request werde ich nicht erstellen, da ich in letzter Zeit nur noch negative Erfahrungen auf GIT, speziell im ioBroker-Bereich (Adapter), gemacht habe.

Ro75.

[mcm1957]

@ro75 said in Fehlerbehandlung httpGet/httPost:

@mcm1957 sagte in Fehlerbehandlung httpGet/httPost:

und es dich stört

ja und es "stört" nicht nur mich. Ein Feature Request werde ich nicht erstellen, da ich in letzter Zeit nur noch negative Erfahrungen auf GIT, speziell im ioBroker-Bereich (Adapter), gemacht habe.

Ro75.

Eröffne ein Issue wie ich geschrieben habe. Oder lebe mit dem IST Stand.
Hier rumraunzen bringt niemand was.

Alternativ kannst du natürlich auch einen PR erstellen. Was du für "negative Erfahrungen auf GIT" - ich vermute mal due meinst GitHub - gemacht hast weiß ich nicht. Kannst es ja aber ggF erläutern.

Aber wenn du keinen Feature Request erstellen willst, dann bringt dein Gejammere hier genausoviel wie ein Brief ans Salzamt. Sorry wenn ich so sage: Raunzen ist offenbar einfacher wie konstruktive Vorschläge an der vorgesehenen Stelle ablegen und optimaler Weise an einer Verbesserung mitarbeiten.

[tobi19]

@mcm1957 sagte in Fehlerbehandlung httpGet/httPost:

erstell doch einen Feature Request

gibt es und wurde von mir erweitert, siehe https://github.com/ioBroker/ioBroker.javascript/issues/1599

[mcm1957]

@tobi19 said in Fehlerbehandlung httpGet/httPost:

@mcm1957 sagte in Fehlerbehandlung httpGet/httPost:

erstell doch einen Feature Request

gibt es und wurde von mir erweitert, siehe https://github.com/ioBroker/ioBroker.javascript/issues/1599

DANKE für das Issue. Diese Vorgangsweise finde ich konstruktiv - auch wenn für dich das Problem damit noch nicht aus der Welt geschafft ist. Damit ist das Problem mal erfasst und Klein0r wird sich das auch im Rahmen seiner verfügbaren Zeit ansehen.

Der Issuetitel ist zwar (für mich) nicht gleich klar - weil ein Timeout IST ein Fehler/Warning und das sollte auch gelogged werden. Aber natürlich nur, wenn der User das nichts selbst behandelt. Einfach ausschalten führt dann zu Folgedisussionen - "httpGet funktioniert nicht un leifert mit ein undefined :-)"

[diwoma]

@mcm1957 sagte in Fehlerbehandlung httpGet/httPost:

Der Issuetitel ist zwar (für mich) nicht gleich klar - weil ein Timeout IST ein Fehler/Warning und das sollte auch gelogged werden. Aber natürlich nur, wenn der User das nichts selbst behandelt.

Das stelle ich mir mal automatisch nicht so einfach vor, weil die innere (fehlerwerfende) Methode ja keine Ahnung hat, das der Aufruf durch ein try .. catch gecovert ist.

Kann mir nur vorstellen, dass ein zusätzlicher Parameter (z.b. silentError = false/true) übergeben wird.
Wenn der Parameter auf default=false steht würde der normale Ablauf nicht gestört sein. Und der User, der das wünscht müsste den Parameter explizit auf true schalten.

[haus-automatisierung]

@diwoma Du wirfst gerade zwei Themen zusammen. Die Log-Meldung hat ja erstmal nichts mit einem try/catch oder einer unhandled exception zu tun. Die wird es bei den Varianten mit Callback auch nicht geben. Dann nutze die Varianten mit Promises (also httpGetAsync). Dann kannst mit .catch(..) des Promises arbeiten oder halt mit await und einem try/catch.

[diwoma]

@haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

Die wird es bei den Varianten mit Callback auch nicht geben.

Das habe ich nicht gewusst. Wenn es sowieso schon eine Aufrufmöglichkeit gibt, in der der innere Log-Eintrag unterdrückt wird, ist ja schon alles vorbereitet.
Ist das eine Vorschrift bei Aufrufen mit Callback?

[haus-automatisierung]

@diwoma Die Meldung kommt trotzdem, aber Du möchtest ja die Fehlerbehandlung mit try/catch machen

[diwoma]

@haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

@diwoma Die Meldung kommt trotzdem, aber Du möchtest ja die Fehlerbehandlung mit try/catch machen

Sorry, dann habe ich die Diskussion falsch verstanden.
Ich habe es so gelesen, dass der User die interne Fehlermeldung im Log unterdrücken will, weil er mit seinem Fehlerhandling entscheiden will, ob der Fehler protokolliert werden soll oder nicht, bzw. wie es protokolliert werden soll

[haus-automatisierung]

@diwoma sagte in Fehlerbehandlung httpGet/httPost:

Ich habe es so gelesen, dass der User die interne Fehlermeldung im Log unterdrücken will

Ist ja scheinbar auch der Wunsch. Aber das hat ja erstmal nichts Callbacks oder Promises oder zusätzlichen Try/Catch zu tun.

Die internen Funktionen versuchen einen so gut wie möglichen zu schützen und Abstürze des kompletten Scripts zu vermeiden. Daher wird z.B. auch jede Callback-Funktion wieder innerhalb eines try/catch aufgerufen.

[tobi19]

@diwoma sagte in Fehlerbehandlung httpGet/httPost:

Ich habe es so gelesen, dass der User die interne Fehlermeldung im Log unterdrücken will, weil er mit seinem Fehlerhandling entscheiden will, ob der Fehler protokolliert werden soll oder nicht, bzw. wie es protokolliert werden soll

So war es auch gemeint.

[tobi19]

@haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

Die wird es bei den Varianten mit Callback auch nicht geben. Dann nutze die Varianten mit Promises (also httpGetAsync). Dann kannst mit .catch(..) des Promises arbeiten oder halt mit await und einem try/catch.

Mein Missverständnis liegt wohl in meiner Unkenntnis der Möglichkeiten von Javascript.
Wenn es eine anderen Funktionsaufruf gibt (z.B. httpGetAsync), welche die explizite Fehlerbehandlung erlaubt, ist das mit Blockly unverändert ja prima.
Dann bitte ich als JavaScript Anfänger um Hilfe.
Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.
Einen Code mit httpGetAsync und Promise kann ich leider noch nicht generieren.

Mein Versuch mit

try {
    let response =  await httpGetAsync('http://192.168.178.127/status');
    if (response.statusCode = 200) {
        console.log(response.data);
    }
    else {
        console.log(response.responseTime)
    }
} 
catch (error) {
        console.warn(error);
}

führt auch zu einer implizite generierten Timeout Fehlermeldung.

Danke

[peterfido]

@tobi19 Der Fehler an sich ist ja vorhanden. Wenn das WLAN mies ist, dann den Timeout erhöhen, oder, wenn es regelmäßig auftritt, vorher per Ping checken, ob die Verbindung da ist.