Indeed. If you can show me where the SOC was above 95% and the system showed a #1… that is a bug, that needs looking into. But as I said, this particular part is pretty extensively unit-tested and I haven’t found a bug there in many years. I would be amazed if you found something that wasn’t the result of something specific you did.
Something to keep in mind. Many BMSes don’t supply SOC with a decimal. Whole numbers only. And it goes into low-battery mode AT the configured SOC, not BELOW it. So 95.4% SOC… if it reports that as a whole number (which it likely does)… it that will cause it to stop. So in such a system, 96% is basically the lowest you can go. Just some things to look at…
Edit: Also, even momentarily dipping under 96% can dump it into Discharged mode. By the time you come to look, you might conclude: Oh, look, it went into discharged mode before 95%! Not necessarily… it could have done it 12 seconds ago when you weren’t looking, and it has since recharged again to 96%… (or more likely, it recharged from 95.4% to 95.5%… so it literally takes just 100Wh to trigger).
@TheTerribleTriplet
I am not saying this is related but it might be worth checking.
In the ESS assistant, there is some dynamic voltage cut off settings.
Have those been adjusted according to your 17S values?
Thanks Phil. Did not cater for 17 cell bank, left settings like so, volts nowhere near the 58.65v it happens at.
I have tried settings over the years that “skik vir niks”.
Know of this, your post reminded me of it, as it has to do with Low Battery (ESS #1) before inverting is allowed again …
Google shows this thing I experience comes up now and then on Victron Community too. With no concrete answer that I have read bar dropping the SOC IF I see it happening.
Am now setting the Min SOC via on HA to max 90% … it does prolong the “events” happening compared to running at 95% Min SOC.
I’m pretty sure it is software-related, not a bug per se, but because of catering for one set of circumstances that this event occurs in some cases just because. And I’m not saying it must be fixed, not worth the “risk” in my mind, but if there is a legit easy way that the system can “get itself” out of this “loop”, automatically, that would be nice like.
EDIT: Like IF ESS #1 comes up, and SOC is >95%, drop the ESS #1 state, as it is incorrect.
I am going to restate the problem, as I see it so that everyone is on the same page:
The problem condition is that ESS#1 kicks in, and the MPPT is excluded from picking up the loads even though there is plenty sun.
OK, Let’s think about things we know:
The ESS #1 thing is a binary condition.
If the SOC is below the threshold it will not use the battery to supply the loads.
The SOC is a coulomb count, not a voltage condition.
The SOC for the system is a whole number.
Question: Does that mean 95.4% = 95% and 95.5% = 96%?
The ESS#1 condition has 3% hysteresis.
Question: Does this mean that ESS#1 turns on at 95.4% and off at 98.5%?
The MPPT has a voltage target, it reaches and turns off. There will be a hysteresis voltage band that has to be exceeded before they turn on again. This is not a coulomb count condition.
The Lithium batteries are being operated on the flat of the curve so that current could be drawn without an appreciable drop in voltage.
Question: Is it possible to achieve ESS#1 state by coulomb counting without breaching the MPPT hysteresis voltage band - I think Yes.
Question: Once in ESS#1 condition what can drop the voltage? - I think that there is nothing to drop the voltage sufficiently.
Question: Does this mean the MPPT is effectively locked out from all but throttled charging?
The BMS is set so that charging is throttled between 95% and 98% to 10A or has this now changed?
See recent quote:
Question: So is there still charging ( albeit throttled charging) until 98%?
And:
Question: If charging ceases at 98%, how is the 98.5% SOC reached to turn off ESS#1?
I don’t know but I think that all these things that seem to be set to happen within a hair of each other seem to be a recipe for getting stuck in this limbo.
This is where having a smaller house comes in handy
Those 3 peaks you see is the heatpump and dish washer (dishwasher is my marriage safeguard ). The rest of the house is in between that.
That is SO true … 2 households, 8 people including 1 x 4 week old one … bugger.
You want to use the dryer, book a time - and check geyser temp, asking who wants to shower tonight?
You want to switch on the dishwasher early, NP, switch off the geyser and remember to put it back on.
Lifestyle changes, optimizing the system draw.
1: Charging ceases at 95% SOC, set to Zero/off, no charging. BUT a teeny bit still slips past into the batts. Cannot stop that completely all the time.
2: It goes up to 97% SOC because of the volts per cell, from that bit that still seeps through pushing the cell volts up, therefore the SOC goes a wee bit up.
Titbit: I watch the BMS, can see the ah would be on 96.04ah, then it drops to 96.00ah, and starts slowly creeping up/go down again as the volts alter all the time, with no draw on the cells. IF balancing happens, ah adjusts faster. Delta at like 0.008/0.009v between the 17 cells.
OK, pulled the data. The state machine does go into lowsoc. I cannot see why. But it could be that the BMS driver is causing it, if it intermittently sends a low SOC (and corrects it within 5 seconds or so, before vrmlogger triggers and logs the change) this sort of thing can also happen.
What is interesting in the data for your site is a lot of open white space… where nothing except the battery capacity changes (which in my mind is incorrect… the capacity is the current connected capacity, which should be fairly constant: If I have 5 x 100Ah racks connected, and 4 of them is online, then this should show a constant 400Ah… it should not update as the battery charges, that’s what SOC is for).
I suspect your BMS driver… because I promise you, the only way it ends up in #1 is if it observes an soc lower than your minimum.
Redo the test, but use the SOC from the BMV instead. See if it stops doing it…
Cerbo is connected with a UTP cable to a hub onto fibre. Out of my control, maybe report it to someone?
Have never ever seen the BMS, on the app in front of me, nor on the Cerbo, give a low SOC ever, unless I did it on purpose.
If the comms to BMS is lost, the BMS alarm beeps and Cerbo shows the “broken” values. If it happens in a split of a second, SOC drops low, no alarm, I will miss it. But I will see it if it takes seconds.
Used BMV on the Trojan’s and Pre-disaster on the Lifepo4 cells, before Louis driver … both cases happened with the BMV too.
So I can run the test again using the BMV SOC … for I promise you it happens when SOC >95% with ESS showing #1.
Will report back once I have done the test using the BMV, if that will help identify where I mess up.
I don’t think the BMS is actually sending such a value. I suspect it might be an error in the communication, and maybe some default value (zero in all likelyhood) slips through, but then a second later when it updates again, it gets a good one again.
I’ve seen this sort of thing before, with Fronius PV inverters. If there is a communication error between the PV-inverter and the datamanager (their own internal comms), the datamanager stuffs the registers with all zeroes (and an error flag). If your timing is such that you fetch that data frame right in that second (which happens with amazing regularity), you get zero volts, zero watts, zero energy. And zero energy means the energy counter has wrapped so that screws things up niiicely…
OK, I’ll buy this hypothesis in combination with the 3% hysteresis.
But @TheTerribleTriplet says this only happens at his 95% SOC setting.
So are we saying once ESS#1 is triggered the next healthy SOC has to be 3% higher than the SOC setting?
So if the SOC setting was 90%, along comes the false zero value data which triggers ESS#1 , but the subsequent healthy data reports say 95% and ESS#1 is reset.
Or at least, even if the subsequent genuine data reports 90%, Jaco’s BMS charge settings allow for charging past 93% and ESS#1 will at least reset after a short time.
It would then follow as Jaco’s only charges to 95%, if ESS#1 is triggered for whatever reason it will never be reset because he never charges to 98%.
This is a variation of what I am trying to get at: A 95% SOC setting and a 95% BMS charging cut-off setting are mutually incompatible. Once ESS#1 is triggered ( for whatever reason) there is no charging headroom capability to reset it.
Edit: Well I think this can be proven. @TheTerribleTriplet if you don’t have the issue when the SOC setting is 90% and the BMS cut-off is 95%. If you keep the SOC setting at 90% and change the BMS setting to 90% and the issue resurfaces I think that will show that the BMS cutoff setting has to be higher than the SOC setting.
I think you shouldn’t charge to the min SOC setting, you should charge through the min SOC setting.
I can do that yes. Am pretty sure it will work, the >95% SOC, where it happens, hysteresis needing SOC of 98% (3%) … mmm and there a penny drops, whether it has meaning or not, I don’t know.
System set to 95%, the system gets up to 97%, and sits there as intended, but needs a SOC of 98% to get past the hysteresis if there is one, which there is, yet does not get to 98%, so it is “stuck”.
No… I have evidence of it happening with a MinSoc of 80% and a reported battery SOC of 87%.
But something is still off here. It looks as if (when it goes into Discharged mode) it stays there until the battery is back at 88%. But that is weird… if this was WITH BatteryLife, that explains it, the ActiveSOC is 5% higher, add in the 3% hysteresis, and it is all accounted for. But he is running Without BatteryLife.
Still, please do excuse me for getting a little grumpy, but it is not the first time I’ve been sent down a rabbit hole which turned out to be not-in-my-code…
It almost looks as if the MinSoc is set to 85% here… and it works perfectly if that is the case. Except the data seems to say at this point the SOC limit us 80%. Still, seems very suspicious that it is doing exactly what it should for an 85% MinSoc.
Notice how it goes into Discharged mode at 85%… and comes out again at 88%.
). The rest of the house is in between that.
