EMHASS: An Energy Management for Home Assistant

Share your Projects! Custom Integrations
1470

I have a Magic Button gate mechanism which uses 433MHz remote. My old Tesla model 3 had a HomeLink garage door opener built into the car but it didn’t work because the magic button system is encrypted.

So I have to put a Sonoff SV in the gate controller and wire it into the terminals that toggle the gate open and shut and put a magnetic switch on the gate to detect when it was closed and then use a Sonoff 433MHz bridge to work with the Tesla HomeLink.

image
image764×573 63.5 KB

The new Model Y doesn’t have a HomeLink built in so I’m back to a remote button again.

2 Likes
1471

Great to see the fix coming in. As an FYI if you have a Gen3 Tesla wall charger you can use sensors from it to see if a vehicle is connected rather than rely on the location tracker in the Tesla.

1472

Hello!

Big thanks to davidusb for this excellent development and also to markpurcell for contributing with his knowledge. This an fascinating topic.
I also started to test this integration and and few questions and issues. Maybe it’s already touched in this thread but it’s a long one and couldn’t find the answer.

First item for EU users who are buying electricity according to Nordpool spot price (including me). Since day ahead prices are published every day afternoon, we get at least a 36h forecast for energy prices. So it’s a 12 hour advantage compared to EMHASS 24h optimization. It would be great if we could take this into use somehow. Maybe it is but I’ve understood it’s possible to do only 24h ahead optimizations?
Other item is, I found EMHASS results to be 1 hour off from inserted values.
If I post forecast values at 23:55 of solcast and nordpool, they are reported with one hour lag in results. I’ve attached some explaining pictures:

EMHASS report:

EMHASS_report
EMHASS_report424×552 60.7 KB

Solar forecast from energy tab:
Will add in next post due to “New user” restrictions

Solar in EMHASS:
Will add in next post due to “New user” restrictions

Nordpool price list:
today:

  • 16.045
  • 16.196
  • 15.931
  • 14.994
  • 14.902
  • 15.672
  • 17.012
  • 28.02
  • 28.608
  • 28.608
  • 28.607
  • 28.607
  • 28.019
  • 27.631
    - 24.605
  • 28.607
  • 28.607
  • 32.153
  • 30.695
  • 26.08
  • 23.945
  • 23.348
  • 19.74
  • 18.74
    raw_today:
  • start: “2023-11-16T00:00:00+02:00”
    end: “2023-11-16T01:00:00+02:00”
    value: 16.045
  • start: “2023-11-16T01:00:00+02:00”
    end: “2023-11-16T02:00:00+02:00”
    value: 16.196
  • start: “2023-11-16T02:00:00+02:00”
    end: “2023-11-16T03:00:00+02:00”
    value: 15.931
  • start: “2023-11-16T03:00:00+02:00”
    end: “2023-11-16T04:00:00+02:00”
    value: 14.994
  • start: “2023-11-16T04:00:00+02:00”
    end: “2023-11-16T05:00:00+02:00”
    value: 14.902
  • start: “2023-11-16T05:00:00+02:00”
    end: “2023-11-16T06:00:00+02:00”
    value: 15.672
  • start: “2023-11-16T06:00:00+02:00”
    end: “2023-11-16T07:00:00+02:00”
    value: 17.012
  • start: “2023-11-16T07:00:00+02:00”
    end: “2023-11-16T08:00:00+02:00”
    value: 28.02
  • start: “2023-11-16T08:00:00+02:00”
    end: “2023-11-16T09:00:00+02:00”
    value: 28.608
  • start: “2023-11-16T09:00:00+02:00”
    end: “2023-11-16T10:00:00+02:00”
    value: 28.608
  • start: “2023-11-16T10:00:00+02:00”
    end: “2023-11-16T11:00:00+02:00”
    value: 28.607
  • start: “2023-11-16T11:00:00+02:00”
    end: “2023-11-16T12:00:00+02:00”
    value: 28.607
  • start: “2023-11-16T12:00:00+02:00”
    end: “2023-11-16T13:00:00+02:00”
    value: 28.019
  • start: “2023-11-16T13:00:00+02:00”
    end: “2023-11-16T14:00:00+02:00”
    value: 27.631
  • start: “2023-11-16T14:00:00+02:00”
    end: “2023-11-16T15:00:00+02:00”
    value: 24.605
  • start: “2023-11-16T15:00:00+02:00”
    end: “2023-11-16T16:00:00+02:00”
    value: 28.607
  • start: “2023-11-16T16:00:00+02:00”
    end: “2023-11-16T17:00:00+02:00”
    value: 28.607
  • start: “2023-11-16T17:00:00+02:00”
    end: “2023-11-16T18:00:00+02:00”
    value: 32.153

