This is my configuration using node red. It’s specifically for a sonnen battery.
That did help, thanks.
I have to modify some things of course, as I have a high voltage system and I am not allowed to discharge from the battery to the grid.
One thing I do not really understand is that you seem to use the settings for prog6 (6. timeslot on “time of use” table/setting) exclusively, no other slots, and you never set the start and end time of that slot.
Can you elaborate a bit on that, e.g. what are the “default” values you have set in the “time of use” table of the Deye inverter?
And how did you determine the values for the selction in the automation? Where do they come from (grid power forcast > 5000, battery power forecast < -5000 etc etc
Yes the inverter runs constantly in prog6. 24 hours a day and doesn’t use any other proj. The modes of proj6 are changed via the scripts above to start/ stop charging depending on the EMHASS forecast.
With Amber the prices change every 5 minutes so there is no fixed peak period in a time of use sense. EMHASS just calculates the best times to charge and discharge.
These settings aren’t really used as the inverter stays in prog6 24x7.
Grid power forecast (grey shade) and battery power forecast (green shade) are generated by EMHASS, see daily forecast chart above. They are the controlling function, when EMHASS says we should charge battery forecast < -5000 and we switch prog6 into backup mode to allow grid.
1 Like
That makes sense, thanks for the explanation.
As I am not allowed to discharge to the grid, I’ll modify the script for that.
Our prices change every hour, not every 5 minutes, but that shouldn’t change the configuration here (it does for the forecast calculation).
I’ll try it as soon as I have got the shell_commands from HA to EMHASS working again, I have messed up the commandline (most probably a } at the wrong place in the string, and I can’t find it … ))
I’ver run into another problem: the day-ahead optim always sets “infeasible” as staus, even when “Status: Optomal” is found in the logs.
Any idea how to hunt down this issue?
**Result - Optimal solution found**
Objective value: -4.54884545
Enumerated nodes: 2
Total iterations: 1916
Time (CPU seconds): 0.76
Time (Wallclock seconds): 0.81
Option for printingOptions changed from normal to all
Total time (CPU seconds): 0.77 (Wallclock seconds): 0.82
2024-08-04 09:33:58,441 - web_server - INFO - **Status: Optimal**
2024-08-04 09:33:58,441 - web_server - INFO - Total value of the Cost function = -4.55
2024-08-04 09:33:59,005 - web_server - INFO - Passed runtime parameters: {}
2024-08-04 09:33:59,005 - web_server - INFO - >> Setting input data dict
2024-08-04 09:33:59,005 - web_server - INFO - Setting up needed data
2024-08-04 09:33:59,009 - web_server - INFO - >> Publishing data...
2024-08-04 09:33:59,009 - web_server - INFO - Publishing data to HASS instance
2024-08-04 09:33:59,068 - web_server - INFO - Successfully posted to sensor.p_pv_forecast = 5171.6
2024-08-04 09:33:59,087 - web_server - INFO - Successfully posted to sensor.p_load_forecast = 994.0
2024-08-04 09:33:59,106 - web_server - INFO - Successfully posted to sensor.p_hybrid_inverter = 5171.6
2024-08-04 09:33:59,126 - web_server - INFO - Successfully posted to sensor.p_deferrable0 = 677.6
2024-08-04 09:33:59,153 - web_server - INFO - Successfully posted to sensor.p_deferrable1 = 1000.0
2024-08-04 09:33:59,175 - web_server - INFO - Successfully posted to sensor.p_deferrable2 = 2500.0
2024-08-04 09:33:59,193 - web_server - INFO - Successfully posted to sensor.p_batt_forecast = 0.0
2024-08-04 09:33:59,219 - web_server - INFO - Successfully posted to sensor.soc_batt_forecast = 60.0
2024-08-04 09:33:59,290 - web_server - INFO - Successfully posted to sensor.p_grid_forecast = 0.0
2024-08-04 09:33:59,312 - web_server - INFO - Successfully posted to sensor.total_cost_fun_value = 0.91
2024-08-04 09:33:59,334 - web_server - INFO - Successfully posted to **sensor.optim_status = Infeasible**
2024-08-04 09:33:59,352 - web_server - INFO - Successfully posted to sensor.unit_load_cost = 0.37
2024-08-04 09:33:59,372 - web_server - INFO - Successfully posted to sensor.unit_prod_price = 0.0744
forget about that - this was strange:
the Nordpool integration (which I use to get prices) had spontaneously decide (today around noon) to throw away the configured sensor entity and create a new one with a different name and without the additiobal_cost template … obviously EMHASS could not find any values in the now unavailable old variable… deleting the integration entity, creating a new one and renaming it to the name configured in EMHASS fixed the issue - for now.
I guess there must be something wrong with my EMHASS setup:
discharge reaches 6 kW (which is well inside the limit, the battery can do 10 kW charge/discharge), but the charge forecarst never goes above 1 kW - this seems very strange.
Any idea where to start to hunt this down?
I wonder if the brains trust here can help me validate what I see with my home setup. I have three phase with three single phase inverters, three power walls behind the Tesla backup gateway. Due to voltage rise issues I have site export limits on pv inverters, basically I can export max 5kw across the phases.
I have implemented an automation (based on @markpurcell s work) to control the power walls in response to batt SOC forecast from EMHASS.
The problem is I can’t get the power walls to export. I assume they are configured to prevent grid export via some kind of site export limit (distinct from the limits on the pv inverters).
Is this likely?
Second quick question, how do people take demand charges into account when sending a price forecast to EMHASS?
Here’s how I deal with the demand window on Ausgrid. Basically I set the price to $1.00 for the window from 15:00 to 21:00 so that the system always plans to use battery during this period. EMHASS: An Energy Management for Home Assistant - #2484 by altonius
1 Like
@markpurcell congrats on your recent media appearances!!! "One household at a time:" 50,000 homes with batteries could displace a gas peaker plant - One Step Off The Grid (I hope that is you 
).
Sounds like a whole new generation of EMHASS users.
4 Likes
make that 49,999 friends needed now
2 Likes
Hi,
Can someone please help a newbie understand if it’s EMHASS I need?
tl;dr: I don’t care about automatically deferring loads, can EMHASS just monitor the 5 minute energy price, energy levels and send signals to my inverter to charge or discharge from grid based on some rules?
I have three different inverter make/models (MPP, Growatt, Goodwe), Victron battery monitor and 3EM CT, all accessible through MQTT. None of my inverters support an “Auto” mode (maintain the current charge level automatically using grid) because no one inverter sees everything that’s going on (automation is the glue), I might need to create a PID in node-red that can “hunt” to maintain a certain charge level, not sure.
Ideally, every day I’d like to get to solar sunset with a 100% SoC and try and make some money selling battery when the price spikes in the evening shoulder, waking up in the morning to a 35% SoC. As cheaply as possible.
I put more detail here:
Thanks.
It is feasible.
You could run EMHASS once per day (in the morning) with dayahead approach and target 35% battery in the morning. Then set the cost function to profit and let EMHASS do the optimisation and decide the intermediate SoC during the day. Publish the results every five minutes or even better run in the middle at high frequency in MPC mode to have fresh computation.
See this picture for an idea
https://emhass.readthedocs.io/en/latest/lpems.html#the-emhass-optimizations
The tricky part could be splitting the signals to control three different appliances.
Just do not set any deferrable loads if you do not need them.
1 Like
Thanks, it may be simpler than that, only one inverter does grid to battery charging and battery to grid discharging.
On charging/discharging what signal does EMHASS usually use to kick off charging/discharging, my “blind” charger (Goodwe SBP that’s way to far away from the meter box to allow its own CT clamps to be used) currently accepts a signal to charge/discharge at a certain amount of watts and just keeps going until I stop it (I have protections against overcharging and letting the voltage get too low):
discharge 5000
charge 3000
Can EMHASS operate like that, or does it signal some other way?
Read this document here (EMHASS configuration for sonnen battery) specifically section 3.2.
EMHASS passes its forecast calculations into HA via the sensors described in section 3.2. It’s up to you have you action the forecast.
1 Like
That is exactly how the EMHASS p batt forecast sensor works.
It will be 5000 for discharge and -3000 for charge.
1 Like
Thanks!
Can anyone point me to a good “EMHASS for Dummies” guide, I can’t make head nor tail of the manual, any blog posts, YouTube videos, anything like that (I cant find anything using Google)?
A basic starter quick guide, I’ve being doing things in node-red and so I’ll have to setup the “relevant” energy sensors (MQTT) and inverter actuator (MODBUS TCP) in HASS first, I’m staring up the side of a mountain in a kind of project paralysis, HASS is very cool but it’s all new to me.
Go on “Tell him he’s dreaming”!
I’ve been in IT for 30 years and its not helping lol.
That document I pointed you towards is a basic configuration using Node-Red. It’s for a sonnen battery system which is a hybrid battery system meaning that the internal inverter in the battery is used to control charging/discharging. This is done via the battery REST API using Node-Red HTTP request nodes. 90% if the system is in Node-Red.
1 Like
Thanks, doh, I skimmed your post and missed the hyperlink, it looks great!
Thanks, I’m a bit confused though, can you expand on this a bit, what does “p batt” mean, grid power to/from battery?
Why is it a forecast “sensor”, does that not imply that its an input, is “p batt” exposed to HASS and then I use it in an automation to control my inverter?
So much to learn here 
The sensor p bat forecast has the current export or import Wattage required to achieve the plan. It also has the future forecast values expected to continue to follow the plan as attributes. So you can take the p bat forecast and apply it to the battery to implement what EMHASS has calculated to be the best outcome. Negative value is charge and positive is discharge.
As an alternative you can use soc batt forecast which has the expected percentage SoC and calculate what power to apply over the next 30 min to achieve that charge. Again this sensor has forecast values as attributes which you can plot on a graph to see what the system is planning to do.
1 Like