ESS MinSOC on this site is set at 25% but first thing in the morning, ESS state is “discharged” and battery charges from PV until about 8am when ESS state switches to “self-consumption”.
The timing of this switch from “discharged” to “self-consumption” matches the change on AC Input Power from grid import to multiphase regulation / grid support (which we want).
I cannot find any documentation about why PV is being dedicated to battery first thing in the morning even though it is at or above ESS MinSOC level.
It’s not being “dedicated”. The Multi is simply not discharging the battery because it deems it to low. Therefore whatever the solar chargers are doing is what they are doing… charging the battery. It is not as if the charge is going through the Multi and the Multi is actively deciding to rather send that to the battery…
To make this work as you say here – and you are not the first one to ask for it – requires code to be added that will look for charge coming from solar chargers, then wait until there is enough of it to carry the self-consumption of the Multi(s) (which we don’t know how many there are, it could be 1, it could be 12). Then carefully balance solar charger output with AC consumption, taking into account a non-static conversion factor from DC to AC…
Or keep it simple and just go to self-consumption when the SOC is high enough.
If you absolutely must have the PV available to loads early in the morning, then AC-couple the PV.
You can also do your own control via nodered.
Another thing that would be nice – and it has come up – is when you hit MinSoc, instead of disabling discharge and bouncing up and down between MinSoc and MinSoc+3%… instead just limit the AC power to whatever is on the DC side. Again, possible, but it adds complications. Which doesn’t mean it won’t happen, just that it needs lots of motivation.
Edit: This may well change with the Multi RS product. The Multi RS takes the PV on the HV-DC side (like a Goodwe) and it converts to AC more readily than it bucks down to battery voltage, so that in this case it will make a lot more sense to ask that PV goes to loads first. Which it may well already do, I am not fully up to date with the Multi RS (yet).
Any chance we might see support for SoC curves in future, as opposed to a single fixed value? Sure I can implement it myself (with difficulty), but it would be nice if it is built-in into Venus OS.
Having given this a lot of thought, I would like to be able to specify two values for every hour of the day:
Minimum SoC (unless grid fails): If the current SoC is below this value and the grid is available, then the multi will use the grid to charge the batteries back up to this level. This is the same as the current ESS “Minimum SOC (unless grid fails)” value, but specified hourly.
Self-consumption safety margin. This is an additional percentage safety margin on top of the minimum SoC above, also specified for every hour. The multi will avoid drawing power from the batteries if the current SoC is below [Minimum SOC + Safety Margin], unless the grid is not available.
(2) is new, and the idea behind it is that I can specify e.g. a 20% safety margin at night in case of loadshedding. I do not need that safety margin from an hour or so before sunrise until a few hours before sunset. Loadshedding usually only hits once a night, so I also do not want to recharge using the grid unless the safety margin is completely exhausted.
Currently I am constantly monitoring the loadshedding schedules, and if loadshedding is scheduled overnight I adjust the minimum SoC up. Unfortunately it recharges the batteries from the grid after loadshedding, which is not great. All this manual labour is also becoming bothersome.
I use HA to up the SOC the entire day. If SOC is like >28%, make Min SOC 25%, >33, make it 30% and so forth. Stop at 90% SOC.
Then I use NodeRed to match the inverter max to the panels by seeing what is drawn from the batteries to lower the inverter max watts.
Why?
To deal with the weather.
Spread battery use over 24h versus on-demand.
The only time I intervene is if there is an LS week, then I put the Min SOC up from 20% to like 50%.
Must say, if that becomes part of ESS, it would be awesome.
The Min SOC, the weather I see there is nogal accurate.
Apart from time constraints (which is my euphemism for laziness), one other reason why I have not taken the plunge and gone the automation route is that I am worried about the longevity of the flash storage in the Cerbo. If you’re constantly changing the configuration, would that not put excessive wear on it? Do we know what kind of flash is used, and what its endurance rating is?
Will hourly write cycles cause an issue a few years down the road, or am I being paranoid?
In the Cerbo? Nope, that has never factored into my thinking ever. I send data every minute up to my Victron port and it has a 5-year warranty. that should not be a concern methinks.
If you refer to an SD card on a Rpi, now THAT is a challenge yes.
My HA runs on a Win10 in a Hyper-V Linux OS, the server also hosting my Firewall on a 2nd Hyper-V instance using SSD drives.
The man behind the code is @Paul - I insist he shares it as there will be questions that I don’t have the answers for. It just works.
Ok here is the code.
This is if you are going to use the Cerbo with node red installed.
You will find some Victron nodes that communicates directly with with the modbus so you dont have to install other nodes.
I am also sending the data to my home automation so you might not need to use all the data but it has been running for a couple of months without any problems. flows.zip (5.8 KB)
Sorry for the Zip file but that is what I am allowed to up load.
Hope it helps!
