EMHASS: An Energy Management for Home Assistant

This might sound like a very noob question, but please enlighten me. How do you retrieve more than 10 days of load data from homeassistant?
Is there any way for emhass to retrieve information from the long term statistics database?

Have you been able to create sensors that are stored in homeassistant lts that you can retrieve for training models?

You have to configure the Home Assistant recorder to retain more days; the default is 10 days. Increasing it will also increase the size of the database and your backups.
Check the recorder docs for Home Assistant for the details.

I suggested using LTS for the ML-models here:

LTS is not available to retrieve using the official HA API from which EMHASS is based on to fetch data.

Here are the docs for the core REST API: REST API | Home Assistant Developer Docs

And the supervisor API: Endpoints | Home Assistant Developer Docs

If this evolve, I would gladly support LTS. We need to ask this to HA devs.
For now the solution is to configure (as you said) the recorder to store more data that the default 10 days.
Personally I store 1 year of my data with a custom list of sensors to be stored, is quite a long list but my DB is always steady at 6-7 Gb

Thanks for the reply. I understand the concerns with using an undocumented websocket api.

I think a feature request for it already exists?

(Community Members can vote, currently 9 votes, so there’s still a long way to go…)

The websocket API does support this

No mention whatsoever in the documentation about LTS and I don’t think that the code part is retrieving LTS history values.
I might be wrong but at first sight of the code it doesn’t seems like…
But if needed we might need to integrate this websocket API to EMHASS which is not the case with the current code

WS endpoint is not well documented, but it is used by many components to retrieve LTS. For example the energy dashboard, apex charts, statistics card. Last time I spoke to the devs they said the REST api is dead and they only develop the WS api. But the documentation still sucks

My github issue shows working python code to fetch LTS via websocket API and the results from such a call.

That makes use of the

recorder/statistics_during_period

But it’s poorly documented and might be subject to change without notice?

Have I got this amber2mqtt configuation right. This is the default config?

amber:
  site_id: 01H1H4FJ5BN81M3ZF4J7PDHAWP
  access_token: psk_d25a7b1f96348889832dfd02f754e18c
  amber5minPrice_seconds: 14,16,18,19,21,23,25,27,30,32,35,40,45,50,55
  amber5minPrice_minutes: 0-1,5-6,10-11,15-16,20-21,25-26,30-31,35-36,40-41,45-46,50-51,55-56
  forecast5min: "False"
  forecast30min: "False"
  forecastUser: "True"
  forecast288: "False"
integration:
  home_assistant: "False"
  amber2mqtt: "True"
aemo:
  aemo5minPrice_seconds: 5,7,9,11,13,15,17,19,21,23,25,28,30,32,35,40,45,50,55
  aemo5minPrice_minutes: 0-1,5-6,10-11,15-16,20-21,25-26,30-31,35-36,40-41,45-46,50-51,55-56
mqtt:
  username: XXXXXX
  password: XXXXXX
  broker: 192.168.99.17
  port: 1883
  client_id: amber-2-mqtt
  debug: "False"

After upgrading to amber2mqtt v 2025.5.6 I don’t have the following sensors:

sensor.amber_30min_forecasts_feed_in_price
sensor.amber_30min_forecasts_general_price

You can enable the forecasts you want here:

Thanks for that Mark. So you are using amber_30min_forecasts_* now instead of amber_billing_interval_forecasts_*?

And forecast30min: ā€œFalseā€ should be True to retrieve that data?

amber:
  site_id: 01H1H4FJ5BN81M3ZF4J7PDHAWP
  access_token: psk_d25a7b1f96348889832dfd02f754e18c
  amber5minPrice_seconds: 14,16,18,19,21,23,25,27,30,32,35,40,45,50,55
  amber5minPrice_minutes: 0-1,5-6,10-11,15-16,20-21,25-26,30-31,35-36,40-41,45-46,50-51,55-56
  forecast5min: "False"
  forecast30min: "True"
  forecastUser: "True"
  forecast288: "False"
integration:
  home_assistant: "False"
  amber2mqtt: "True"
aemo:
  aemo5minPrice_seconds: 5,7,9,11,13,15,17,19,21,23,25,28,30,32,35,40,45,50,55
  aemo5minPrice_minutes: 0-1,5-6,10-11,15-16,20-21,25-26,30-31,35-36,40-41,45-46,50-51,55-56
mqtt:
  username: XXXXXX
  password: XXXXXX
  broker: 192.168.99.17
  port: 1883
  client_id: amber-2-mqtt
  debug: "False"

yes, billing interval forecasts changed with the switch over to 5MS.

Set to True and use 30min_forecasts.

