OK, I will try. There are two values. The one is maintained by BatteryLife, and is lowered by 5% every day that the battery gets a good charge (defined as >95% SoC), and increased by 5% every day it does not get a good charge (defined as 85% SoC). For days that it reaches 85% SoC but does not exceed 95% SoC, this number stays the same.
This number is stored as the SocLimit in settings.
There is a second number, the MinSocLimit. The user can adjust this one. This is the absolute minimum the user ever wants. This is taken so seriously that if you drop more than 5% below this number, the system goes into Auto-Recharge and brings it back to this number.
The system stops when it reaches the higher one of the two. There are many reasons that a user may have the capacity to discharge down to a lower value and recover it the next day, but for whatever reason he doesn’t want to do that. In those cases, the SocLimit (where batterylife determined is a good spot to stop so that we’ll get back to full tomorrow) will be less than the MinSocLimit (the user wants you to stop earlier).
The GUI (the graphical part) takes these values and derives an “active” SOC limit. The one that will actually apply in the real world.
So what you will have to do is query both registers, and use the max() of the two results. That will get you the same value as is shown on the GUI. I know that is more work… sorry about that
Ok, now I understand, thanks. The value that I should have used then right from the start is the MinSocLimit (2901) as BatteryLife will manage the battery around that number. Looking at my requirement it will satisfy +95% of the cases here on the Highveld as we rarely have looooong sun outages (sounds strange) due to overcast conditions (Eloise or something cyclone last year comes to mind). When it actually happens then I don’t mind the grid assisting.
No additional work required, that MinSOC value is the one that is of concern to me. Anything above it will be fine for any LS window. It’s just in the early hours of the morning that things could get dicey when it’s at the lowest limit of 35% in this case. So, in essence I can drop that down to 20% and when I know the next day will be an issue I raise it to 35% or a bit more.
Question, did I read correctly, that if you run NodeRed on the Venus, you cannot upgrade the firmware as easy anymore? Have to redo NodeRed after each firmware upgrade?
It was also interesting to me to find out that I can set the “Minimum SOC (unless grid fails)” to any value. However the GUI rounds it bellow or above to the nearest 5-round value. For example min SOC 26% is rounded to 25 in the GUI, and 28 is rounded to 30% in the GUI.
Indeed it does. Just be careful around certain key values. 97 or 98 might show some unexpected side effects (because there is not enough room for the hysteresis). Values that are not multiples of 5 are not frequently tested. If you break it… you get to keep both pieces.
The GUI does indeed round it to the nearest 5%, but that’s only for display.