Data is forwarded by this shell command:
trigger_emhass_forecast: “curl -i -H "Content-Type: application/json" -X POST -d ‘{"load_cost_forecast":{{((state_attr(‘sensor.nordpool_kwh_ee_eur_3_05_02’, ‘raw_today’) | map(attribute=‘value’) | list + state_attr(‘sensor.nordpool_kwh_ee_eur_3_05_02’, ‘raw_tomorrow’) | map(attribute=‘value’) | list))[now().hour:][:24] }},"prod_price_forecast":{{((state_attr(‘sensor.nordpool_sell’, ‘raw_today’) | map(attribute=‘value’) | list + state_attr(‘sensor.nordpool_sell’, ‘raw_tomorrow’) | map(attribute=‘value’) | list))[now().hour:][:24]}},"pv_power_forecast":{{states(‘sensor.solcast_24hrs_forecast’)}}}’ http://localhost:5000/action/dayahead-optim”

So what about 1,5 day forecasting option and is there a way to get EMHASS results with correct timestamps?

1473

And now the solar forecast from Energy tab:

Energy_solar
Energy_solar482×508 28.7 KB

1474

And solar forecast shown in EMHASS:
EMHASS_solar

1475

Try to set the “timestamp rounding”
“Last” would associate the results to 00:00, “first” to 23:00, “nearest”… well… to the nearest; in your case 00:00.
This should be related to the fact you are passing the 23:00 slot cost as first item of the list (I see 16,94 in the table). Other people using nordpool may confirm.

2 Likes
1476

Dear community,
I have a rather simple question I guess, but haven´t found any documentation or workaorunds on this one…

Is it possible to set defferable loads not to run in parrallel?
E.g. I have a heat pump which I want to use for two defferable loads, heating and warm water production. This can´t be done at the same time. So I have to tell these two defferable loads not to run at the same time.
Is this possible?

1477

Thank You very much! That was the case. Somehow didn’t catch that from manual.

1 Like
1478

You can set up as 2 deferable loads, the emahss will recognise this, but you will need to setup up automations from this to actually command the heatpump to turn it on.

Within automations set a condition to operate priority with the conditions you want. So i.e heatpump hot water has priority over the pool or whatever the load. Then emhass will re calculate the loads and operate accordingly.

1479

I remember reading somewere you had some log data or soemrhing to record logs outside of emhass and it was picking up errors emhass wasnt writting.

I have multiple watchdogs now that are continuously revooting and checking values so it doesnt fail. So far no errors but node red has something clocking its program and not writting errors. I can not find it for the life of me

1480

I just write content of RESTful errors (POST return code 201 and PUT return code 200), and what was sent to cause the error, into a text file with a time stamp so I can review them later. I do this for POSTs and PUTs to my battery and also the POST to EMHASS.

This allows me to review exacty what was sent to EMHASS when it recorded an error in it’s log file or when the sensor.p_batt_forecast change sent to the battery fails for some reason.

These log files are created in the ‘\hassio\share’ directory where the Node-Red ‘Write File’ node can create files.

1481