1 Like

Does any of you uses a heat pump boiler with dynamic hourly tariff? How did you incorporate it? I am looking at Buderus WPT200.4 AS which has dry contact for ’ PV boost’ which I can use when dynamic tariff is low and hope for it to last long enough until prices drop again. Seems a bit odd, using a smart plug in the power outlet is not an option, it might damage the electronics. If anyone has a good idea to make this work? thanks

I have an SG ready dry contact relay on my hot water heat pump, which increases the set point from 55 deg to 65 deg.

I use this automation to control:

Ok, that’s what I was thinking also as it seems to be the only option, plus schedule as deferrable. The PV-dry contact indeed increases setpoint

I also have setup a thermal load with a 50 deg C setpoint overnight and 60 deg setpoint during the solar production window.

          "thermal_config": 
            { "heating_rate": 6.0, 
              "sense": "heat",
              "cooling_constant": 0.007, 
              "overshoot_temperature": 65.0, 
              "start_temperature": {{states('sensor.hws_power_based_sensor')|float(0)}}, 
              
              {%- set set = states('sensor.emhass_sun_next_setting_timesteps')|int -%}
              {%- set total_blocks = horizon -%}
              {%- set max_heating_blocks = 10 -%}

              {# Calculate if heating is possible today #}
              {%- set heating_today = max(0, min(max_heating_blocks, set - 10)) -%}
              {%- set first_start = set - 12 -%}

              {# For second day, always schedule 6 blocks #}
              {%- set heating_tomorrow = max_heating_blocks -%}
              {%- set second_start = first_start + 48 -%}

              {# Calculate fill blocks #}
              {%- set before_first = max(0, first_start) -%}
              {%- set between = max(0, second_start - (first_start + heating_today)) -%}
              {%- set remaining = max(0, total_blocks - (second_start + heating_tomorrow)) -%}

              {%- set temps = 
                    [50]*before_first + 
                    [60]*heating_today + 
                    [50]*between + 
                    [60]*heating_tomorrow + 
                    [50]*remaining +
                    [60]*heating_tomorrow + 
                    [50]*remaining                    
              -%}

              "desired_temperatures": {{ (temps)[:horizon] }}
          "thermal_config": 
            { "heating_rate": 6.0, 
              "sense": "heat",
              "cooling_constant": 0.007, 
              "overshoot_temperature": 65.0, 
              "start_temperature": 39.1,"desired_temperatures": [50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 60, 60, 60, 60, 60, 60, 60, 60, 60, 60, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 60, 60, 60, 60, 60, 60, 60, 60, 60, 60, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50, 50]
            }
          }, 
          {}, 
          {}],
        "outdoor_temperature_forecast": [17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 18, 18, 18, 18, 18, 18, 19, 19, 19, 19, 20, 20, 20, 20, 20, 20, 20, 20, 19, 19, 19, 19, 19, 19, 18, 18, 18, 18, 18, 18, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 18, 18, 18, 18, 20, 20, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 20, 20, 20, 20, 20, 20, 19, 19, 19, 19, 20, 20, 20, 20, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 19, 18, 18, 19, 19, 19, 19, 20, 20, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 21, 20, 20, 20, 20, 19, 19, 19, 19], 

So, you can read-out the water temperature plus you can control your hot water heat pump it seems? I mean you schedule your deferrable, but how to turn on your domestic hot water (DHW) heat pump? Most DHW heat pumps have separate logics with no API, so you can’t control them with HA. You need to schedule heating times on the pump itself. There is also a separate Temp sensor necessary I presume?

My heat pump has a digital thermometer on the outside that I haven’t been able to integrate with home assistant. However, it has a linear relationship between power consumption and tank temperature. 400 W = 40 °C, 500 W = 50 ° C and 600 W = 60 ° C.

I feed this temp into EMHASS thermal model and when EMHASS power forecast is > 100 W, I turn on the dry contact SG Ready relay.

1 Like

Ah, you can only control the boost function (Higher set-point 50 → 60) when there is surplus PV and/or low electricity prices.

The EMHASS thermal model calculates the temp loss over time (cooling_constant) and rate of heating (Heating_rate) if I am correct. The model will calculate the time period where it’s the best time to increase the setpoint if I am correct.

Normal operation you cannot control I would say, but with the thermal model you predict when it’s time to increase setpoint taking into account price.

At least that’s how I think it could be working

1 Like

One thing you don’t want is to cut the power to your heat pump while the compressor is running.

I did have some elaborate automations which would check for power consumption before switching off the power, in the end it was simpler just to switch the setpoint up and down using the dry contact (SG Ready) and leave power to the heat pump control logic.