Logbook, 16 October 2026. The week EMHASS went from three minutes to one second, the solar forecast finally matched reality, and it turned out there had been 29 percent more panel on the roof all along than in any model. Plus the two mistakes I made myself, and what they taught me about how I work.
Where I started
Last week EMHASS, the optimisation that decides every fifteen minutes what the home battery does, regularly got stuck. A calculation took 55 to 90 seconds when it went well, and ran into the three-minute time limit when it didn’t. I had already cut the horizon from 36 to 24 hours to keep it running, and in doing so I gave up exactly what makes the planning valuable: seeing in the afternoon that tomorrow’s evening peak is coming.
The cause was in the configuration, not the model
The breakthrough didn’t come from trying things on the installation itself, but from installing EMHASS locally and running my own configuration offline, switching one setting on or off at a time. That produced a table that left no room for discussion:
| Configuration | Solve time |
|---|---|
| As it was (hybrid inverter on, “battery first” on) | 106 s |
| Only “battery first” on | 46 s |
| Only hybrid inverter on | 0.9 s |
| Both off | 0.7 s |
| Both off, with the heating model | 0.5 s |
The culprit was set_battery_first_priority. The documentation says in so many words that it is meant for a fixed tariff: it forbids drawing from the grid as long as the battery has anything left. With quarter-hour prices that is exactly the wrong way round, because cheap grid charging while the battery is half full is the whole arbitrage. And the heavy penalty the setting adds made the problem badly conditioned. One checkbox, a factor of sixty in solve time.
I switched off the hybrid inverter model too, for a different reason: my panels are connected on the AC side with micro-inverters, so there is no DC bus where PV and battery meet. The model was physically wrong, and it added a binary decision variable for every quarter hour.
Documentation first, then build
This was also the week I had the complete EMHASS documentation read, all 42 pages including the cookbook and the study cases, before anything else was changed. I should have done that sooner. It contained things that made my own construction unnecessary: you can supply prices and the solar forecast as a timestamped dictionary, and EMHASS then aligns them and fills the gaps itself. Out went the quarter-hour logic I had written myself, which had already contained a bug twice. And the recommended way to handle the end of the planning horizon was in there as well; I’ll come back to that in a moment.
The result is a strategy document: for every EMHASS feature, whether it applies to my setup, what it delivers, what it requires, and in which order I’ll introduce them. Heating as a thermal model, hot water with shower times, the car via evcc, the Sunday balancing via a SoC target. None of it went live this week; it is ready, with a safety net, waiting for colder weather for the calibration.
What is stored energy worth at the end of the horizon?
A planner that looks 48 hours ahead needs to know what a full battery is worth at hour 48, otherwise it sells everything at the last moment. I had a fixed end state of 25 percent for that, with the result of a planned “dump” at the end that was rarely carried out but did colour the choices in between. The documentation recommends setting the end state equal to the starting state: energy is its own value. That worked, until the battery stood at 95 percent after the Sunday balancing. Then “end where you started” meant that every discharged kilowatt-hour had to be bought back within two expensive days, and EMHASS kept the battery at 89 percent overnight while the house drew from the grid at €0.38.
The solution now running is automatic: the end state is the starting state, but never higher than the average actual SoC over the past seven days. Anything above that is surplus and can be used freely; below it, the neutral rule applies. No knob, no number I pick; it follows the season by itself. Same evening, same prices, three variants:
| End state | Cost |
|---|---|
| Fixed end state 95 % | €6.44 |
| The wrong starting value | €5.01 |
| Weekly average of the SoC | €2.42 |
The sun: 6.84 kWp, not 5.31
Last week I wrote about a monthly table to correct the structurally low solar forecast, with factors up to 1.28. This week the Enphase app showed what is actually on the roof: 18 panels of 380 Wp with IQ7+ micro-inverters, not 295 Wp with IQ7. That is 6.84 kWp instead of 5.31, a factor of 1.29. Exactly the median the measurement loop had been showing for eight days. The table wasn’t correcting the weather, but a wrong kWp figure.
With the right roof details I put Solcast alongside, and made the comparison fair: record both forecasts at 06:00, before sunrise, and set them against the actual generation at 23:55. After three days, one sunny and two grey, Solcast was almost spot on and Open-Meteo was 40 percent below. Since Thursday EMHASS reads the sun from Solcast, directly from the Home Assistant integration, without extra API calls. The monthly table is gone.
On Sunday the roof delivered 32 kWh. At first I was convinced the Solcast forecast was too high.
Price-aware heating, as an intermediate step
EMHASS only plans the heat pump once the house has been calibrated: seven nights of cooling and five real heating days. At 16 degrees outside that takes a while. Until then a simpler rule does the work. Every fifteen minutes Home Assistant decides whether it is expensive now (more than 15 percent above the average of the next 24 hours) or will be within two hours. Expensive hours: the target drops three quarters of a degree and the floor does the rest. Just before, while it is still cheap: half a degree extra. On Thursday morning the heating ran from 05:00 to 06:45 at €0.31 and stayed off during the €0.46 peak at 08:00. Two starts a day, never in the peak.
Two mistakes of my own
The balancing got stuck. On Sunday, after three Home Assistant restarts, the inverter’s SoC target was still at 100 percent, and the battery didn’t discharge in the evening while the price was €0.42. The automation that ends the balancing was waiting for “battery full” in one long run, and a restart breaks off such a run; the 8-hour timeout started counting again after every restart. Now a watchdog checks every five minutes, and right after every start, whether the balancing should still be running.
The heat loss measurement on sunny days. The measurement divides the heat the heat pump delivers by the indoor-outdoor temperature difference. On a sunny October day the sun largely heats the house by itself, and then it looks like a house of 23 W/K, a figure no terraced house achieves. That value would pollute the thermal constant for EMHASS. Now a day only counts if the heat pump delivered at least 12 kWh and the sun gave less than 12 kWh.
New tools
- Offline test harness. Every change to the EMHASS payload is first run locally against the same version as the add-on, with status and solve time, before it goes onto the installation. That is how the heating model was tested in six variants without anything running at home.
- System check. One script that walks the whole chain (plan fresh, SoC target, does the battery deliver what the plan says, grid around zero, Modbus, forecasts, calibration) and puts the report on my phone. Eighteen lines, green or red, each with a hint.
- Plausibility check. After a restart the battery sensor briefly reported 49 percent instead of 95; the plan immediately wanted to grid-charge at 11 kW. A SoC that differs by more than 20 points from the previous run is now skipped, with a notification.
- Republishing the plan after a restart. The sensors EMHASS publishes are gone after a Home Assistant restart until the next run; the inverter then sat in its safe mode for fifteen minutes. Now the last plan is republished right after startup.
Where things stand
EMHASS solves in one second with a 48-hour horizon. The battery follows the plan: night and morning peak from the battery, full from the sun during the day, evening from the battery; on this week’s expensive days not a single export, and that was the right choice. The solar forecast matches reality. The heat pump runs twice a day in cheap hours. And the thermal model for the heating is ready behind one switch, with a pause safety net if a run fails. It is waiting for the first cold week.
The lesson
The most important lesson of the week isn’t a setting. It is: read everything first, then test offline, and only then go live. The two days that cost me gave me more than the three days of trial and error before them.
Want to set up EMHASS yourself? Start with Install EMHASS in Home Assistant. All logbooks in one place: Logbook (in Dutch). All incidents and lessons: Lessons from practice (in Dutch).
This works in my situation: micro-inverters on the AC side, a Deye inverter with a home battery and quarter-hour prices. Solve times and costs apply to one installation and one week. Check it against your own documentation. As of October 2026.
Leave a Reply