EMHASS load forecast: the naive forecast shifts with a longer horizon

·

Werkelijk verbruik en een gestippelde prognose met dezelfde vorm maar uren verschoven, met een liniaal tussen de pieken

When I extended the EMHASS horizon from 96 to 117 quarter-hours, the plan looked fine at first glance: the solver returned Optimal. But the EMHASS load forecast for the house was no longer right. The evening peak was about five hours late.

What happens

With load_forecast_method: naive, EMHASS takes the latest measured values and uses them as the forecast. With a horizon of exactly 96 quarter-hours (24 hours), that comes down to “same time yesterday”. That is a reasonable estimate.

But from what I saw, EMHASS pastes the last N measured values onto the future, with N equal to the length of the horizon. With 117 steps, the forecast therefore starts 117 quarter-hours back instead of 96. The consumption pattern shifts by exactly 21 quarter-hours: over five hours.

The fix: my own load_power_forecast

EMHASS accepts its own forecast in the payload, as a load_power_forecast list. I build that myself:

  1. A buffer. A trigger template sensor stores the average base load every quarter-hour (30 seconds after the start of the quarter): the house without the car and without the heat pump. It keeps 49 hours of quarter-hour values in an attribute, keyed by the start of the quarter in local time.
  2. A value for each future quarter-hour. For each quarter-hour t, the payload looks up the value of t − 24 hours. If that is still in the future (with a horizon longer than 24 hours), it uses t − 48 hours.
  3. A safety net. If more than four quarter-hours are missing, the payload does not send its own list and the horizon falls back to 96.

I exclude the buffer itself from the recorder: it is large and changes every quarter-hour. Tested with an empty, a short, a full buffer and a buffer with gaps; the forecast lines up exactly at 96, 117 and 140 steps.

Known limitation

Around the switch to winter time, “24 hours earlier” is off by an hour for one day. I have not built anything for that yet.

What I do differently now

An Optimal from the solver only says the maths adds up, not that the input is right. With every change to the horizon, I now put the forecast and yesterday’s actual load side by side on the same time axis.

Why I wanted to extend the horizon in the first place: from 24 to 36 hours, and why 48 did not work. The whole setup: EMHASS and the battery.


These values apply to one installation. Check them against your own documentation; leave work on 230/400 V to a qualified electrician.


Read also


Comments

Leave a Reply

Your email address will not be published. Required fields are marked *