Part 6 of the series "Smart Home in Practice". Parts 2 to 5 brought the heat pump onto the local hub. Now comes the instance that turns it all into a system: a home-grown energy management. Part 7 shows the PV setup behind it, Part 8 takes stock.
Energy management in Home Assistant almost always starts the same way: one automation for surplus charging, one for the hot water boost, one for discharging the battery at night - and two years later you are maintaining a dozen automations that do not know each other but switch the same devices. In my case an outage was added to that: when the heat pump lost its cloud connection, the energy automations went idle, and while rebuilding I did not want that tangle a second time.
The result is HEMS, a home energy management system as its own Home Assistant integration - installable via HACS, open source on GitHub, MIT licence. This post tells the design decisions; the full documentation with every configuration parameter lives in the repository.
Why not an existing tool
For Home Assistant there is EMHASS, a full-grown energy optimiser that treats the distribution as a mathematical optimisation problem. That is the right tool when hourly changing electricity prices have to be weighed against forecasts. My case is simpler: a fixed electricity price, no feed-in tariff acrobatics, one clear goal - self-sufficiency first; the grid is the fallback, never the optimisation target.
With an objective like that, explainability beats mathematical elegance. HEMS therefore computes with a heuristic: a rolling plan in 15-minute slots across 24 to 48 hours, and in every slot one fixed, explainable order - hot water base demand first, then house consumption, then depending on the forecast comfort hot water, battery or car, and whatever remains is exported. When the system does something unexpected, I read the rule that did it - instead of asking a solver why its optimum looks the way it does.
Roles instead of entity IDs
The second decision: the planner knows no manufacturers and no entity IDs, only roles. Configuration happens entirely through the UI:
| Role | Example in my house |
|---|---|
| Meter (exactly one) | main meter, momentary power at the grid connection |
| Forecast source | three PV roof faces east, south, west |
| Storage | three batteries, one per phase |
| Thermal store | the hot water tank |
| Switchable load | the heat pump, with anti-cycling protection |
| Modulated load | the wallbox, via charging current |
Several batteries merge into one virtual total storage; setpoints are distributed proportionally to free capacity. A fourth battery is a new instance in the configuration dialog, not a code change. And because the roles are abstract, the same integration runs on entirely different hardware - which is exactly why it is published as its own repository rather than as a collection of my automations.
A forecast that learns from your own house
Every plan stands or falls with two questions: what will the sun still deliver, and what will the house consume? For the first, HEMS aggregates any number of forecast sources (for instance from Forecast.Solar). For the second, it learns consumption from its own history: 28 days of long-term statistics yield a 24-hour load profile per weekday type - workdays tick differently from weekends. As long as the history is not yet sufficient, a fallback chain reaches down to the configured base load. From this come the quantities the plan works with: expected surplus, night deficit, sun window.
Observing before acting
The most important property of HEMS is what it does not do by default: switch things. The mode has three levels - observe (default) computes recommendations and only displays them, auto additionally writes them to configured control entities, off is the kill switch with no write access at all. Whoever sets up the integration watches the planner for days and compares its recommendations against their own gut feeling before any device obeys it.
Even in auto mode the executing part stays deliberately conservative: it writes only to explicitly configured entities, only on an actual value change, never on an unknown recommendation, and a failure on one device does not drag down the others. Switchable loads get anti-cycling protection with minimum run and pause times - a heat pump forgives a lot, but not minute-by-minute on and off. And a sanity check reports configuration mistakes before they become wrong switching actions.
The details that daily operation teaches
Three examples of what was added between the concept and version 1.0 because real operation demanded it:
- A charge cap protects the batteries. Calendar ageing is largest at a high state of charge - so HEMS holds the batteries at 78 percent during the day and only ramps to 100 in the last hours before sunset, so they spend as little time full as possible. If the expected remaining yield no longer suffices, the cap drops immediately - better full into the night than pampered and empty.
- Jumps trigger recalculation. HEMS regularly computes once per minute. If the grid balance jumps by more than 800 watts - a cloud edge, the stove switching on - it recomputes immediately instead of waiting for the next tick; a cooldown prevents update storms.
- The objective is switchable. A select entity changes at runtime between self-consumption, true zero export and full charge - including the honest footnote in the docs about where the physical limits are.
All of it becomes visible in a dedicated sidebar panel with a power flow diagram and a plan card showing the coming hours: when the battery discharges, when hot water is loaded, how the state of charge is expected to develop.
Limits and outlook
HEMS is deliberately a phased project: observing and recommending are stable, actuation is optional, and the next stage is a simulation that replays your own past with virtual battery sizes - what would a fourth battery really have delivered, in kilowatt hours and euros instead of in a brochure. The heat pump from parts 2 to 5 participates in the system as a role.
If you want to rebuild this or just let it watch: the repository contains installation, all parameters with explanations, and the dashboard cards. Feedback and measurements from other setups are explicitly welcome - the role model exists precisely for that.
Part 7 shows the plant all of this hangs on: solar on three roof faces, three batteries - and what dynamic electricity prices would change about it.
Sources
- GitHub: hahems - the integration with full documentation and concept paper
- GitHub: EMHASS - the energy optimiser the heuristic decision was made against
- HACS: Home Assistant Community Store - installation path for custom integrations
- Forecast.Solar: PV forecast service - source of the per-face forecasts in the example setup
- Home Assistant: project website - the platform everything runs on