Would also be happy with a pointer to somewhere in the dbus api instead. What I’m trying to do is detect when the SOC is close to 100 and in absorption and a few other things (all of which I’ve got handled) but my key point is to know when it has stopped charging the battery even though it hasn’t yet reached 100% and it’s ramped down the solar charge controllers and the charging function on the inverter and is dumping excess power from my AC coupled legacy inverter to the grid. If there’s no one place to detect this situation then a combination of different factors is fine - just need a clear hook to hang the rest off in terms of a start point. At this point if I kick in “Keep Batteries Charged” for a couple of minutes I can get my batteries to balance but otherwise if I leave it in its usual state of Battery Life with Optimisation it usually never covers the final little bit and the balance will worsen a little day by day until I have to intervene manually.
Well I’m continuing to try to figure something out myself whilst waiting for someone to reply…I think I’ve found something interesting through dbus-spy: I’m leaving the battery BMS in control (Pylontech clone) and it seems to me that the closer com.victronenergy.vebus.ttyS4/BatteryOperationalLimits/MaxChargeCurrent gets to the value in com.victronenergy.battery.socketcan_can1/Info/MaxChargeCurrent the more certain I can be that it’s in my desired state…however large loads coming on seem to drag this number down quite a bit even though the system still seems ripe to put into Keep Batteries Charged…can anyone confirm or deny that I’m on the right track here or add a second place/number to watch in tandem with it to balance out that effect?
I’m using ESS for this on my MultiRS, which is after inverter.
For this I disabled selling and put VM meter in front of AC inverter ( VM → AC inverter → MultiRS )
It helps me to keep 100% of the time MultiRS running without using AC inverter, only use it when grid if off and and I need more power than MultiRS max
For the moment when MPPTs are in limited generation mode - I’m using Node-RED where I check
all my MPPTs and then making a decision to send a message to my non-critical consumers to use only excess solar
Thanks…I have that parameter on my SmartSolar RSes but I hadn’t noticed this option you point out which presumably means production is being ramped down…that should definitely help with part of the puzzle…
Why don’t you look at the battery’s current?
com.victronenergy.battery/Dc/0/Current
Anything positive and above 0.5A, charging.
Anything negative and below -0.5A, discharging.
Anything between -0.5A and 0.5A, idle.
Is that how the idle is defined in the GUI code because that would be good to know? Yes it’s a useful measure to confirm the situation I’m looking for but because it could be a transient situation it wouldn’t make a good “go” signal/event to trigger other actions though. I could do some sort of monitoring of it over a period but that could lead to a complicated flow and other factors could change in the mean time.
Don’t know how idle is defined in the GUI, the above is how I would do it.
You can apply some filters for reducing the consequences of transient situations, but such situation will always be, so no code is perfect.
LE:
In the GUI I see that the idle state of battery is defined based on power, the limits being -30W and 30W.
But that’s debatable, because for a 12V system the current is 2.5A, for a 24V system is 1.25A and for a 48V system is 0.62A.
com.victronenergy.battery/Dc/0/Power
Anything positive and above 30W, charging.
Anything negative and below -30W, discharging.
Anything between -30W and 30W, idle.
Thanks for the extra detail… 
So in case anyone is interested to know my solution I’ve implemented something based on the ESS State being 4 (ie. it’s in battery life with optimisation and has reached at least 95% so it’s qualified to reduce the Active SoC target by 5%), the solar charge controller having an MPP operation mode of 1 meaning it’s not producing at maximum, the battery being in idle as defined in the GUI, the multi not being in a charge state of bulk, the code not having run yet on that day, and the SoC not having reached 100%.
It will then go into a running state for half an hour where it switches to an ESS State of 9 (keep batteries charged) and automatically acknowledges any high voltage warnings until SoC reaches 100 or the time is up at which point it reverts to the previous state. Having run this for a couple of days it seems to be working so far.
Improvements to come would include refining it to take account of my AC-coupled grid tied legacy system pushing power out to the grid as an alternative to solar charge limiting (or possibly something around the inverter/charger’s decisions about whether to move any power between the AC and DC sides), detecting and perhaps adapting to individual batteries triggering over voltage protection, and perhaps making it realise conditions have changed and cutting the attempt early if the sun goes in and/or load rises substantially.