NEWS
HttpGet Balkonkraftwerk => Nachts Errors in Protokoll
-
@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.
-
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. -
@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
-
@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. -
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.
-
HTTPget verwendet axios und reicht die Optionen weitgehend 1:1 durch.
-
Klammern könnte man das dadurch, dass man den Wechselrichter nur anspricht, wenn er per Ping erreichbar ist..
-
@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...
-
@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); } });
-
@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...