Verfügbarkeits/Robustheits-Steigerung bei Strom/Internet-Ausfall durch gültige Default-Zeit

[Andrix82]

Bekanntes Problem/Eigenschaft der openDTU ist dass sie ohne NTP Zeit nach Neubestromung keine gültige Systemzeit (1.Jan 1970) hat und nicht mit den WR kommunizieren kann.
Dies mag bei einer openDTU nicht so schlimm sein da reine Monitoring Daten mit schrottigem Zeitstempel recht wertlos sind.
Die openDTU on Battery hat aber weitere Aufgaben, nämlich die Nulleinspeisungsregelung UND das rechtzeitige Abdrehen des WR bevor der Akku unter die konfigurierte Schwelle entladen wird.
Daher würde ich es für den openDTU on Battery branch als wichtig/sinnvoll ansehen nach einer Neubestromung und keinem erreichbaren NTP Server zumindest eine beliebige aber gültige Defaultzeit als Startpunkt zu nehmen um die WR Kommunikation und Nulleinspeisung/Akkumanagement zumindest wieder aufzunehmen!

Sollte sich auch recht schnell und einfach implementieren lassen und kann den einen oder anderen Akku vor einer ungesunden Entladung bis zur BMS Entladeschwelle oder auch kompletten Tiefenentladung retten!

Weiters wäre dann ein recoverable Standalone-Betrieb des Systems ohne Internet damit zumindest denkbar!

Vielen Dank!

[schlimmchen]

Sollte sich auch recht schnell und einfach implementieren lassen

Warum lieferst du dann keinen Pull-Request? 😉

Deine Argumentation macht Sinn. Allerdings muss dann erst noch verstanden werden, warum mit dem Hoymiles nicht gesprochen werden kann ohne gültige Uhrzeit. Das kann ja noch andere Gründe außer "Daten sind dann mit falschen Zeitstempeln verknüpft" haben. Beispielsweise würde es mich nicht wundern, wenn der Wechselrichter schlicht keine Pakete mit zu altem Zeitstempel verarbeitet (der WR hat eine Zeit und die Pakete von der OpenDTU sind super alt, und der WR verwirft sie einfach).

Mach doch bitte ein passenden Issue auf mit einem Feature-Reqest.

[Andrix82]

danke für schnelle Rückmeldung. Ich habe noch keine Build-Umgebung aufgesetzt, wenn da wer vlt. einen Link/Infos hat zu einem Guide wär ich dankbar, wenn die läuft dann könnte ich auch beim Coding mitwirken :) und mit github noch kaum gearbeitet bisher.

blauäugige annahme wäre mal es reicht einen initwert zu ändern oder einzuführen für die Systemzeit.....

Dein Punkt ist natürlich richtig, wenn der Hoymiles die Zeit vlt. persistent speichert und nach einer neubestromung nur eine streng monoton steigende zeit akzeptiert dann bringts auch nix...

gerne stelle ich es etwas anders formuliert als Issue - Enhancement ein ?! präferenz dort deutsch oder english ?

[schlimmchen]

gerne stelle ich es etwas anders formuliert als Issue - Enhancement ein ?! präferenz dort deutsch oder english ?

Darfst du die aussuchen.

Ich habe noch keine Build-Umgebung aufgesetzt, wenn da wer vlt. einen Link/Infos hat zu einem Guide

https://www.opendtu.solar/firmware/compile_vscode/

[Andrix82]

Ich war gestern noch motiviert und hab die Änderung codiert und die precompiled Startzeit funktioniert auch , ABER ich kann es nicht testen weil sowohl mit der Änderung wie auch mit dem unverändert nachgebautem! originalem Repository über VSC etwas nicht mehr funktioniert in der Anwendung. Das firmware.bin des codeneutralen Nachbaus ist auch nicht hexneutral mit dem opendtu-onbattery-generic.bin von dieser homepage. Meine gebauten Stände (neutral und mit der Änderung) lassen sich jeweils per OTA flashen und laufen auch irgendwie auf der openDTU, ich kann configs ändern usw. ABER ich habe auf der Startseite einfach keine Anzeige der WR-Daten :(
Ist dies vlt. ein bekanntes Problem bzw. was kann falsch gelaufen sein, GIT und VSC wurden beide in der neuesten Version installiert und haben sich die notwendigen PlugIns/Extensions ja selbst gesaugt. Bin da nun recht ratlos...

[schlimmchen]

Hast du die WebApp gebaut, bevor du die Firmware gebaut hast?

https://www.opendtu.solar/firmware/compile_webapp/#

Dein Kompilat wird soweit ich weiß garantiert nicht binär gleich sein zum Build von Github, weil sich meines Wissens nach niemand um reproducible Builds bemüht. Damit kannst du also nicht rechnen.

[Andrix82]

leider auch nach installieren von YARN über NodeJS und lokalem compilieren der WebApp das gleiche Problem, lokal gebaute Firmware mit oder ohne Änderungen läuft, liest z.b. auch die Daten vom Shelly ein wenn ich F5 drücke, ABER es fehlt einfach die gesamte Anzeige der Wechselrichter unter der Grid Power. :(

Hexneutralität wär mir ja noch egal aber wenn das lokal gebaute einfach nicht lauft wie das original dann gibt es auch keine Arbeitsfähigkeit und kann so leider nichts testen/beisteuern.

Vlt. Noch Ideen oder bzw. ein Hinweis wohin man sich mit Problem wenden sollte ? Danke!

[Andrix82]

ok danke für diese etwas beunruhigende info o_o ....
Die webapp habe ich nicht neu compiliert da ich daran auch nichts geändert habe, hätte gelesen/verstanden solange es nur änderungen in der firmware gibt ( in diesem fall ausschließlich in der main eine time init ) und keine änderungen in der webapi bleibt die unverändert und wird einfach mitgelinked ins gesamt binary.
Wenn die builds allgemein prinzipiell nicht hexneutral sind wäre es aber möglich dass dies hilft mit lokalen gegebenheiten neu zu compilieren, werde das demnächst mal ausprobieren und berichten, thx