Is this the downside of working on the flat of the curve I wonder?
Possibly, the MPPT’s think the batteries are full and the load is insufficient to dip the voltage…
What I see, drop the SOC and the production starts again … it is like it is triggered by a setting change on the Cerbo, to start the MPPT up again when SOC is >95%, cells are not really full, but at 3.45v it is told to stop charging … so I take what Plonskter says to heart … but it makes no sense as there is a house to still feed the power into, even if the batts are “full”.
SOC dropped to 90% … and there it goes again … increasing the MPPT’s volts to 58.7v did not trigger it to start. Had to change settings on the Cerbo.
Methinks, the system does what it is designed to do based on programmed parameters from user settings + ESS architecture + MPPT’s software.
Battery is “full”, SOC is reached, internal X, Y, Z parameters have been met, so lower production based on these pre-set parameters, as it does not “see” the house as a load to power.
Just a musing from my side, as I have no idea what else to make of it.
Yep, I think there is something buried in the algorithm.
I don’t have Lithiums and my batteries are set to keep charged 100%.
My MPPT’s are also not Victron and so are invisible to the Venus device.
Every so often, the batteries discharge a per cent or so, quite rapidly.
Followed by a short bulk, followed by a short absorption and back to float again.
No apparent reason for this happening.
But it does, it’s like the algorithm is just checking everything is still in place every once in a while, and then we’re good to go again.
Doesn’t seem to influence overall performance.
But it’s like the algorithm wants to go to Bulk every so often but because the batteries are full it needs to make some room first.
Now THAT would work … as I do that kinda manually … send the power into the house, test it … as it will overshoot the house, and go to the grid …
When you see “ESS #1” it means the Inverter component inside the Multi (responsible for feeding energy into the grid/loads) is disabled. So that would be why loads are not powered.
If I had to guess, you set the MinSoc to 100% (for whatever reason) and then lowered it to 95%.
It uses a state machine and a hysteresis of 3%. So one way of getting into this state is to have a battery at 96%, then increase the MinSoc to 100% (state machine goes into Discharged state, #1 shows up), then lower the MinSoc back to 95% (state machine remains in Discharged state until Soc reaches 98%).
To get it out of Discharged state, lower the MinSoc to 90%. It will start up immediately. Then you can increase it again to 95%.
You see what I mean by “endlessly tinkering” 
Sug. Nope, I don’t.
Read what I posted. I don’t see any mention of 100% SOC anywhere. 
And I have seen this before … this started again when I replaced the Venus with a Cerbo.
Is it the Release Candidate software I use, or a combination of that and the fact that I’m still on 487, is it because of the charging I stop at >95% using the BMS driver to steer clear of 100% SOC … something is causing this, it could well be me, or a combination of it all … I get that.
A little help would have gone a long way … not your problem, I get that too.
I’ll figure this one out too …
Is this a bank with a BMV as well as a BMS?
Like the temperature probes if you have multiple probes the system reacts to the highest.
I am thinking that a disparity of SOC reporting between them may be an issue?
Just a thought.
AHA … let me check.
Note: System is set to use BMS SOC, not BMV.
This is what it looked like today when it happened:
1 - BMV
2 - BMS
I don’t know if it’s significant or not, but there is 3%+ between them.
Or maybe, it’s just at 95% you stop charging until you drop to 92%.
I don’t really know.
It’s an Andy’s garage type mystery.
After some more thought, will start the process of elimination with the BMS driver’s settings I altered.
Gonna take a few days … must be around and not distracted, the first time.
If it still happens, as you pointed out, maybe take the BMV out of the loop, and wait again.
The last option I can think of off the top of my head, is to disable HA upping the SOC past 90%.
Don’t see any reason to change the inverter/MPPT settings, as I don’t think it comes from there.
1 Like
Well, if that #1 shows up, you did something to make the state machine go into “Discharged”. And lowering the MinSoc lifts it out again, as you have seen.
There is a weird deadlock that can happen at the top. I see it most often with 1) lead acid batteries, 2) small battery capacity, 3) a high MinSoc, for example 95%.
What happens is that the battery is at 95% SOC, so the BatteryLife state machine goes into Discharged mode. This completely disables the feeding in of energy (mostly, because if the battery is discharged, something that will most often happen during the darker hours of the day, you want to be in the lowest energy-flow state possible).
But because it is a lead acid that is practically full, and because the relative capacity is small, the voltage rises to absorption level really easily, and the battery cannot accept all the current from the solar chargers. Result: MPPTs are throttled while the load is powered from the grid. Customer unhappy because he doesn’t understand what just happened.
That is one reason why using the BMS to manage the SOC is a good idea. Stupid things like an external battery monitor being out of sync cannot really happen. When the high cell spikes, the BMS jumps to 100%, and the system starts feeding in energy
Don’t know if that had anything to do with your issue… but it’s your science experiment, and the state machine in question is extremely well tested and hasn’t had a bug in years…
System sat since ±12:16pm on a BMS SOC of 97% SOC … here:
Then it decides to drop the MPPT’s off a cliff nearly 2.9 hours later, at 15:02 pm, because of something I did? What?
HA cannot do anything as is stop upping the SOC to a max of 95%.
BMS could do nothing as it stopped at 96% SOC, charge current set to zero, although a teeny bit still slips past, pushing it slowly up to above 58.65v.
… extremely well tested and hasn’t had a bug in years… - I have no doubt, but as you said … “There is a weird deadlock that can happen at the top.”
Methinks I have it …
I don’t know if this is related at all.
But as I was saying earlier in this thread, sometimes my system which is set to “keep batteries charged” gets a speed wobble and starts to run off the battery for a bit.
Look at this:
It seems to correspond to when the frequency dips to 49.85Hz. When the frequency is steady (flatline) there are no speed wobbles.
For me, that makes sense, when the frequency drops, for the inverter to step in a bit,no?
Usually has more to do with the grid voltage.
When running grid parallel, the Multi is essentially a transformer and a synchronous rectifier, placing the battery in parallel with the grid. By creating small potential differences, the Multi can cause energy to flow into the grid, or into the battery. But it also means other changes in voltage can cause the same.
If the grid voltage goes up slightly, energy will flow into the battery (until the Multi adjusts the PWM ratio to stop that from happening), and likewise, a small drop in the grid voltage can cause energy to momentarily flow out of the battery.
Also, if you have an AC input current limit set, it can cause energy to be extracted from the battery.
I adjusted the BMS driver back to what it comes out with, and the same happened on Sunday.
Now I’ve seen this plenty of times over the years, so yeah, I have that “weird deadlock that can happen at the top”. 
Now I’ve set the SOC to only reach 90% during the day, it will happen less, but it will still happen, and mostly only in summer.
The requirements for it to happen:
Enough paneling to not only recharge the batteries, but also power the house with ease
SOC >95% <100%
House Loads that don’t need any battery power, as the panels are enough
Fix:
If you see it, drop the SOC.
If you don’t see it, more Eskom will be used till the system eventually “kicks out” of the “loop”.
An idea to circumvent having to waste time to dig deep into why:
On >95% SOC with ESS 1 displayed, trigger system to run off the batts, or drop the SOC … or some such … just to get out of the loop.
If this becomes a “thing” this summer, I will figure out a way to do that.
My head is too busy to trawl through all the things you tried. Suffice it to say, #1 shows up when the SOC of the battery (so it will depend on which battery monitor you selected) is at or below the minimum (so it will also depend on whether you’re using with- or without BatteryLife).
When #1 is displayed, it means the system is in “Discharged” mode. It will put the Multi in the lowest power consumption stage. That means no power is taken out of the battery for loads… not even power that might presently be streaming in from an MPPT. It is simply not that smart (and making it that smart will just cause more questions from particular customers).
Previously it was BMV, now I use the BMS SOC, both are connected.
Min SOC is set to 95%
Without BatteryLife.
DVCC is on.
No rocket science, I have this “weird issue” and can actually make it happen, sometimes, “on demand”, with a touch of patience. Or, for sure, if I turn my back on the system for days … 
The system working beautifully … just have to keep away from a high SOC and then “park” it there for evening use whilst powering the house in the afternoons … and don’t allow the SOC to reach too high midday, or it happens earlier.
If someone at Victron wants to dig into why it happens, we can make the system do it a few times per day … on sunny days … if there is a need to find it. Or tell me what to look for, and whom to report that too.
Otherwise, I’ll sort it somehow … automate it.
Variables, as per your input, I need to look for is >95% SOC and 1# ESS.
Will see how it goes with Min SOC not allowed to be set higher than 90%.