On 3 October at 19:45, EMHASS came up with a strange plan: 1 kW of export, and a home battery helping to charge the car. Two things my setup is designed to prevent. The cause of this wrong SoC was not in EMHASS, but in the minutes after a Home Assistant restart.
What happened
I had just restarted Home Assistant. The inverter is read through the Sunsynk add-on, and after a restart those entities only become available after a few minutes. In that window, the optimisation for the current quarter hour ran.
The payload for EMHASS had a fallback value for the battery level (state of charge, SoC): 50 %. The real level was 57 %. So EMHASS calculated from a made-up starting point, and came up with a plan that made sense for that number, but not for reality.
The fix
The optimisation now only runs when the SoC is a real number greater than zero. As a condition in the automation:
condition:
- condition: template
value_template: >
{{ states('sensor.ss_battery_1_soc') | float(0) > 0 }}With float(0), unavailable and unknown become zero, so they are filtered out. If a run is skipped, the next quarter hour simply runs again. The translator that carries out the plan also waits three minutes after a restart until the inverter entities are there, before it writes anything.
The lesson
A fallback value is a made-up value. For a dashboard display that is handy; for a calculation that decides what the battery does, it is a risk. Better no plan than a plan based on an assumption. A plan older than 45 minutes puts the translator in a safe mode anyway.
The full setup: EMHASS and the battery. All incidents: Lessons from practice (in Dutch for now).
Not running EMHASS yet? Then start with Install EMHASS in Home Assistant.
These values apply to one installation. Check them against your own documentation; leave work on 230/400 V to a qualified electrician.
Leave a Reply