HttpGet Balkonkraftwerk => Nachts Errors in Protokoll

[fichtenmoped82]

Hallo,

ich frage per HttpGet den Wechselrichter apsystems ez1-m ab. Da dieser Mikrowechselrichter erst bei einem gewissen Lichteinfall startet und nicht fremdversorgt ist, antwortet dessen Webserver bei Dunkelheit nicht.

Das wiederum sorgt beim Pollen für hässliche Fehlerlogs, die ich bisher auch mit üblichen Try-Catch-Bemühungen nicht lösen kann und über Nacht das Fehlerprotokoll füllen:

script.js.Balkonkraftwerk: httpGet(url=http://192.168.178.58:8050/getOutputData, error=timeout of 2000ms exceeded)

Hier der ansonsten (im Hellen...) funktionierende Code:

httpGet('http://192.168.178.58:8050/getOutputData', { timeout: 2000 }, (err, response) => {

            if (err) 
            {            
                setState('0_userdata.0.Balkonkraftwerk.Current_Combined_Power_W'/*Current Combined Power W*/, 0);
            }
            else if (response.statusCode == 200) 
            {
                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);
            }
        });

Nach etwas Recherche deutet sich an, dass Try-Catch o.ä. hier deshalb nicht funktioniert, weil die eigentliche Logmeldung innerhalb von HttpGet während der asynchronen Abarbeitung erzeugt wird:

https://www.heise.de/hintergrund/Einfuehrung-in-die-asynchrone-JavaScript-Programmierung-2752531.html

Mit welchem programmiertechnischem Kunstgriff ließen sich die obigen Logeinträge daher vermeiden?

Wäre dankbar für Vorschläge, da meine Javascript-Kenntnisse eher überschaubar sind...

Bisher nutze ich einen ohnehin verfügbaren Lichtsensor als Workaround für die Annahme, wann der Mikrowechselrichter wohl gestartet sein müsste. Ist aber genauso wie ein vorheriger Ping o.ä. auf den Webserver irgendwie keine schöne Lösung...

[Samson71]

@fichtenmoped82
Wie ist der Wechselrichter angeschlossen? Falls per Steckdose dann eine einfache Messsteckdose davor und die erste Leistung als Auslöser für den Beginn der Abfrage nehmen.

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