By default, the EMHASS prediction horizon is 24 hours ahead. That sounds like enough, but for me it produced the same strange plan every evening: exporting the battery at the end of the horizon. This is how I ended up at 36 hours.
The horizon effect
For the solver, energy still in the battery at the end of the horizon, above the target SoC, is worth nothing. If exporting it happens to earn something, it plans that export. With a horizon that ends at midnight, it doesn’t see tomorrow’s morning peak, let alone tomorrow’s evening peak.
How that plays out in practice: on 3 October EMHASS planned to sell 6 kWh at the end of its horizon for €0.27 per kWh. The following evening I would have had to buy that same power back for €0.42. I spotted it in time, but it showed that a horizon ending at midnight structurally makes the wrong choices.
An export planned 18 hours or more ahead usually isn’t carried out: later runs know more prices and hold on to the energy. But the plan is worse than it could be. A longer horizon lets EMHASS see tomorrow’s evening peak during the day, so that it can, for example, charge cheaply from the grid in the afternoon (around €0.19/kWh for me) for an evening at around €0.40/kWh.
Prices for hours that aren’t known yet
Tibber publishes tomorrow’s quarter-hour prices around 13:00. After that you know about 140 quarter-hours; before that, only the rest of today. For the quarter-hours after that, the payload repeats the last known day, quarter-hour by quarter-hour of the day. That’s an assumption, but a reasonable one: the pattern of off-peak and peak is similar from day to day.
The solar forecast comes from Open-Meteo, two days ahead. Hot water stays planned within the first 24 hours, so the block can’t slide to tomorrow.
Prerequisite: a load forecast that shifts along
EMHASS’s built-in naive forecast shifts with a longer horizon. That’s why I first built my own forecast: the naive load forecast shifts with a longer horizon. As long as that buffer isn’t full, the horizon stays at 96.
Why a 48-hour prediction horizon didn’t work
A configurable upper limit made 96 to 192 quarter-hours possible. The first tests with 192 steps (48 hours) went well, at various times of the day. A day later the solver hit its 180-second timeout at 192 steps.
The solve time grows sharply with the horizon, and also depends on how complicated the plan is that day. I now run at 144 steps (36 hours). That covers tomorrow evening, and the solve time stays well within the limit.
My advice
- Start with 96 steps.
- First make your load forecast independent of the horizon.
- Increase step by step and watch the solve time in the log. That’s the yardstick, not what is technically possible.
- Build a switch to fall back to 96, for when the solver gets stuck.
The complete setup: EMHASS and the battery. All incidents: Lessons from practice (in Dutch).
Not running EMHASS yet? Then start with Install EMHASS in Home Assistant.
These values apply to one installation. Check them against your own documentation; leave work on 230/400 V to a qualified electrician.
Leave a Reply