Weihnachtsangebot 2025! 🎄

[OliverIO]

@fichtenmoped82

Wahrscheinlich ist die Fehler Ausgabe direkt in HTTPget im JavaScript Adapter eingebaut worden.
https://github.com/ioBroker/ioBroker.javascript/blob/840d03855636c4271971afc202532d008c22d264/lib/sandbox.js#L1263

Im Zweifel, wahrscheinlich nur wenn du axios direkt verwendest.

Du kannst ja ml ein issue anlegen. Evtl. wird eine Option eingeführt
Bei der man diese fehlerausgabe unterdrücken kann und man selbst err auswerten muss.

[fichtenmoped82]

@samson71 Danke für den Vorschlag: Ja, so einen ähnlichen Workaround mache ich ja bereits mit dem Lichtsensor. Derzeit habe ich dort keine Steckdose mit Leistungsmessung angeschlossen.

Ich hatte mich allerdings gefragt, ob es eventuell eine elegante codebasierte Lösung statt eines Workarounds gibt.

[OliverIO]

@fichtenmoped82

Also besser ist natürlich die Ursache abzustellen, da du aber nichts dazu geschrieben hast, gehe ich davon aus, dass du weißt, warum das Gerät irgendwann nachts nicht erreichbar ist,
Das ist grundsätzlich schon okay Ist wenn dieser entsteht, du ihn aber nicht im log stehen haben möchtest.

[fichtenmoped82]

@oliverio Danke, der Weg mit dem Issue und der Option wäre vermutlich eine Möglichkeit.

Axios direkt zu verwenden übersteigt vermutlich meine Möglichkeiten ;)

[Samson71]

@fichtenmoped82
Code kann ggf. die Meldung ausschalten. Das wäre die Richtung von @OliverIO .
Ein stoppen des sinnlosen Traktierens des WR mit Abfragen während der Nacht wirst Du damit nicht erreichen. Ich würde eher das Unterbinden als Wert auf das Ausschalten der "hässlichen" Fehlermeldungen zu legen. Das ist doch nur Kosmetik und behebt das Problem der unnötigen/sinnlosen Abfrage nicht.

[fichtenmoped82]

Ok danke Euch, dann nutze ich den Lichtsensor weiter um die Abfragen nur dann durchzuführen, wenn der Lichteinfall den Wechselrichter versorgt und er erreichbar ist.

[OliverIO]

@fichtenmoped82

HTTPget verwendet axios und reicht die Optionen weitgehend 1:1 durch.

https://axios-http.com/docs/example

[MartinP]

Klammern könnte man das dadurch, dass man den Wechselrichter nur anspricht, wenn er per Ping erreichbar ist..

[Samson71]

@martinp sagte in HttpGet Balkonkraftwerk => Nachts Errors in Protokoll:

dass man den Wechselrichter nur anspricht, wenn er per Ping erreichbar ist..

Auf die Idee kam er in seinem Eröffnungspost auch schon selber.

@fichtenmoped82 sagte in HttpGet Balkonkraftwerk => Nachts Errors in Protokoll:

Ist aber genauso wie ein vorheriger Ping o.ä. auf den Webserver irgendwie keine schöne Lösung...

[MCU]

@fichtenmoped82 Versuche mal das? Timeout abfangen

httpGet('http://192.168.178.58:8050/getOutputData', { timeout: 2000 }, (err, response) => {
    if (err) {
        if (err.code === 'ETIMEDOUT') {
            // Prüfe Bedingungen, die Anzeige willst du ja nicht
            // console.error("Timeout-Fehler: Die Anfrage hat zu lange gedauert.");
        } else {
            console.error("HTTP-Fehler:", err.message);
        }
        // Setze den Zustand auf 0 bei Fehler
        setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W' /*Current Combined Power W*/, 0);
    } else if (response.statusCode == 200) {
        try {
            const resObj = JSON.parse(response.data);
            setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W' /*Current Combined Power W*/, resObj.data.p1 + resObj.data.p2);
        } catch (parseError) {
            console.error("JSON-Parse-Fehler:", parseError.message);
            // Setze den Zustand auf 0 bei einem Parse-Fehler
            setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W' /*Current Combined Power W*/, 0);
        }
    } else {
        console.error(`HTTP-Fehler: Statuscode ${response.statusCode}`);
        // Setze den Zustand auf 0 bei unerwartetem Statuscode
        setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W' /*Current Combined Power W*/, 0);
    }
});

[fichtenmoped82]

@mcu Danke dafür, aber bei "err" handelt es sich bei mir lediglich um einen Datentyp String. Vielleicht hast Du noch eine ältere Codebasis (?) des JS-Controllers? Bin bei Version 7.0.6. Der Code funktioniert also in der Form bei mir so nicht. Ich vermute aber, dass das keinen Unterschied machen wird.

Hintergrund:

Der störende Logeintrag wird meines Verständnisses nach VOR dem Ausführen der Callback-Funktion (alles innerhalb der geschweiften Klammern ab "=>" { ... Callbackfunktion ... }" erzeugt. Dein Vorschlag zielt darauf ab, innerhalb der Callback-Funktion das Fehlerhandling noch etwas detaillierter durchzuführen, aber da ist der Logeintrag leider bereits erzeugt worden...

[opöl]

@fichtenmoped82 ,

bei einer ähnlichen Fragestellung habe ich den Radar Adapter zu Hilfe genommen.
Damit können Geräte (der WR in Deinem Fall) auf Anwesenheit überwacht werden. Dann kannst Du die HTTP Abfrage gegen den WR nur ausführen, wenn Radar für den WR ein „true“ in den zugehörigen DP schreibt.
In etwa so, wie @MartinP weiter oben schreibt, nur ohne Ping. Spart neben den Log Einträgen auch noch Rechenleistung -;)

Gruß