EMHASS: An Energy Management for Home Assistant

Thanks for the answer @altonius!

I just tried a vanilla config file (emhass/config_emhass.yaml at dd00d438df95d78210fef52638ce472aafaf1805 · davidusb-geek/emhass · GitHub) and I am still getting the “infeasable” flag. Could there any remnants which need deleting prior to trying new parameters?

Try a different weather forecast method.
You will get infeasible results if scrapper returns negative values.

Thanks @stevenwhately !!
That was it: I changed to weather_forecast_method: 'solcast' and now I finally get:

All as expected, thanks again for the help!

1 Like

Hi team, will I always run into issues with 0 days of history everytime I restart HA or is it just me?

The retrieved JSON is empty, A sensor:sensor.power_load_no_var_loads may have 0 days of history, passed sensor may not be correct, or days to retrieve is set too heigh\n","ERROR - web_server - Unable to get sensor power photovoltaics, or sensor power load no var loads. Check HA sensors and their daily data

Yeah, I have that too. Every time I update HA or Emhass. Would have something to do with recorder settings. Somewhere above here it’s explained. I haven’t looked into it yet.

I always had that issue until I implemented an ‘include’ statement to restrict recording to a minimal list of sensors and deleted my recorder database to start afresh.

Now I’ve constructed a variable called input_text.fifo_buffer to pass into the MPC calculation as the load_power_forecast dictionary key, like Mark does. This avoids using the recorder database altogether.

THe way Mark does it is documeneted above (just search for fifo in this topic) and the way I do it using Node-Red is documented in my configuration doco here.

1 Like

Hi Guys, I came across this thread while looking for a solution to maximise the use of my solar production to heat the house. I have a 6 zone HVAC unit which i am trying to control with this EMS.

We normally set the HVAC to turn on in the living room and one of the bedrooms to 20°C. As the sun rises, i’ve noticed the bulk of the solar is getting exported back to the grid. Rather than send it back to the grid, i want the HVAC to utilize it by increasing the HVAC temperature gradually till it gets to about 23°C and then later in the afternoon as the sun begins to set, i want the HVAC to start dropping the temperature back to 20°C. This will allow me to maximize the consumption of the solar production for our comfort rather than send it back to the grid for peanuts.

i installed EMSHaas and done the initial configuration to set the optimization schedule, but how should i proceed from here?

I’ve borrowed some parts of your code in node-red and been running for a while now. It’s running fine from what I can see.

1 Like

Is it possible to have a Deferrable load start immediately, and then stay on until it is turned off?

