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

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

[Blockmove]

@tobi19 said in Fehlerbehandlung httpGet/httPost:

Mit geht es darum, bei einem Timeout keinen expliziten Logeintrag zu bekommen, da mein WLAN leider nicht sehr stabil ist.

Ich schließ mich da einfach mal an.
Mir gefallen die expliziten Logeinträge auch nicht. Egal ob nun Blockly oder Javascript.
Mag vielleicht sein, dass es für Anfänger etwas einfacher ist.
Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.
Gibt es einen Fehlerhandler, dann programmiere ich ihn entsprechend und gut ist's.

[haus-automatisierung]

@blockmove sagte in Fehlerbehandlung httpGet/httPost:

Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.

Und wenn Du nur den Blockly-Baustein nutzt, musst Du vorher gar keine Doku oder Signaturen der Funktionen anschauen.

Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.

[Blockmove]

@haus-automatisierung said in Fehlerbehandlung httpGet/httPost:

Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.
Ich fand eigentlich die Umsetzung des alten request gar nicht so schlecht. Im Script mit try - catch und im Blockly mit dem wählbaren Loglevel.

Vielleicht kannst du ja die interne Fehlermeldung des httpGet deaktivieren und das Blockly so gestalten wie beim request.
Im Script funktioniert ja try - catch heute schon. Nur kommt die interne Fehlermeldung halt immer.

Das ganze ist aber eher ein kosmetisches Thema und aus meiner Sicht keine hohe Prio.

[Blockmove]

@haus-automatisierung said in Fehlerbehandlung httpGet/httPost:

@blockmove sagte in Fehlerbehandlung httpGet/httPost:

Aber wenn ich httpGet das erstemal verwende, dann muss ich mir sowieso die Beschreibung und / oder Beispiele anschauen.

Und wenn Du nur den Blockly-Baustein nutzt, musst Du vorher gar keine Doku oder Signaturen der Funktionen anschauen.

Erstelle gerne einen PR mit Deinem Vorschlag (für JS und neuem Blockly-Code) und dann diskutieren wir gerne die Lösung.

Ich hab dazu mal ein Github-Issue angelegt:
Github Issue

[viper4iob]

Könnte jemand mal einen Code-Schnipsel zur Verfügung stellen, wie man httpGetAsync mit selbst definierten Timeout aufruft und bei nicht erreichen der URL den timeout error mittels .catch() oder await/try/catch abfangen kann, so dass dieser nicht im iobroker log als error auftaucht.
Das wäre super, danke.

[peterfido]

Schnipsel. writeFile gegen eigene Weiterverarbeitung ersetzen

Spoiler

        httpGet( URL, { validateCertificate: false, timeout: 2000, responseType: 'arraybuffer' }, async (err, response) => {
        if (err) {
            console.error(err);
        }
            fs.writeFile(img_path + 'cam4.jpg',  response.data, 'binary', function(err) {
                if (err) {
                    log('Fehler beim Speichern von Bild 4: ' + err, 'warn');
                } else {
                    log('Bild 4 gespeichert.');
                }
            });         
        });

[viper4iob]

@peterfido
Danke für die Rückmeldung.
Es kommt aber auch mit entfernen der zusätzlichen log-Zeilen im Code weiterhin der Standard-Error im Log, wenn das Zielsystem nicht erreichbar ist:

javascript.0	10:14:37.420	error	httpGet(url=http:****************, error=timeout of 3000ms exceeded)

Und genau den will ich los werden.

Alle Varianten, die ich bis jetzt mit httpGet oder httpGetAsync inkl. try/catch, async/await oder .catch() probiert habe, waren erfolglos. Ich bin allerdings auch kein Javascript Profi ;-)

Ich möchte alle 5 Sekunden eine URL abfragen, um Statusdaten zu erhalten, die aber nur für die Visualisierung relevant sind, aber nicht lebensnotwendig.
Wenn das Zielsystem aber mal eine halbe Stunde weg ist, bekomme ich alle 5 Sekunden eine Fehlermeldung, und müllt so das Log zu.

Ich benötige also eine Code-Variante von httpGet oder httpGetAsync, die bei nicht erreichen des Zielsystems keinen Error im iobroker Standard-Log erzeugt und ich den Fehler im Code selbst verarbeiten kann (z.B. nach einer gewissen Zeit erst einen Fehler ausgeben oder das Log-Level festlegen).

[haus-automatisierung]

@viper4iob sagte in Fehlerbehandlung httpGet/httPost:

Und genau den will ich los werden.

Alle Varianten, die ich bis jetzt mit httpGet oder httpGetAsync inkl. try/catch, async/await oder .catch() probiert habe, waren erfolglos.

Aktuell ist es so, dass die Meldung immer geschrieben wird:

https://github.com/ioBroker/ioBroker.javascript/blob/1d1c2c69e12a28dc52527751bc882347005278ee/src/lib/sandbox.ts#L1443

Es ist also egal ob es einen Callback gibt oder mit Promises gearbeitet wird.

@viper4iob sagte in Fehlerbehandlung httpGet/httPost:

Ich benötige also eine Code-Variante von httpGet oder httpGetAsync, die bei nicht erreichen des Zielsystems keinen Error im iobroker Standard-Log erzeugt

Dazu gibt es glaube ich sogar schon einen Feature Request.

[Codierknecht]

@haus-automatisierung sagte in Fehlerbehandlung httpGet/httPost:

Dazu gibt es glaube ich sogar schon einen Feature Request.

https://github.com/ioBroker/ioBroker.javascript/issues/1599

[peterfido]

Das einfachste wäre doch, den Server vorher anzupingen.

[haus-automatisierung]

@peterfido sagte in Fehlerbehandlung httpGet/httPost:

Das einfachste wäre doch, den Server vorher anzupingen.

Nicht jeder Server reagiert auf einen Ping

[BananaJoe]

@peterfido und ping heißt nicht das ein http-Aufruf funktioniert

[peterfido]

Oben steht, dass der Server öfter mal offline ist. Da ist ping meine erste Idee. Ob der Server auf Pings antwortet, weiß ich nicht. Reagiert der Server nicht auf ping, dann evtl. als Ersatz einen httpcheck nehmen.

httpcheck nutze ich auf der Synology, bevor die auf den ioBroker zugreift.

# ===== HTTP-Check statt Ping =====
curl -s --connect-timeout 3 "$BASE/system.adapter.admin.0.alive" > /dev/null || exit 1

Ist allerdings ein Bash-Skript. Das muss für die Zwecke angepasst werden.