SOC changing to zero every about 13 min 20 s while solar power is zero
Closed this issue · 7 comments
Hi there again,
sorry to come up with another issue. I am wondering about the topic e3dc/battery/soc changing to 0 every 13 min 20 s (nearly exactly, plus/minus a few seconds). It is looking a bit strange in Home Assistant (the lower graph in the following picture).
This issue is not a new one - but until now I suspected the reason to be in Home Assistant. Only since I did some analytics of the mqtt messages I found out that it seems to be rscp2mqtt related. This behaviour can only be observed while there is no solar power (e3dc/solar/power = 0). Or in other words: As soon as the sun is shining there are no jumps in the soc value, visible on the left side of the diagram screenshot.
As well, after upgrading to v3.12 I noticed that e3dc/battery/rsoc is changing from the rsoc to the soc value from time to time (that is the upper graph) - and vice versa (and this behaviour is new with v3.12). I checked the values with RSCPGui, also refreshed the values at that moment when e3dc/battery/soc changed to zero (that was for about 1-3 intervals with INTERVAL=3, then back to the correct value). RSCPGui does not show these jumps, even if I force updates as soon as I observe the value jumps via mqtt. Weirdly, before upgrading rscp2mqtt, the rsoc value was always identical to the soc value - only that the rsoc value had one decimal (i.e. 23.5%) while soc always are published as integer value (i.e. 23 %).
I did not dive into the source code too deeply (since I am not a skilled programmer) but possibly there is a double definition of some mqtt topics in RscpMqttMapping.h in block
// CONTAINER TAG_DB_HISTORY_DATA_...
// TODAY
(Possibly in that block there is a missing "today/" prefix in the mqtt topics? But could not find anything in parallel to this regarding the soc jumps).
Best regards
Additional information: The issue only seems to occur when SOC of the battery reaches the minimum charge level set for emergency power.
Hi,
regarding rsoc you are right. There is a double definition (since rel. 3.11, issue #40, lines 239 and 338) for e3dc/battery/rsoc in RscpMqttMapping.h.
If you like please delete line 239 { TAG_DB_HISTORY_DATA_DAY, TAG_DB_BAT_CHARGE_LEVEL, 0, "battery/rsoc", ... compile and test again.
The issue with soc (toggle between the correct value and 0) I can't reproduce. My battery is discharging now and I have set an emergency limit. So I will take a look at the mqtt output for the next hours ;-)
Best regards
Thomas
I did what you suggested - the result was a bit of a surprise (blue line: rsoc, magenta line: soc):
a) You can see the jumping of the RSOC line stopped around 18:00 - that was when I followed your suggestion. To my surprise it did not rise to the upper value where it jumped to before ...
b) ... so RSOC and SOC now seem to be identical values (except the missing decimal of the SOC value)
c) The jumping of the SOC value to zero starts when (R)SOC gets just UNDER the configured emergency power charge value.
d) RSOC does NOT jump to 0.
Additionally, the mean value of e3dc/battery/dcb/<bat#>/soc drawn from all the four of my batteries is nearly 5 percentage points higher than e3dc/battery/soc or e3dc/battery/rsoc. In my understanding the former are the real socs of every battery module including the reserve that is held for not deep discharging the batteries.
After some research (mainly in the code of RSCPGui) I found that there is another RSCP tag named TAG_BAT_RSOC_REAL (represented by 0x0380000E) which reflects the mean value of all e3dc/battery/dcb/<bat#>/soc.
So for now, after deleting line 239 in RscpMqttMapping.h (which probably represents a real soc) I can use the rsoc value that does not seem to jump and also has the benefit of one decimal. As a by-product of my research: May I suggest to add TAG_BAT_RSOC_REAL to rscp2mqtt to have the mean value of e3dc/battery/dcb/<bat#>/soc represented by one mqtt topic?
Best regards
Hello,
exactly, I have to distinguish correctly between SOC and RSOC. I think your explanation for the difference between SOC and RSOC is correct.
My research has shown that the code in line 239 is needed for the daily history data to recognise if the payload has changed. I have adapted the topic so that it is unique.
I will also intercept the switching of the SOC :-) When the S10 returns "0", rscp2mqtt will use the SOC value with decimal place to check if the "0" is plausible.
I have added the tag RSOC_REAL as well.
I'm still testing, but will release a v3.13 version soon.
Best regards
Thomas
Hopefully fixed by the new release v3.13
I can confirm, that SOC sometimes drops to 0 when it is near emergency power value.
However, I am currently logging my SOC with information polled from Modbus, not from rscp. So I guess this is an E3DC internal problem/behavior rather than an rscp2mqtt problem.
Maybe this is related to a power saving mode that E3DC offers and when there is no sun and the system waits at the emergency power level, the system goes to sleep.
First of all: 3.13 is doing much better, thank you also for adding RSOC_REAL!
I watched battery/soc since installing 3.13 - I had one single drop to zero, but from a value much higher than emergency energy value.
The wild drops (btw emergency energy was changed so those always happened near emergency energy value) stop before noon of the 27th (the day I upgraded to 3.13). From there only the mentioned drop in the afternoon of 28th - but that happened on 3.13, indeed.