Getting some crazy numbers, but still claiming to be optimal ;-(

Very hard to debug which constraint is causing this issue.

2024-06-23 11:56:30,195 - web_server - INFO - Passed runtime parameters: {'prod_price_forecast': [-0.02, -0.02, -0.01, -0.01, 0.08, 0.1, 0.09, 0.21, 0.24, 0.31, 0.4, 0.49, 0.53, 0.5, 0.45, 0.4, 0.4, 0.39, 0.33, 0.3, 0.27, 0.28, 0.28, 0.16, 0.15, 0.11, 0.15, 0.11, 0.11, 0.08, 0.09, 0.09], 'load_cost_forecast': [0.05, 0.05, 0.06, 0.06, 0.16, 0.18, 0.18, 0.31, 0.48, 0.56, 0.66, 0.76, 0.8, 0.77, 0.71, 0.66, 0.66, 0.65, 0.44, 0.41, 0.37, 0.39, 0.39, 0.25, 0.25, 0.2, 0.25, 0.21, 0.2, 0.17, 0.18, 0.18], 'prediction_horizon': 31, 'alpha': 0, 'beta': 1, 'soc_init': 0.578, 'def_start_timestep': [0, 0, 19], 'def_end_timestep': [0, 0, 34], 'def_total_hours': [1, 0, 6], 'soc_final': 0.08}
2024-06-23 11:56:30,196 - web_server - INFO -  >> Setting input data dict
2024-06-23 11:56:30,197 - web_server - INFO - Setting up needed data
2024-06-23 11:56:30,207 - web_server - INFO - Retrieve hass get data method initiated...
2024-06-23 11:56:35,571 - web_server - INFO - Retrieving weather forecast data using method = scrapper
2024-06-23 11:56:40,408 - web_server - INFO - Retrieving data from hass for load forecast using method = naive
2024-06-23 11:56:40,411 - web_server - INFO - Retrieve hass get data method initiated...
2024-06-23 11:56:52,887 - web_server - INFO -  >> Performing naive MPC optimization...
2024-06-23 11:56:52,888 - web_server - INFO - Performing naive MPC optimization
2024-06-23 11:56:52,953 - web_server - INFO - Perform an iteration of a naive MPC controller
2024-06-23 11:56:53,137 - web_server - DEBUG - Deferrable load 0: Proposed optimization window: 0 --> 0
2024-06-23 11:56:53,138 - web_server - DEBUG - Deferrable load 0: Validated optimization window: 0 --> 0
2024-06-23 11:56:53,161 - web_server - DEBUG - Deferrable load 1: Proposed optimization window: 0 --> 0
2024-06-23 11:56:53,162 - web_server - DEBUG - Deferrable load 1: Validated optimization window: 0 --> 0
2024-06-23 11:56:53,185 - web_server - DEBUG - Deferrable load 2: Proposed optimization window: 19 --> 34
2024-06-23 11:56:53,185 - web_server - DEBUG - Deferrable load 2: Validated optimization window: 19 --> 31
2024-06-23 11:56:54,372 - web_server - INFO - Status: Optimal
2024-06-23 11:56:54,373 - web_server - INFO - Total value of the Cost function = 10251017.19
2024-06-23 11:56:55,556 - web_server - INFO - Passed runtime parameters: {'custom_unit_load_cost_id': {'entity_id': 'sensor.unit_load_cost', 'unit_of_measurement': '$/kWh', 'friendly_name': 'Load Cost'}, 'custom_unit_prod_price_id': {'entity_id': 'sensor.unit_prod_price', 'unit_of_measurement': '$/kWh', 'friendly_name': 'Prod Price'}}
2024-06-23 11:56:55,557 - web_server - INFO -  >> Setting input data dict
2024-06-23 11:56:55,558 - web_server - INFO - Setting up needed data
2024-06-23 11:56:55,567 - web_server - INFO -  >> Publishing data...
2024-06-23 11:56:55,567 - web_server - INFO - Publishing data to HASS instance
2024-06-23 11:56:55,655 - web_server - INFO - Successfully posted to sensor.p_pv_forecast = 6684.58
2024-06-23 11:56:55,718 - web_server - INFO - Successfully posted to sensor.p_load_forecast = 1017.38
2024-06-23 11:56:55,755 - web_server - INFO - Successfully posted to sensor.p_pv_curtailment = 0.0
2024-06-23 11:56:55,795 - web_server - INFO - Successfully posted to sensor.p_deferrable0 = 3600.0
2024-06-23 11:56:55,834 - web_server - INFO - Successfully posted to sensor.p_deferrable1 = 0.0
2024-06-23 11:56:55,871 - web_server - INFO - Successfully posted to sensor.p_deferrable2 = 125012500000.0
2024-06-23 11:56:55,909 - web_server - INFO - Successfully posted to sensor.p_batt_forecast = 50004992000.0
2024-06-23 11:56:55,952 - web_server - INFO - Successfully posted to sensor.soc_batt_forecast = -92782642.2
2024-06-23 11:56:55,990 - web_server - INFO - Successfully posted to sensor.p_grid_forecast = -25002494000.0
2024-06-23 11:56:56,024 - web_server - INFO - Successfully posted to sensor.total_cost_fun_value = 10251020.84
2024-06-23 11:56:56,056 - web_server - INFO - Successfully posted to sensor.optim_status = Optimal
2024-06-23 11:56:56,093 - web_server - INFO - Successfully posted to sensor.unit_load_cost = 0.05
2024-06-23 11:56:56,130 - web_server - INFO - Successfully posted to sensor.unit_prod_price = -0.02

Fixed: Reduced battery_minimum_state_of_charge from 0.05 to 0 and numbers are sensible again…

Seeing some odd def_end_timestep optimisations with my 600 W heat pump, which I want to complete a 6 hour run by sunset.

p_nom is 600W, but then just before the def_end_timestep it tries to schedule 4800W for this load?

I have been using EMHASS for two years now and it works perfectly for me. However, PPVmix with the coefficients alpha and beta (tried all variants) simply does not work for me (the values do not change at all). Here, for example a mpc call, with a prediction horizon of 10, first value in the array is the actual PV Power Sensor .
Input:
“pv_power_forecast”: [3569, 8171, 7695, 6282, 5381, 4683, 3723, 2635, 1803, 1344]
Output:

No errors in the log, status: optimal

I’ll answer myself if anyone else finds it useful-
It is no more difficult than taking the time it should be on, which in my case is the washing machine for 1 hour. Then send mpc-optim

"def_end_timestep": [1, 0, 0]

I think I have asked of this earlier. But im almost completed a Geothermal Heat Pump at home with a big accumulation tank.

Any suggestions on how we can use emhass to control this?

What setting did you set for this load on treat_def_as_semi_cont ? I believe I had similar behaviour (charging my car with 6000*6 watts…), but this did not happen after I set the treat_def_as_semi_cont to true.

treat_def_as_semi_cont is true

A couple of options are available,
. how much per does it draw?
. What are your typical run hours?
. Do you have a temperature sensor in Home Assistant?

You could:
. Run for set number hours each day
. Calculate run hours based on temp
. Specify run hours before defined events, run hours before sunrise/ sunset

guess this can depend on how cold its outside. on how much heat that are going to be used. Norwegian winter :slight_smile:

another question. is it possible to run 2 instances of emhass? 1 for current in use and one for testing?

You can run the same instance with different inputs and use the prefix parameter to produce different sensors.

Or you can run two instances in different containers, but might end up with namespace clashes.