EMHASS: An Energy Management for Home Assistant

Thanks for your help, Robert,
below my rest command. I build a sensor from Epex for the next 24 h, taking the 1 h and double the number of values so I have the same value for full hour and the half hour.
my production price is constant 0.08 €
My thought was that the load for the next 24 h is generated when I run the ML forecast model predict which gave me in the Web Gui also 48 values for the next 24 h, that I expected that I have everything in 30 minute steps.
I am really new to EMHASS so sorry for stupid questions.

  emhass_dayahead:
    url: "http://192.168.0.38:5000/action/dayahead-optim"
    method: POST
    headers:
      Content-Type: application/json
    payload: >
      {
        "weather_forecast_cache": true,
        "prediction_horizon": 24,
        "load_cost_forecast": {{ state_attr('sensor.epex_preise_30min_next24h', 'forecast') | to_json }}
      }

have a look at the comment above: EMHASS: An Energy Management for Home Assistant - #3509 by marst444
the parameter “prediction_horizon” is not used within the dayahead-optim call.

Got it! Thanks Cavemonkey!

1 Like

I have a question for the people who use a heatpumpboiler for DHW with the thermal model and rolling window with 5 min MPC runs. Do you see a nice planning with the heatpumpboiler getting warmed up during PV generation, but in the end EMHASS decides to start in the early mornings? I have a 15 kWh battery also. I just wonder why EMHASS deviates from it’s original planning when heading into the evening/night. You don’t expect big changes anymore in the forecasts at night for the next day. If you want to share your experience with this,that would be very helpful. Thank you all

I have experienced the same behaviour, with 5min MPC calls. Especially when there is enough pv production. I now switched to 15min MPC with 15 min optimisation steps and a rolling windows of 72 hours. Currently it looks better

Thank you, I will try that, 15 min MPC runs and I also have 72h rolling window forecast
Enclosed you can see the behaviour with 5 min MPC


The internal logics prevent the heatpump to start

This is the temperature profile, I would expect one long run not all those in between starts.

I use the dry-contact to increase the setpoint, if deferrable > 0 then the dry-contact is closed and setpoint goes to 65°C until deferrable = 0, then back to 50°C

It would be helpful to see the optimisation plan for these two cases.

It is important to realize that EMHASS has no memory or state, it doesn’t know what the optimisation plan was 5 minutes ago or 5 hours ago. It doesn’t try to stick to the previous plan.

Each time you run the optimisation it looks at the provided four forecasts; cost, price, solar and load and generates a fresh plan and in the case of thermal loads external forecasts like outdoor_temp.

If the plan has changed that is because some of the inputs have changed.

If you can show us those optimisation plans we maybe able to see the differences.

I have three thermal loads running HVAC (cooling), hot water and pool heating. I do see their schedules jump around after each 5 minute MPC run.


All looks nice, however heading towards evening/night I get these short starts 15 min runs plus the longer runs at approx 2:00 - 4:00 a.m.

What does your thermal config look like?

Here is my hot water system

My desired_temperatures I allow it to cool to 40 deg overnight, but charge to 60 deg at 6 hours before sunset (set - 12) for 3 hours. Getting the desired_temperature profile is complicated.

Here is my hot water, I too use a change of setpoint (SG Ready = 65 deg C) when deferrable4 > 0.

I’m interested in your desired_temps, do you have the same value repeated or different values at different times depending on your household needs?

This is my setup. 15 min optimisation, I started the same as you @markpurcell

Same day hours later I get this:

Totally shifted DHW with current 2 blocks planned. Maybe because pricing suddenly becomes very low, however that part is MLForecast model, will probably not be correct with real prices I get tomorrow at 1:30 pm

I have similar challenges with my ML forecast pricing.

The ML forecast has some very low costs in the future, so it defers startup until those lower prices.

It can also be useful to graph future temp_predicted4 (in my case) forecasts.

type: custom:apexcharts-card
apex_config:
  chart:
    height: auto
header:
  show: true
  title: EMHASS Daily Forecast
  show_states: true
  colorize_states: true
span:
  start: minute
  offset: "-2h"
all_series_config:
  stroke_width: 1
  extend_to: false
now:
  show: true
  label: Now
yaxis:
  - id: temperature
    min: 0
    max: 65
    decimals: 0
    apex_config:
      forceNiceScale: true
      tick_amount: 4
      title:
        text: Temperature (°C)
  - id: power
    opposite: true
    decimals: 1
    max: 15
    min: 0
    apex_config:
      forceNiceScale: true
      tick_amount: 4
      title:
        text: Power (kW)
series:
  - entity: sensor.p_pv_forecast
    yaxis_id: power
    type: line
    stroke_width: 2
    color: orange
    show:
      in_header: false
      legend_value: false
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_pv_forecast / 1000];
      });
  - entity: sensor.p_load_forecast
    yaxis_id: power
    type: line
    color: purple
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.forecasts.map((entry) => {
        return [new Date(entry.date), entry.p_load_forecast/1000];
      });
  - entity: sensor.p_batt_forecast
    yaxis_id: power
    curve: stepline
    color: lightgreen
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    type: area
    data_generator: |
      return entity.attributes.battery_scheduled_power.map((entry) => {
        return [new Date(entry.date), entry.p_batt_forecast/1000];
      });
  - entity: sensor.p_deferrable4
    yaxis_id: power
    curve: stepline
    name: Hot Water System
    color: red
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.deferrables_schedule.map((entry) => {
        return [new Date(entry.date), entry.p_deferrable4/1000];
      });
  - entity: sensor.temp_predicted4
    yaxis_id: temperature
    curve: stepline
    name: HWS (temp_predicted4)
    color: grey
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.predicted_temperatures.map((entry) => {
        return [new Date(entry.date), entry.temp_predicted4];
      });
  - entity: sensor.temperature_forecast_next_hour
    yaxis_id: temperature
    curve: stepline
    name: Forecast (temp)
    color: red
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    data_generator: |
      return entity.attributes.forecast.map((entry) => {
        return [new Date(entry.datetime), entry.temperature];
      });
  - entity: sensor.p_pv_forecast
    yaxis_id: power
    type: line
    stroke_width: 1
    color: orange
    extend_to: false
    name: PV actual
    transform: return x / 1000
    show:
      in_header: false
      legend_value: false
      in_chart: true
  - entity: sensor.p_batt_forecast
    yaxis_id: power
    curve: stepline
    color: lightgreen
    name: Battery actual
    transform: return x / 1000
    show:
      in_header: false
      legend_value: false
    stroke_width: 1
    type: area
  - entity: sensor.p_grid_forecast
    yaxis_id: power
    curve: stepline
    color: lightgray
    type: area
    name: Grid actual
    transform: return x / 1000
    show:
      in_header: false
      legend_value: false
view_layout:
  position: main

So, I am not the only seeing this with pricing, however you would expect that PV-power is free regardless of pricing during a PV period.
Last night I tried a 48h prediction window, intially It looked good:

But at night EMHASS decided to start the heatpompboiler:

Deferrable:

So many starts, however I fixed one run at least to be 15 min, internal logics don’t comply with EMHASS planning (See energy usage above)

New planning after the night:

Will incorporate your graphs as well @markpurcell