Log-Level bei httpGet Block einstellbar

[LastPerfectTobi]

Timeouts die beim neuen httpGet Block entstehen werden immer als Error im Log aufgeführt.

Wäre es möglich den Log-Level (Info/Warn/Error/Ohne) einstellbar machen?

[VierlingMt]

Timeout auf 0ms stellen hat bei mir als Workaround funktioniert...

[klein0r]

@VierlingMt Damit ist der Timeout aber komplett deaktiviert und der Prozess wartet ggf. ewig auf ein Ergebnis

[zaphod2]

Wie kann man dann die Fehlermeldung vermeiden und ob es dann auch Fehlerfrei funktioniert? Selbst unter 8.6.0 ist die Fehlermeldung immer noch da.

[tobi119]

Feature Request für Fehlerbehandlung

Beim Abfragen von Tasmota/Shelly/.. Devices, welche über das unstabile WIFI im Netzwerk sind stören die vielen Fehlermeldungen im LOG bei Nichterreichbarkeit. Das Fehlerhandling, welches scheinbar intern erfolgt, sollte beeinflussbar oder für explizite Programmierung abschaltbar sein..

// 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); 
}

Mit dem Code-beispiel ist es leider nicht abzufangen 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%208, 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, vermutlich weil bereits intern abgefangen.

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

Danke

[klein0r]

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

Das ist so gelöst worden, da Blockly ja beispielsweise auch Code generiert, welcher keine Fehlerbehandlung im Standard hat. Die Leute sind jetzt oft schon überfordert und wenn einfach "gar nichts" passiert und der Callback nicht aufgerufen wird (ohne einen Fehler im Log) muss man noch mehr erklären.

Warum stört Dich der Fehler im Log? Der Timeout doch ein Fehler.

[tobi119]

Hallo Mathias, für Blockly sehe ich dies durchaus als richtige Vorgehensweise. In Javascript suche ich nach einer erweiterten Möglichkeit, lerne JS aber selbst erst z.T. anhand von Blockly. Vielleicht gibt es hier auch einen Tipp, wie ich es anders programmieren kann und die Timeout Meldung nur im Debug sehe.

Da ich viele Devices abfrage und vielleicht auch kein optimales WLAN überdecken diese "Zyklischen" Fehlermeldungen alle anderen Meldungen, die dann doch evtl. wichtig sind.

[mcm1957]

Ich möchte da auch meinen Senf dazu geben. Wenn der User eine eigene Fehlerbehandlung einsetzt dann sollte es seine Sache sein ob etwas gelogged wird. Es kann ja gut sein, dass z.B. ein Gerät offline ist und man nicht alle x Sekunden / Minuten einen Log haben will.

Ergo: Es ist OK und sinnvoll dass was gelogged wird wenn der User "nichts" tut. Damit ist auch Blockly abgedeckt. ABER der User sollte eine Möglichkeit haben sich selbst um die Fehlerbehandlung zu kümmern, sprich es so einzurichten dass der java-script Adapter nichts von sich aus logged. Ob das schon durch den Einsatz von try/catch or via callback erfolgt oder ob man dazu eine eigne Option / Aufrufvariante vorsehen muss ist eine Frage der Implementierung.

Ich muss mich daher diesem Issue und der auch iM Forum öfter schon aufgetretenen Forderung eine Lösung anzubieten keinen Fehler zu loggen anschließen.

[Diginix]

Persönlich fände ich es auch schöner wenn man Einfluss auf den Loglevel hat. So wie beim alten Baustein.

[klein0r]

Persönlich fände ich es auch schöner wenn man Einfluss auf den Loglevel hat.

@Diginix Du weißt schon was die Auswahl dort bewirkt hat? Da gab es einfach nur eine zusätzliche Logausgabe was abgefragt wird. Mit dem Loglevel der Abfrage selbst hatte das nichts zu tun

https://github.com/ioBroker/ioBroker.javascript/blob/53e420de726936ed5fb2d0eb31a6b4dfc6089593/src/public/google-blockly/own/blocks_action.js#L739-L744

[klein0r]

für Blockly sehe ich dies durchaus als richtige Vorgehensweise. In Javascript suche ich nach einer erweiterten Möglichkeit, lerne JS aber selbst erst z.T. anhand von Blockly. Vielleicht gibt es hier auch einen Tipp, wie ich es anders programmieren kann und die Timeout Meldung nur im Debug sehe.

Blockly macht ja nichts besonders - dort wird auch einfach nur JavaScript programmiert. Das Script weiß am Ende nicht, ob der Code mit Blockly generiert wurde oder von dir programmiert wurde. Daher kann man das auch nicht unterscheiden.

Es ist OK und sinnvoll dass was gelogged wird wenn der User "nichts" tut. Damit ist auch Blockly abgedeckt.

Also willst Du ein zusätzliches Flag in den Optionen haben um explizit Log-Meldungen abzuschalten? Anders ist es nicht lösbar denke ich.

[tobi119]

Also willst Du ein zusätzliches Flag in den Optionen haben um explizit Log-Meldungen abzuschalten? Anders ist es nicht lösbar denke ich.

Ja, das Flag ist wünschenswert, auch wenn es dann im Blockly zu einer Checkbox führt.

[mcm1957]

remark from #1716:

if an error occurs in httpPost, the internal function always generates a log entry. all other log messages from httpPost depend on "sandbox.verbose" maybe it's possible to make errors also depend on that variable.