Thanks for your response.
I know that I can setup more than one deferrable load but haven`t found a way to tell emhass to plan the timeframe of all loads (or just some loads) sequentially. Most of the times it plans both loads (hot water and heating) at the same time but this is not possible since the heat pump is only capable of doing one at a time.

1482

For some reason pv_power_forecast drops to zero by time now?

image
image718×913 31.8 KB

Even through POST data seems correct:

{
“prod_price_forecast”: [-0.05, -0.06, -0.07, -0.07, -0.08, -0.08, -0.07, -0.07, 0.22, 0.24, 0.26, 0.3, 0.33, 0.31, 0.31, 0.33, 0.34, 0.36, 0.41, 0.42, 0.16, 0.16, 0.14, 0.13, 0.09, 0.07, 0.08, 0.09, 0.09, 0.11, 0.09, 0.09, 0.07, 0.07, 0.07, 0.07, 0.07, 0.09],
“load_cost_forecast”: [0.06, 0.05, 0.03, 0.03, 0.03, 0.03, 0.03, 0.04, 0.3, 0.32, 0.35, 0.39, 0.42, 0.39, 0.4, 0.42, 0.43, 0.45, 0.5, 0.51, 0.27, 0.27, 0.25, 0.23, 0.19, 0.17, 0.18, 0.19, 0.19, 0.21, 0.19, 0.19, 0.17, 0.17, 0.17, 0.17, 0.17, 0.19],
“pv_power_forecast”: [3421, 3698, 3865, 4058, 4176, 4228, 4212, 4079, 3941, 3766, 3494, 3180, 2780, 2351, 1862, 1345, 789, 319, 52, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 5, 80, 289, 586, 937, 1264, 1532, 1760, 1941, 2008, 1986, 2009, 2069, 2100, 2113, 2146, 2146, 2084, 1902, 1662, 1405, 1172, 972, 800, 567, 305, 86, 22, 0, 0, 0, 0, 0, 0, 0, 0, 0],
“prediction_horizon”: 38,
“alpha”: 0,
“beta”: 0,
“num_def_loads”: 2,
“def_total_hours”: [3,4],
“P_deferrable_nom”: [1300, 7360],
“treat_def_as_semi_cont”: [1, 0],
“set_def_constant”: [0, 0],
“soc_init”: 0.14,
“soc_final”: 0.12
}

p_load_forecast does the same:

image
image702×909 35.2 KB

{
“prod_price_forecast”: {{
([states(‘sensor.cecil_st_feed_in_price’)|float(0)] +
(state_attr(‘sensor.cecil_st_feed_in_forecast’, ‘forecasts’)|map(attribute=‘per_kwh’)|list))
| tojson
}},
“load_cost_forecast”: {{
([states(‘sensor.cecil_st_general_price’)|float(0)] +
state_attr(‘sensor.cecil_st_general_forecast’, ‘forecasts’) |map(attribute=‘per_kwh’)|list)
| tojson
}},
“pv_power_forecast”: {{
([states(‘sensor.sonnenbatterie_84324_production_w’)|int(0)] +
state_attr(‘sensor.solcast_pv_forecast_forecast_today’, ‘detailedForecast’)|selectattr(‘period_start’,‘gt’,utcnow()) | map(attribute=‘pv_estimate’)|map(‘multiply’,1000)|map(‘int’)|list +
state_attr(‘sensor.solcast_pv_forecast_forecast_tomorrow’, ‘detailedForecast’)|selectattr(‘period_start’,‘gt’,utcnow()) | map(attribute=‘pv_estimate’)|map(‘multiply’,1000)|map(‘int’)|list
)| tojson
}},
“prediction_horizon”: {{
min(48, (state_attr(‘sensor.cecil_st_feed_in_forecast’, ‘forecasts’)|map(attribute=‘per_kwh’)|list|length)+1)
}},
“alpha”: 0,
“beta”: 0,
“num_def_loads”: 2,
“def_total_hours”: [
{%- if is_state(‘sensor.openweathermap_forecast_condition’, [‘rainy’, ‘cloudy’]) -%}
0
{%- elif is_state(‘sensor.season’, ‘winter’) -%}
2
{%- elif is_state(‘sensor.season’, ‘summer’) -%}
4
{%- else -%}
3
{%- endif -%},
{%- if is_state(‘device_tracker.robsiphone’, [‘home’]) -%}
{%- if is_state(‘cover.ynot_charger_door’, [‘open’]) -%}
{{ ((90-(states(‘sensor.ynot_battery’)|int(0)))/30*3)|int(0) }}
{%- else -%}
0
{%- endif -%}
{%- else -%}
0
{%- endif -%}
],
“P_deferrable_nom”: [1300, 7360],
“treat_def_as_semi_cont”: [1, 0],
“set_def_constant”: [0, 0],
“soc_init”: {{ (states(‘sensor.sonnenbatterie_84324_state_charge_user’)|int(0))/100 }},
“soc_final”: 0.12
})

1483

Alpha and Beta both = 0 ? :face_with_raised_eyebrow:
That’s the problem I guess.

1484

Ah ok. Thanks.

1 Like
1485

So you have 1 deferrable load that controlls 2 items?

1486

No, right now I have setup two deferrable loads, deferrable0 for hot water and deferrable1 for heating.

But as you can see, these loads are planned to run at the same time. This is not possible in my setup, since the heat pump is only capable of doing either /or.

Screenshot_2023-11-19-21-36-03-007_io.homeassistant.companion.android
Screenshot_2023-11-19-21-36-03-007_io.homeassistant.companion.android1080×2400 192 KB

1487

Maybe just have one deferrable load and schedule it for the combined number of hours you want to operate your device.

Then in your activation automation you can monitor and allocate the operating hours for the different modes.

1488

Thanks for your hint. I was thiniking about this as well but honestly, why am I using emhass? To optimize the energy consumption and profit.
Combining hot water and heating into one deferrable load with e.g. 9 hours of runtime will not be ideal in regard to optimization.

I´m wondering no one else is having the same problem!? No one using emhass in conjunction with a heat pump for heating and hot water?

1489

EMHASS will help you select the optimal 9 hours of the day to run your device, you can use your automation to determine which mode is suitable at any one time.

I have a heat pump hot water system and a heat pump air conditioner but they are different devices so I can schedule them independently. Combined systems like yours make a lot of sense but I haven’t come across too many in the field.

Do you actually want your device to run for 9 hours, or are you trying to find some other optimisation? Can you describe an alternative optimisation?