Now just to optimise it into a single automation!
2 Likes
Is it possible to do something like, instead of 30 and 35:
Min(Round down SOC to nearest multiple of 5,30);
Min((Round down SOC to nearest multiple of 5),30) + 5;
?
The Min part is just to make sure you never go below X, 30 in this case. It could also be an input.
As it is currently working, it is SPOT ON what I wanted … starts at Min SOC of 30.
Hits >40, set SOC to 35
45, set SOC to 40
50, set SOC to 45
… and so forth.
The 5% increments are GOOD … maybe even 10 to have some more leeway ito clouds etc.
Will try that.
Summer and winter differ ito settings.
Now I get to 5 pm with 100% SOC, optimal battery usage daytime, not pushing the batts hard for extended periods of time with big loads … and I did nothing to make it so.
YES!!! 
Yeah I am sure it does, I was just thinking how to make it a single automation instead of something like 14?
1 Like
I also think I’m going to try and implement this, when I ever get chance again between work, construction at home and a 10 month old baby…
I don’t want to use my batteries during the day, so I’d even replace the exact times (though those could be inputs on the UI) with the sunrise and sunset variables I believe to already be in HA somewhere, maybe offset by an hour.
And I’ll see if a type of SOC | round(SOC/5,”floor”)*5 thing can work.
I’m obviously very new at HA, but I don’t understand why YAML needs to be so difficult to work with when it comes to calculations and variables. Why can’t I just code with normal IF statements and mathematical operations on variables. Maybe I can and I just don’t understand templating well enough yet.
1 Like
+1
There was a “version”, if memory serves, that tried to make it “all-in-one”, but it also worked in the reverse i.e. lowering the MIN SOC under certain conditions, now this close as damn “IF THEN” version.
As one of my developers once said to me: “IF” there is a benefit to change the code (i.e. works MUCH better faster saving a lot MORE users time), “THEN” then we do it, “ELSE” we leave it. 
EDIT: But then there is also the case of “let’s do it, why not!?” and someone comes along, sees the code, and choef chaf new code is there …
I’m not sure how HA executes code, but my intuition would tell me that 17 automations vs 1 automation would probably not make a big difference in CPU usage. But I dislike scrolling a lot. 
1 Like
OK guys. I’m thinking of something. Well, this is on my TODO at the bottom of a heap of other things with higher priority… but… maybe the lazynet™ will do it for me.
(That is a term for putting an idea out on the internet that you are too lazy to do yourself, or don’t have time for, and then someone else does it 
).
The idea is this: Build an integration for HA+Venus, similar to one of these:
or…
It would also be nice if it auto-discovers, which you can implement easily using either mDNS (it responds to the name venus.local) or by using uPNP.
3 Likes
Yeah, I saw other brand names interfacing … so I left it right there.
Methinks it would be super cool if Venus / HA gets some TLC. 
Absolutely shocking that there isn’t already a Victron integration. 
If I understand correctly, the benefit of this would be that you don’t need to manually load all the addresses from ModBus that you want? It will all already be detected and added as sensors?
Correct. That would be the idea. What I would like to avoid is needlessly polling the entire range, it should be possible to know what is available and only query that which is actually used by a sensor. Also, the slave address equals the DeviceInstance, and you may have multiple, so it also needs a way to discover that stuff.
Since a few versions ago, there is a dbus service (com.victronenergy.modbustcp) that advertises what modbus addresses are available, and this is also shown on the GUI (to make it easier for people).
So one of the challenges is to make that information available so an external service can easily obtain it. I could probably expose that information through modbus-tcp itself, but doing it that way would be limited to some static number of services. The alternative is to spit out some json over http. Or something.
Sounds great plonkster. I probably need to dust off my Python and start doing something like this too (or helping if you go for something).
1 Like
I’ve actually created a second sensor that automatically determines the nearest 5% point below the current SOC, minus 5% or 10% depending on what you want.
Just didn’t get around to implementing it yet and TTT was too keen on getting something working, so we went for the manual route with gazillions of automations.
Here’s the code:
sensors:
- platform: template
sensors:
victron_minimum_soc_target:
friendly_name: "Trailing SOC minmum target"
value_template: >-
{%- if ((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) >= states.sensor.victron_battery.state | int -%}
{{ (((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) - 10) | int }}
{%- else -%}
{{ (((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) - 5) | int }}
{%- endif -%}
Here’s a graph with all three:
- My actual SOC
- The min SOC of the Venus (as set by the bunch of automations so far)
- The extra sensor I’v added but not yet using
Needless to say, it still has issues:
- went to -10 for some reason
- It doesn’t go back to my “nightly discharge min of 30%” target, instead it backtracks again as the SOC starts falling.
The current min SOC as set by the automations works well and follows the curve quite closely with a couple of % points to dip into battery during the day before falling back to Eskom.
2 Likes
The -10 thing could be because one of the dependent variables was unavailable at a single point in time.
Have you tried adding an availability template to your sensor?
eg:
sensors:
- platform: template
sensors:
victron_minimum_soc_target:
friendly_name: "Trailing SOC minmum target"
value_template: >-
{%- if ((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) >= states.sensor.victron_battery.state | int -%}
{{ (((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) - 10) | int }}
{%- else -%}
{{ (((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) - 5) | int }}
{%- endif -%}
availability_template: >-
{%- if not is_state("sensor.victron_battery", "unavailable") %}
true
{%- endif %}
Good idea, will try that.
Then again, I’m not sure I’ll use a sensor for this, this was mostly just to test the calculation.
Can one set variables in HA’s trigger or condition templates and thus re-use them? Putting in the whole calculation (((states.sensor.victron_battery.state | int / 10) | round(1,"half") * 10) - 10) | int multiple times becomes painful.
afaik you can use set
Example:
{% set temp = states('sensor.solar_yield_yesterday_ne_raw') %}
The yield yesterday was {{ temp }}
So my automations that I set up with @TheTerribleTriplet and @jykenmynie a while back helped a lot last weekend, when we had an unexpected (non-loadshedding) power outage Friday evening around 19:30.
We had been using the oven earlier the evening, and my system typically start eating away at the batteries anywhere from 16:30 as PV yield wanes. In the past this would have gone a lot into the batteries and just go wild, but now it stops at 95% and goes back to Eskom.
So when the power went out I still had 95% of battery life left. I then monitored everything extra careful and eventually the power came back around 1:00 and still had ample SOC left at that point.
In the past I would have likely reached 30% by 1:00 (and thus switch back to Eskom if available), so it would have been a lot more nerve-wrecking on Friday evening, having only 22% left (the Pylontechs switch off at 8%, so 30 - 8% = 22%).
3 Likes
I now have NodeRed running on HomeAssist too … to match the inverter with the panel wattages, as this Cpt winter fooked me up good.
1 Like
This is what I do with Home Assistant. It works great. Much more control over the system and more peace of mind.
Yes, it doesn’t save as much as you would otherwise, but I’d rather buy an extra 2kWh from Eskom every day than risk it in the winter. In the summer I’ll up my daytime inverter capacity to be a few hundred watts above the panels.
Hi,
What theme is this and what card are you using for PV power?