And there we go!!!
Next level:
Automate this process using a SOC setting in the system that gives a decimal %, and up the SoC to 0.1% less than that 5% bands up to a max SoC of 85%, for late afternoon it tops up to close to 100%.
Just a genuine question: why would you want to automate adjustment of SoC? Only example I can think of is when you’re integrated with the Muni’s (admittedly inaccurate) load shedding schedule? What am I missing?
Over time I have noticed, being in Cpt to boot, that I don’t:
I prefer to spread the loads over 24hours.
So from 10pm:
So by upping the SoC slowly I can get at ±10am to about +80% SOC when the first geysers starts.
Say it is 90% SoC, so what, use some of the batts, it is ok, but not below 80%.
2nd geysers starts at 1pm, by then I want to be at about 85%.
Both geysers stay on till 5pm, so use some batts if they must.
So by 3pm I aim for 90%+ SoC.
Then late afternoon I have the system on a Scheduled charge to not use any batts, as the SoC should then be reaching 95%+, ready for evening use, or at least min of 90%.
Here is a good example of what I am trying to do, peak cooking times are on Eskom for the cost to take that off the grid is 2 x 5kva MPII and doubling of the battery bank, the batts a Hobby, not a Need. 
And just to clarify, the over-riding motivation here is extending the life of the batteries?
Ditto … maximum cycles over their lifetime steering well clear of any consistent temp increases because no matter lithiums or lead acid, consistent high temperatures kill batteries prematurely.
So charge them hard when the ambient temp is reasonable and use them lightly when the ambient temps tend to be higher, for being grid tied, peak hour loads should be 100% from the panels in any case.
That makes perfect sense, thank you for the very detailed reply. I would desperately like to implement the same scenario with my system, but because Goodwe, it does a restart whenever you change any of it’s parameters (like min SoC). The driver we developed allows us to make such changes but the inverter restarting every time is annoying. As it is I’m already dealing with random restarts (a looooong saga in itself).
I think I have achieved the result you are looking for using rules in HA.
I charge my PylonTechs in the mornings using all the power the PV array can generate to keep the battery temps as low as possible early in the day.
I then have a rule that turns my geyser on at 93% SOC. The geyser will continue to run unless the PV array output has dropped below a threshold or the SOC has dropped below 91%.
I have scheduled the geyser to switch on several times during the day and run on a loop until 3PM at which time it will turn off and the array will top up the battery bank to 99% SOC before the sun sets.
My solution is unfortunately several rules in HA and certainly not as elegant as the solution you are seeking but it works very well for me.
My personal idea is just to shift the 20% odd Eskom power that I use every month to the early evenings rather than early mornings.
I live in an area which is prone to power outages (outside of Loadshedding unfortunately). This way I have batteries almost fully charged when I’m awake and have ample time to react should I have a power failure early evenings (busy automating that part too - switching off loads based on priority and SOC).
And if I have a power failure early morning I have enough batteries to get me to sunrise.
Granted it isn’t sunny every day, but at least it gives me some backup.
What is your min soc set to?
20% but never goes below 30% SOC
Damn, that is awesome!!!
I’ve got to like 15% in summer on 3.5kw panels. And if we don’t cook at night, then maybe I can get lower … BUT … now I have 4.2kw so we will see this summer.
But we still cook at night … with computers and other media for entertainment at night … maybe I must … naaa, I ain’t gonna go there, I like my life.
Sigh … I cannot get to 7% easily. 
The Min SoC last night was 35.5%, when the sun took over. Last 12 hours this is what I see:
It is 9:58am and geyser one is going to come on at 10am.
Because I allow the batts to gain some charge the SoC is now on 67% having powered the normal loads the whole morning as seen above. So this is 9:58am:
And then at 10am and geyser one came on. If it was not a nice day I would not want to use any batteries.
And if the system must, I have already set the Min SOC to 65%, in this scenario, only 2% of the batts will be used, which is a “so what” case.
And by 10h30, the batts have gained some charge, whilst the 2kw geyser and ±450w other loads where powered. At 70.1% SoC I set Min SoC to 70% - slowly building up to about 85% SoC.
Waiting for 70.1%, BMV SoC at 69.7% as I don’t want Eskom to interfere with MPPT doing it’s thing.
Right, automating it all.
This is what I thought so far:
- alias: Set ESS Min SoC Automatically
trigger:
platform: time_pattern
minutes: /5
condition:
condition: and
conditions:
- condition: sun
before: sunset
before_offset: +00:30:00
- condition: sun
after: sunrise
after_offset: -00:30:00
- condition: state
entity_id: sensor.bmv_soc
state: '36'
action:
service: modbus.write_register
data_template:
unit: 100
value: '{{ states(35)|int * 10 }}'
hub: victron
address: 2901
Thing is to do this:
sensor.bmv_soc = 36 then modbus.write_register = 35
sensor.bmv_soc = 41 then modbus.write_register = 40
sensor.bmv_soc = 46 then modbus.write_register = 45
etc
Why ‘states(35)’ in the template?
I saw this and thought lets try … what can possibly go wrong 
:
value: '{{ states(''input_select.victron_ess_minimum_soc'')|int * 10 }}'
And because I knew there are multiple values further complicating it all, it was a try …
How about something like this:
- alias: Set ESS Min SoC Automatically
trigger:
platform: time_pattern
minutes: /5
condition:
condition: and
conditions:
- condition: sun
before: sunset
before_offset: +00:30:00
- condition: sun
after: sunrise
after_offset: -00:30:00
- condition: template
value_template: "{{ (states('sensor.bmv_soc')|int) < 800 }}"
action:
service: modbus.write_register
data_template:
unit: 100
value: '{{ states(‘sensor.bmv_soc’)|int * 10 - 1 }}'
hub: victron
address: 2901
That way, every 5 mins, as long as the SoC is less than 80%, it’ll set the minSoc to SoC-1 (that’s what I assume the goal is?)
Spot on! And much simpler … this is so far above my head I cannot even see the sunshine.
But this monkey has a torch called copy/paste …
Two changes I made:
- alias: Set ESS Min SoC Automatically
trigger:
platform: time_pattern
minutes: /5
condition:
condition: and
conditions:
- condition: sun
before: sunset
before_offset: +04:00:00
- condition: sun
after: sunrise
after_offset: -00:30:00
- condition: template
value_template: "{{ (states('sensor.bmv_soc')|int) < 800 }}"
action:
service: modbus.write_register
data_template:
unit: 100
value: '{{ states(sensor.bmv_soc)|int * 10 - 1 }}'
hub: victron
address: 2901
Right, it ran, but did not up the Min SoC in ESS.
I set the last Current ESS Min SoC at 45%.
Wonder if it has anything to do that the Min SoC must be in 5’s like 30, 35, 40, 45 etc.
Yeah, that’ll be the reason.
You could change the action of the automation to set the MinSoc to the lower multiple of 5, if you wanted.
{{ states(sensor.bmv_soc)|int - 1 - ((states('sensor.bmv_soc')|int -1 ) % 50 ) }}
This essentially says: Goal value - (Goal value modulo 50), which gives the next lower multiple of 50 (since we’re dealing with a x10 situation)
Also, this does assume you have the automation to go from modbus minSoc to the input_select minSoc set up:
- alias: Set input select from Victron ESS Minimum SOC
trigger:
platform: state
entity_id: sensor.victron_ess_minimum_soc
action:
service: input_select.select_option
data_template:
entity_id: input_select.victron_ess_minimum_soc
option: '{{ states(sensor.victron_ess_minimum_soc) }}'