OpenDTU-OnBattery stalls on DPL update via MQTT until power is switched off and back on #1494
Comments
|
I am far behind on my notifications, sorry about that. Good issue description, thanks! Is it possible, that the MQTT payload for There should be only one other reason for why there is no message like "Setting battery SoC start threshold to: 75 %": The config write guard could not be acquired... And that should shortly cause a panic by the watchdog. Strange. Is the frequency of this issue increasing? Is your flash ruined by too many writes? If that was the case, we should still see the aforementioned message... |
|
thx for your investigation and no worries, the issue is a bit annoying but not too urgent as it does not happen very often :) |
Afraid not, as the log tells us that the value was received, but processing it trips something up.
That's a good question. Let's not focus on it for now, as it seems far-fetched. 4 updates per day should still get you 6 years of flash usage at the very least... Well, except that you send four new values each time, causing four writes per "HA cycle". So we are down to ~1.25 years. Is this anywhere close to the age of your ESP32? Are you able to connect some sort of PC to log the output of the hardware serial console? There might be more info in there than in the web console. Have you had the web console running for extensive amount of times? Try to observe the amount of free heap while you are doing so. Good point: Can you monitor the system stats published to the MQTT broker to see if the temperature gets excessive, or the heap is getting low right before the issue presents itself? |
|
So, jetzt komm ich endlich dazu, die gesammelten Daten zu sortieren und zu schicken :)
Zu deinen Fragen:
Freier Heap-Space: Temperatur: Console-Log Hänger Nr. 1: Console-Log Hänger Nr. 2: Console-Log Hänger Nr. 3: tty-Log Hänger Nr. 3 (ab Zeile 3041): Happy Hunting, wenn du mal Zeit und Lust drauf hast :) - die Prio ist wirklich nicht sehr hoch, ich bin auch so total glücklich mit dem Projekt, kann gar nicht oft genug danke sagen dafür! |
|
eins noch... falls das Problem bis Ende Januar tatsächlich nicht mehr auftreten sollte, werde ich den Issue zumachen |
❤️ Der Backtrace ergibt wohl Plausibel, aber leider nichtssagend. Es bleibt dabei, dass sich das Teil irgendwie beim Schreiben der Konfig verklemmt. Die anderen Tasks, bei dir beispielsweise der SML Power Meter Task, laufen normal weiter.
Hm... Ich kann mir mögliche Gründe ausdenken, aber keine konkreten. Kann schon sein, dass in einer Bibliothek etwas repariert wurde, dass hier hilft. Dann beobachten wir mal, ob dein Problem wieder auftaucht. 👍 |
|
jetzt ist es leider doch wieder passiert, zwar kein kpl. Stall, aber es wurde zwei Mal nur der erste MQTT-Wert übernommen. Außerdem ist mir aufgefallen, dass es in der Config einen SaveCount gibt; der steht zur Zeit auf ca. 3000, d.h. (hoffentlich) nicht kritisch. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Two weeks ago I switched from a HA scene for the limits to a script with a 3 second delay between setting each value. Since then no more problems... maybe a timing issue still? Anyway, I close the issue, thx a lot for your support! |
|
Interesting... Thanks for coming back to us and sharing that information. I will keep this in mind that frequent MQTT updates can potentially cause issues. |
What happened?
On Dec 1st, 2024 I modified a HomeAssistant automation to not only update the Voltage "Start and Stop Threshold for Battery Discharging" (before I had the "Use Voltage Threshols Only" switch active) but also the two corresponding values for the SOC. The updates are performed via MQTT. Since then it has happened 3-4 times that the system stalled (e.g. no more log entries are produced) and did not recover until I switched off the power. Before Dec 1st, when only updating the two voltage values, the stall has not happened (in at least 6 months).
Thanks to the team for having a look and I appreciate your work tremendously!
To Reproduce Bug
I have tried to reproduce it by manually executing the HA automation in short sequence but was not successful so far (tried at least 50 executions). It happens seldomly (3-4 stalls in Dec. vs 3-4 automation executions per day), I did not find any pattern yet how to reliably trigger the problem.
Expected Behavior
Install Method
Pre-Compiled binary from GitHub releases
What git-hash/version of OpenDTU-OnBattery?
2024.11.20
What firmware variant (PIO Environment)?
generic_esp32_4mb_no_ota
Relevant log/trace output
Anything else?
The provided log shows three MQTT updates which are also visible in the screenshot of the DPL settings. The fourth value is not updated, it remained at the previous value "75". There was no further log output than the one provided until I restarted the system via power off/on.
Please confirm the following
The text was updated successfully, but these errors were encountered: