-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Inverter hängt, DTU wird nicht aktiv #268
Comments
Den Aufbau des Logs habe ich noch nicht verstanden. In der Konsole werde ich mein Problem vermutlich nicht finden, da ja aktuelle Daten und keine History |
Auf welcher Basis beruht eigentlich die aktuelle Version (23.06.14.post2)? Hier https://github.com/tbnobody/OpenDTU/issues/1032 wird nämlich ein ähnliches Problem beschrieben, was angeblich mit der 23.6.14 nicht mehr auftrat. |
23.6.13 Findest du auch immer in der Readme als Badge. Ich habe da eine Action laufen, die immer in der Readme die Version der originalen OpenDTU für die aktuelle Version angibt |
Werde mal schauen, ob ich Zeit habe gleich mal zu mergen und eine neue Realease freizugeben |
Erstmal vielen Dank für die schnelle Reaktion und das neue Build Als erste Feststellung an den "missing" in der Konsole hat sich nichts geändert, oder muss das so? Ob sich an dem Kernproblem etwas geändert hat wird sich erst in ein paar Tagen zeigen. |
Also das "missing" habe ich auch. Habe mir den Code dazu aber nie angeschaut, da ich funktionell keine Probleme habe. Will sagen, ich habe keine Ahnung was diese Logausgabe wirklich aussagt. |
Das die DTU neustartet sollte eigentlich nicht sein. Das deutet auf irgendwelche Bugs hin. Bei mir lief jetzt alles über 6 Tage total stabil. Welche Komponenten sind bei euch aktiviert?
|
In meinem Fall aktuell nur MQTT, powermeter (https) und das oled. Ich werde meine DTU morgen updaten und dann beobachten |
MQTT ohne HA VE -off- |
Bei mit hat das System den WR geplant um 0:00 nu gestartet, Error 2 ist bisher noch nicht aufgetreten, allerdings kommt aktuell auch keine Leistung in den Akku, sodass er auch nicht freigegeben wird. @spcqike Update 13:12: |
Ich glaube größer ist der interne Fehlerspeicher des Inverters nicht. Und er überschreibt auch Meldungen mit unterschiedlichen Prios. Soweit ich mich erinnere. |
Error 2 war "...Command failed", flutete in der Vorgängerversion auch mein Log Allerding muss ich dazu sagen, dass ich den empfohlenen "Stützelko" am Funkmodul im Rahmen des Updates auch von bisher 10uF auf 100uF Tantal getauscht habe, auch wenn ich hier die Lösung nicht drin vermute. |
Macht Sinn. Denn der Start (Code 1) ist ja noch vorhanden. Bisher ist auch nichts weiter passiert. Ich hab auch keine Ahnung, welcher Command da hängen geblieben sein soll. Die openDTU sollte bei mir ja aktuell nichts schicken. Oder werden die aktuellen Leistungsdaten ebenfalls gepollt? die Konsole sieht aktuell wie folgt aus:
gelegentlich mit "Middle missing", aber auch oft ohne. die Kanäle ändern sich gelegentlich. |
Die Daten werden immer gepollt. Allerdings habe ich mir das genaue Protokoll nicht angeschaut. |
Kurzes Update. Bisher läuft es dann ohne Auffälligkeiten. Keine Fehler Meldungen, keine erkennbaren Lücken in der Aufzeichnung. Laufzeit 21:11 h. Nachtrag. In der Zwischenzeit ist der Fehler 2 mal aufgetreten. Steht aber nur im log. Aufgehängt hat sich nichts Update. Die DTU läuft ohne dass ich sie neu gestartet hätte aktuell 1tag 2h 54min Und hat einen heap Von 126/144/270. können die Fehler von nicht erfolgreichen Antworten stammen? Wenn dieses“middle missing“ passiert? |
Update: Danach war die DTU irgendwann völlig weg. Ich bin nicht drauf gekommen. Kein Ping, keine IP, kein MQTT, keine api. Zwischenzeitlich kam ich auf die api. Es gab aber immer nur null als Antwort. Jetzt komme ich wieder auf die Info Seite. Die DTU läuft aktuell seit 1 Tag 3 Stunden. Sie hat sich also nicht neu gestartet. MQTT geht wieder. Ebenso die api. Heap steht bei 69% (82/186/267 kB) kann man irgendwie auslesen / herausfinden, was den heap füllt? |
@spcqike doofe Frage: Netzwerkprobleme kannst du ausschliessen? Kein Mesh-Netzwerk oder ähnliches? |
100%ig auschließen kann man sowas nie :) Mein Heimnetzwerk ist schon .... größer und komplexer als eine FritzBox :) aber da ich alle anderen Geräte (und ihre Daten) aus dem IoT Netzwerk einwandfrei erreichen konnte (bzw. die anderen Daten ohne Lücken protokolliert wurden, also bspw. Tasmota Sensoren die ebenfalls MQTT nutzen), würd ich sagen da lag kein Problem vor. spätestens, als ich die OpenDTU wieder per Ping erreicht habe, und auch per "http:///api/livedata/status", dort aber nur "null" zurück kam, würd ich sagen das Problem liegt bei der DTU. wie gesagt, später ging dann die API wieder (der Neustart allerdings nicht. der gab weiterhin im Webinterface ein "Parsen nicht möglich" und direkt per API aufruf ein "null") ebenso hatte sich MQTT von alleine gefangen. Dabei war der HEAP dann recht belegt, siehe oben. zum HEAP, da du es in einem anderen Post meintest, dass das Maximum sich nicht ändern sollte. Ich kann sagen, es ändert sich. wie geschrieben, gestern im "halb aufgehangenen Zustand" lag er bei 267kB Max. nach dem Neustart (am Netzteil) ging es hoch auf 271, aktuell sind es 270. Meinst du, es würde zum Debuggen etwas bringen, den Seriellen Log mal ein paar Tage aufzuzeichnen? Dann würd ich mir mal was einfallen lassen, wie ich das hinbekomme.... |
Bringen würde es mit sicherheit etwas. Ich würde erwarten, dass wenn der liveview nicht funktioniert du im Log sowas sehen würdest: "Call to /api/livedata/status temporarely out of resources." Generell tippe ich auf ein Speicherproblem. LiveView ist immer das, wo es am schnellsten auffällt. Dort wird versucht den größten zusammenhängenden Memory-Block zu bekommen (für den Status-Report). In Summe mag zwar genug Speicher verfügbar sein, aber durch Fragmentierungen im Speicher gibt es keinen zusammenhängenden Block mehr. Das kann passieren, wenn kleinere Speicher-Blöcke nicht sauber freigegeben werden. Dann fallen irgendwann weitere Funktionen aus und am Ende bootet der ESP neu. Mein Problem ist es, dass ich es nicht nachstellen kann. |
na, ich gucke mal und lasse mir was einfallen. wird schon irgendwie gehen mit dem Log :) zu meiner config: -das Modul ist im WLAN
das ist gestern nicht passiert. er hat sich wieder halbwegs gefangen. MQTT ging wieder, ebenso einige API aufrufe (neustart bspw. nicht), LiveView weiterhin nicht. Das wird schon am belegten HEAP liegen, es waren dann ja nur 82kB frei. Ich habe noch 2 ähnliche Systeme installiert bei Bekannten, allerdings ohne MQTT und PM (und auch ohne DPL, den ich ja seit ner Woche zum beobachten auch nicht nutze). die laufen unauffällig. (da wird aber auch weniger oft drauf geguckt.... vielleicht kommt das HEAP Problem ja erst durch das Öffnen des LiveView? Mir kommt es auch so vor, als käme das Problem bevorzugt, wenn ich mit dem iPhone drauf gucke. Auf der anderen Seite läuft es auch Tage stabil, und irgendwann häufen sich diese komischen Fehler 2 im InverterLog. Und irgendwann steigt das WebUI aus. die zwei PRobleme müssen ja aber nicht zwingend zusammen hängen (ich kann aber schlecht überprüfen ob VOR dem vollen HEAP und den Abstürzen Fehler da waren. gestern jedenfalls war es so)) |
Bisher läuft die Version f018a01 vom Jun 21, 2023 relativ problemlos, Was mich aber jetzt zusätzlich irritiert, sind die neu verfügbaren Versionen mit "ESP32" im Namen? |
@uli-bs Scheinbar hast du noch kein Log (Console) geteilt. Kannst du einmal einen Auszug kopieren und uns zeigen? Gerade bist du ja scheinbar im Fehlerzustand, da wäre der Log vermutlich sehr hilfreich. Was hast du im Kontext das Power Limiter als "lower power limit" für den inverter eingestellt? |
Jetzt mit weniger Müll und mit Fehler: ` Websocket: [/livedata][20] disconnect
18:03:16.822 > Websocket: [/vedirectlivedata][20] disconnect
18:03:16.822 > Websocket: [/huaweilivedata][20] disconnect
18:03:16.976 > Websocket: [/batterylivedata][20] disconnect
18:03:18.611 > RX Period End
18:03:18.611 > All missing
18:03:18.611 > Nothing received, resend whole request
18:03:18.611 > TX PowerControl Channel: 40 --> 51 82 92 24 50 80 18 30 88 81 00 00 B0 01 25
18:03:18.732 > Interrupt received
18:03:18.798 > RX Channel: 3 --> D1 82 92 24 50 82 92 24 50 81 00 00 00 00 24 00 74 | -80 dBm
18:03:19.117 > PowerMeterClass: TotalPower: 136.00
18:03:20.628 > RX Period End
18:03:20.628 > Success
18:03:20.763 > TX ActivePowerControl Channel: 61 --> 51 82 92 24 50 80 18 30 88 81 0B 00 03 E8 00 00 10 81 E5
18:03:20.880 > Interrupt received
18:03:20.968 > RX Channel: 3 --> D1 82 92 24 50 82 92 24 50 81 00 00 0B 00 14 07 48 | -80 dBm
18:03:22.699 > RX Period End
18:03:22.700 > Success
18:03:22.700 > Fetch inverter: 114182922450
18:03:22.811 > TX RealTimeRunData Channel: 75 --> 15 82 92 24 50 80 18 30 88 80 0B 00 64 A4 42 CA 00 00 00 00 00 00 00 00 0C 4A D4
18:03:22.927 > Interrupt received
18:03:23.015 > RX Channel: 3 --> 95 82 92 24 50 82 92 24 50 83 00 00 00 00 00 00 01 28 00 39 BA 93 2F | -80 dBm
18:03:23.217 > RX Period End
18:03:23.217 > Middle missing
18:03:23.217 > Request retransmit: 1
18:03:23.217 > TX RequestFrame Channel: 3 --> 15 82 92 24 50 80 18 30 88 81 D0
18:03:23.324 > RX Period End
18:03:23.324 > Middle missing
18:03:23.324 > Request retransmit: 1
18:03:23.324 > TX RequestFrame Channel: 23 --> 15 82 92 24 50 80 18 30 88 81 D0
18:03:23.442 > RX Period End
18:03:23.442 > Middle missing
18:03:23.442 > Request retransmit: 1
18:03:23.442 > TX RequestFrame Channel: 40 --> 15 82 92 24 50 80 18 30 88 81 D0
18:03:23.545 > Interrupt received
18:03:23.631 > RX Channel: 23 --> 95 82 92 24 50 82 92 24 50 01 00 01 01 09 00 03 00 07 01 08 00 03 00 07 00 00 94 | -80 dBm
18:03:23.683 > RX Period End
18:03:23.683 > Middle missing
18:03:23.683 > Request retransmit: 2
18:03:23.683 > TX RequestFrame Channel: 61 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:23.747 > RX Period End
18:03:23.747 > Middle missing
18:03:23.747 > Request retransmit: 2
18:03:23.747 > TX RequestFrame Channel: 75 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:23.835 > RX Period End
18:03:23.835 > Middle missing
18:03:23.835 > Retransmit timeout
18:03:24.358 > PowerMeterClass: TotalPower: 139.00
18:03:26.367 > [PowerLimiterClass::loop] ******************* ENTER **********************
18:03:26.367 > [PowerLimiterClass::loop] ******************* PL inverter updates PM: 4747, Inverter: -385
18:03:27.679 > Fetch inverter: 114182922450
18:03:27.873 > TX RealTimeRunData Channel: 3 --> 15 82 92 24 50 80 18 30 88 80 0B 00 64 A4 42 CF 00 00 00 00 00 00 00 00 5C 75 BE
18:03:28.045 > Interrupt received
18:03:28.132 > RX Channel: 23 --> 95 82 92 24 50 82 92 24 50 01 00 01 01 09 00 03 00 07 01 08 00 03 00 07 00 00 94 | -80 dBm
18:03:28.198 > Interrupt received
18:03:28.254 > RX Channel: 3 --> 95 82 92 24 50 82 92 24 50 83 00 00 00 00 00 00 01 28 00 39 BF 5E E7 | -80 dBm
18:03:28.309 > RX Period End
18:03:28.309 > Middle missing
18:03:28.309 > Request retransmit: 2
18:03:28.309 > TX RequestFrame Channel: 23 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:28.381 > Interrupt received
18:03:28.543 > RX Channel: 40 --> 95 82 92 24 50 82 92 24 50 02 4D 09 00 00 4D D3 00 15 00 15 09 36 13 8F 00 00 EE | -80 dBm
18:03:28.608 > RX Period End
18:03:28.608 > Success
18:03:29.645 > PowerMeterClass: TotalPower: 138.00
18:03:32.669 > Fetch inverter: 114182922450
18:03:32.737 > TX RealTimeRunData Channel: 40 --> 15 82 92 24 50 80 18 30 88 80 0B 00 64 A4 42 D4 00 00 00 00 00 00 00 00 AC CB EB
18:03:32.821 > Interrupt received
18:03:32.943 > RX Channel: 40 --> 95 82 92 24 50 82 92 24 50 83 00 00 00 00 00 00 01 28 00 39 3A D2 EE | -80 dBm
18:03:33.201 > RX Period End
18:03:33.201 > Middle missing
18:03:33.201 > Request retransmit: 1
18:03:33.201 > TX RequestFrame Channel: 61 --> 15 82 92 24 50 80 18 30 88 81 D0
18:03:33.269 > Interrupt received
18:03:33.453 > RX Channel: 40 --> 95 82 92 24 50 82 92 24 50 01 00 01 01 09 00 03 00 07 01 08 00 03 00 07 00 00 94 | -80 dBm
18:03:33.503 > RX Period End
18:03:33.503 > Middle missing
18:03:33.503 > Request retransmit: 2
18:03:33.503 > TX RequestFrame Channel: 75 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:33.567 > RX Period End
18:03:33.567 > Middle missing
18:03:33.567 > Request retransmit: 2
18:03:33.567 > TX RequestFrame Channel: 3 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:33.644 > Interrupt received
18:03:33.763 > RX Channel: 40 --> 95 82 92 24 50 82 92 24 50 02 4D 09 00 00 4D D3 00 15 00 15 09 38 13 8E 00 00 E1 | -80 dBm
18:03:33.833 > RX Period End
18:03:33.833 > Success
18:03:34.908 > PowerMeterClass: TotalPower: 138.00
18:03:36.878 > [PowerLimiterClass::loop] ******************* ENTER **********************
18:03:36.878 > [PowerLimiterClass::loop] dcVoltage: 26.50 Voltage Start Threshold: 24.60 Voltage Stop Threshold: 24.10 inverter->isProducing(): 0
18:03:36.878 > [PowerLimiterClass::loop] newPowerLimit: 98
18:03:36.878 > [PowerLimiterClass::loop] Starting up inverter...
18:03:36.878 > [PowerLimiterClass::loop] Limit Non-Persistent: 98 W
18:03:36.878 > [PowerLimiterClass::loop] Status: SolarPT enabled 0, Drain Strategy: 0, canUseDirectSolarPower: 0, Batt discharge: 1
18:03:36.878 > [PowerLimiterClass::loopInterrupt received
18:03:37.036 > RX Channel: 23 --> D1 82 92 24 50 82 92 24 50 81 00 00 00 00 24 00 74 | -80 dBm
18:03:38.897 > RX Period End
18:03:38.897 > Success
18:03:38.979 > TX ActivePowerControl Channel: 40 --> 51 82 92 24 50 80 18 30 88 81 0B 00 03 D4 00 00 1C 41 15
18:03:39.044 > Interrupt received
18:03:39.184 > RX Channel: 23 --> D1 82 92 24 50 82 92 24 50 81 00 00 0B 00 14 07 48 | -80 dBm
18:03:40.157 > PowerMeterClass: TotalPower: 139.00
18:03:40.910 > RX Period End
18:03:40.910 > Success
18:03:40.910 > Fetch inverter: 114182922450
18:03:40.965 > TX RealTimeRunData Channel: 61 --> 15 82 92 24 50 80 18 30 88 80 0B 00 64 A4 42 DC 00 00 00 00 00 00 00 00 6C AC 44
18:03:41.141 > Interrupt received
18:03:41.232 > RX Channel: 40 --> 95 82 92 24 50 82 92 24 50 01 00 01 01 09 00 03 00 07 01 08 00 03 00 07 00 00 94 | -80 dBm
18:03:41.460 > RX Period End
18:03:41.460 > Last missing
18:03:41.460 > Request retransmit: 2
18:03:41.460 > TX RequestFrame Channel: 75 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:41.591 > RX Period End
18:03:41.591 > Last missing
18:03:41.591 > Request retransmit: 2
18:03:41.591 > TX RequestFrame Channel: 3 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:41.743 > RX Period End
18:03:41.743 > Last missing
18:03:41.743 > Request retransmit: 2
18:03:41.743 > TX RequestFrame Channel: 23 --> 15 82 92 24 50 80 18 30 88 82 D3
18:03:41.808 > Interrupt received
18:03:41.946 > RX Channel: 40 --> 95 82 92 24 50 82 92 24 50 02 4D 09 00 00 4D D3 00 15 00 15 09 37 13 8F 00 00 EF | -80 dBm
18:03:41.999 > RX Period End
18:03:41.999 > Last missing
18:03:41.999 > Request retransmit: 3
18:03:41.999 > TX RequestFrame Channel: 40 --> 15 82 92 24 50 80 18 30 88 83 D2
18:03:42.073 > Interrupt received
18:03:42.152 > RX Channel: 75 --> 95 82 92 24 50 82 92 24 50 83 00 00 00 00 00 00 01 29 00 39 7F CE B6 | -80 dBm
18:03:42.220 > RX Period End
18:03:42.220 > Success |
Hm... Ganz schön zerhackstückelt. Da kannst du natürlich nichts dafür. Also immerhin sehen wir, dass er den Wechselrichter einschalten möchte: "Starting up inverter...". Danach sehen wir ein "TX ActivePowerControl", aber keine Indikation, dass ein PowerControl (nicht Active-) gesendet wird. Allerdings weiß ich auch nicht sicher, ob man da so sieht, wie ich es jetzt erwarte. Zu wenig Erfahrung... Es ist natürlich möglich, dass versucht wird, den Inverter zu starten (Hoymiles Bibliothek), aber dass das Kommando nicht ankommt (zeitweise Probleme auf der Funkstrecke). Wenn deine Hysterese groß ist (30 W ist eher viel) und dein Netzbezug eher "ruhig", dann kann es sein, dass kein weiteres Einschalten versucht wird. Auf welchem Release bist du denn gerade unterwegs, und könntest du auf das heutige aktualisieren? Da kenn ich mich jedenfalls besser aus 😁 Wenn du aktualisierst, dann lass nach Möglichkeit ansonsten mal alles, wie es ist, wenns du es einrichten kannst. |
Version f018a01 vom Jun 21, 2023 Mittlerweile produziert er auch wieder, ohne dass ich etwas gemacht habe. |
@uli-bs Kann das Issue geschlossen werden, oder hast du noch Probleme, die damit zusammenhängen? |
An den Problem hat sich nichts geändert, mittlerweile läuft wieder die z.Z. aktuellste Version. |
Hallo, habe ein ähnliches Problem und hoffe das ich bei der Fehlersuche behilflich sein kann! Meine Daten: MQTT: aktiviert Ich lasse über MQTT ca. alle 20 bis 30 Sekunden ein Limit für den Inverter mit dem Topic "limit_nonpersistent_absolute" setzen. Irgendwann (nach 1, 2, 10, 15, ... Stunden Laufzeit, ganz unterschiedlich) wird dieser Wert aber nicht mehr an den Inverter weitergeben! Auch ein manuelles Limit-setzen über die Live-Ansicht: -> Limit-Einstellungen funktioniert dann nicht mehr! Das aktuell gemeldete Limit vom Inverter bleibt unverändert! Verbindungsprobleme zum Inverter bestehen eigentlich nicht, da ich die aktuellen Werte vom Inverter in der OpenDTU-OnBattery angezeigt bekomme! Hier ein Auszug aus der Debug-Konsole, wenn alles funktioniert:
Und hier ein Auszug aus der Debug-Konsole, wenn das Limit nicht mehr an den Inverter weitergegeben wird:
In diesem Auszug ist mir aufgefallen, das nach dem "Limit Non-Persistent" das "TX ActivePowerControl" fehlt und auch kein zugehöriges "Interrupt received" vorhanden ist! Ich habe zum Test auch mal das originale openDTU-Image (v23.7.22) installiert! Hier ein Auszug aus der Debug-Konsole, wenn das originale openDTU-Image installiert ist:
Die Meldungen sind ähnlich zur OpenDTU-OnBattery! Bevor ich es noch vergesse! Finde das Projekt: "OpenDTU-OnBattery" echt genial und ziehe meinen Hut! |
@schlimmchen kann das irgendwas mit #287 zu tun haben, wenn sich die originalDTU und -onBattery unterschiedlich verhalten? Allerdings ist bei mir noch nicht aufgetreten. |
Mir sieht das nach einer Art "Überlauf" aus: |
@the-lonely-one Danke für deine ausführliche Beschreibung. Mir fäll auf, dass der Mein Gefühl ist es, dass meine Änderung 8b23324 womöglich Teil des hier diskutierten Problems ist. Das würde allerdings bedeuten, dass bereits ein anderes Problem vorliegt, nämlich dass Das ist theoretisch möglich: Der MQTT Task benutzt Man könnte ein Pflaster basteln, aber das macht natürlich keinen Sinn, weil meiner Einschätzung nach alle Leute immer davon ausgehen, dass ihr Code synchron in der Der MQTT Client darf keinen internen Task benutzen, um seine Eine enstprechende Änderung habe ich vorbereitet und grundsätzlich auf meiner Platform verifiziert (MQTT funktioniert wie gewohnt). @the-lonely-one welchen Typ Firmware brauchst du? Ich würde dir gerne eine Vorabversion bauen, die du testen könntest. Wenn ich es richtig verstanden habe, tritt das Problem bei dir ja recht zuverlässig auf, da könnten wir nach 24h ohne dein Problem schon davon ausgehen, dass es in der Tat behoben wurde. Es macht übrigens Sinn, dass viele Leute dieses Problem nie sehen, weil sie selten oder gar nicht MQTT nutzen, um den Inverter zu steuern. Es braucht schon meine oben verlinkte Änderung und ein häufiges Steuern des Inverters durch MQTT, um diese Race Condition zu treffen. |
@helgeerbe Benutzt du MQTT, um deine Inverter zu steuern? Meiner Einschätzung nach reden wir in diesem Issue jetzt von mindestens zwei Problemen. Wenn ich @the-lonely-one richtig verstanden habe, dann hat meine Änderung, nur Commands vom selben Typ in die Queue zu lassen, wenn noch keins drin ist, dazu geführt, dass der MQTT Client Task zu einem realen Problem wird. Das hab ich ja im vorherigen Kommentar ausführlich beschrieben. @uli-bs schreibt aber davon, dass er lauter |
@schlimmchen Die Antwort ging ja echt schnell Ich habe einen ESP32 und hatte zuletzt die OpenDTU-OnBattery Firmwareversion: 43e836a drauf, bei der aktuell auch das Problem vorhanden ist. |
@the-lonely-one Dann freue ich mich, wenn du für uns einmal die Firmware aus https://github.com/schlimmchen/OpenDTU-OnBattery/releases/tag/mqtt-no-task ausprobieren könntest und berichtest. |
@schlimmchen Test läuft Schaut aktuell gut aus! Meldungen in der Debug-Konsole sind jetzt ähnlich zur originalen OpenDTU! |
Sollte mit der 2023.08.01 gefixt sein. Ich lasse das Ticket noch offen, damit @the-lonely-one seine Rückmeldung geben kann. |
@schlimmchen Und läuft und läuft und läuft!!! Nach dem ich gestern Abend meine DTU mit der von dir bereitgestellten Firmwareversion "aca46f2" aktualisiert habe, ist das von mir beschriebene Problem nicht mehr aufgetreten! Aktuell läuft meine DTU seit ca. 22 Stunden durchgehend ohne Probleme! Die Randbedingungen waren in diesem Zeitraum gleich: Danke dir nochmal, für die schnelle Bearbeitung! |
@the-lonely-one Sehr gerne, war ein spannender Fehler. Also nehmen wir mal an, dass es in der Tat ein Problem/Fehler war und dass das Problem bei dir nicht mehr auftritt, weil du es bisher mindestens nach 15h beobachtet hast. Ich erstelle dann noch einen Pull-Request gegen das Upstream-Projekt und verlinkte deine ausführliche Fehlerbeschreibung. |
@schlimmchen Limit Vorgabe für meinen Inverter über MQTT funktioniert bisher immer noch ohne Probleme! Mir ist nun aber etwas anderes aufgefallen. Siehe Chart: Vom 31.07. bis zum 02.08. hatte ich die von dir bereitgestellte Firmware-Version zum testen installiert. Aktuell ist die Firmware: 81864b3 installiert, bei der aber ebenfalls das Problem besteht! Laut dem Webinterface von meiner OpenDTU-OnBattery kann ich weder Neustarts von meiner DTU selbst noch von meinem Hoymiles-Inverter nachvollziehen. Ich vermute mal, das mein Problem etwas mit der Web-API bzw. mit der Webserver-Implementierung zu tun, das aktuell bei OpenDTU als Pull Request #1201 diskutiert wird! |
Das freut mich zu lesen! Kopierst du deine Frage nach dem Zurücksetzen der Inverter-Tagesleistung bitte in ein neues Issue? |
@the-lonely-one Ich würde mich freuen, wenn du uns erfahren lässt, ob dein Problem mit dem Release aus Dezember 2023 oder neuer wieder auftritt. Halt da doch mal ein Auge drauf, bitte. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns. |
What happened?
Der Inverter (HM-600) und openDTU (onBattery) läuft zunächst einwandfrei und wie konfiguriert.
Nachts (0:00) wird der Inverter über die DTU neu gestartet, was auch im Log vermerkt ist.
Danach treten zeitlich versetzt lt.. Log Fehler (DTU command failed / Error 2) auf (15x)
Am nächsten Morgen, genügend Ladung ist bereits im Akku, startet, trotz entsprechender Anforderung (480W), der Inverter nicht.
Um wieder normalen Betrieb zu erreichen muss sowohl der Inverter, wie auch openDTU, über die Oberfläche neu gestartet werden.
Der Neustart nur einer der beiden Komponente löst das Problem nicht.
To Reproduce Bug
Tritt nicht jeden Tag auf, daher eher schlecht zu reproduzieren.
Expected Behavior
event eine Art Watchdog implementieren?
Install Method
Pre-Compiled binary from GitHub
What git-hash/version of OpenDTU?
Relevant log/trace output
No response
Anything else?
No response
The text was updated successfully, but these errors were encountered: