Home energy management for prosumers (PV, battery, heat pump, EV charging on dynamic tariffs)

A modern household with rooftop PV, a battery, a heat pump and an EV has several flexible loads but prices and solar yield change hourly. A home energy management system (HEMS) forecasts PV and consumption, then schedules battery, heat pump, wallbox and appliances against dynamic tariffs and grid-operator signals. The result is lower bills, higher self-consumption and compliance with grid-side control rules, with little daily effort for the occupants.

Problem & value

• Today: inverter, battery, wallbox and heat pump come from different vendors, each with its own app and simple rules ("charge battery from surplus"). Dynamic tariffs add price risk and opportunity that fixed rules miss.
• AI value: combine PV/load forecasts with a solver (MILP/MPC) or learned policy to shift consumption into cheap or solar-rich hours, pre-heat thermal mass, charge the EV by the departure time, and keep a reserve for outages.
• Regulatory driver (Germany): since 2025 suppliers must offer dynamic tariffs, and smart-meter rollout continues. §14a EnWG gives grid operators the right to throttle controllable consumers (heat pumps, wallboxes, storage) in exchange for reduced grid fees; a HEMS must honour these signals while still optimising the rest [1].
• Savings depend heavily on tariff spread, system size and consumption profile; vendor claims should be validated against your own meter data. No universal figure is quoted here.

Variants

• Private homeowner (PV + battery + EV): the core case, mostly Path A or open-source evcc.
• Heat-pump-centred home: pre-heating, DHW boost, SG-Ready / EEBUS control, link to PRED-048 for building quality.
• Tenant / balcony PV: small battery and smart plugs, simplified optimisation.
• Multi-family / energy community: shared PV and tenant electricity, allocation keys; relates to OPT-022.
• Small commercial site: shops, farms, offices with PV and chargers; overlaps OPT-007 and OPT-021.
• Flexibility aggregation: the household's battery/wallbox joins a virtual power plant (VPP), see OPT-039 and OPT-011.
• Self-host enthusiast (evcc, Home Assistant): local-first control without a vendor cloud (Path C).

How it works

1. meter + inverter + battery + heat pump + wallbox telemetry
2. data layer (local APIs: Modbus, SunSpec, MQTT, OCPP, EEBUS, vendor cloud)
3. forecasting (PV from weather/irradiance, household load, EV availability, price)
4. optimiser (MILP / model-predictive control, rolling horizon, or RL policy)
5. dispatch (set-points: charge/discharge, heat pump mode, charge power, appliance start)
6. safety layer (§14a limits, battery/wallbox constraints, user overrides)
7. feedback (actual vs forecast, savings report, model retraining)

• Forecasting: gradient-boosted trees or small neural time-series models on weather data; load profiles learned per household; NILM (PRED-031) can separate appliance loads.
• Optimisation: a rolling-horizon linear/mixed-integer programme is the robust industry default; RL or learned policies are used to imitate or speed up the solver, rarely as the sole controller.
• LLM role: conversational set-up ("have the car at 80% by 7:00"), explanation of decisions, tariff-contract parsing. The control loop itself stays deterministic and runs locally.
• Human-in-the-loop: occupants set comfort bounds, minimum SoC, departure times and can override anytime; grid-operator signals take precedence over optimisation.

Data preparation

This use case needs little preparation. The data are smart-meter or inverter readings, battery and heat-pump telemetry, wallbox sessions, tariff prices and weather forecasts. In a home or small business they live in the inverter portal, the vendor app, the grid operator's meter portal and sometimes in an Excel sheet of the energy bill. Typical gaps: no 15-minute meter data yet (only annual totals), several vendor clouds without a common interface, wrong or missing time stamps, no clean record of the tariff contract, and undocumented device limits such as maximum battery power or section 14a restrictions.

Preparation steps: 1. List devices and check which expose local interfaces (Modbus, SunSpec, MQTT, OCPP, EEBUS) or exports (PREP-005). 2. Request quarter-hourly meter data from the grid operator or install a local meter reader. 3. Write down tariff, feed-in rate and device limits in one config file. 4. Collect a few weeks of history to train the load forecast; fix gaps and units (PREP-011). 5. Set comfort bounds such as minimum battery level and departure times.

Effort share is roughly 10-20%; most time goes into device integration, not data cleaning. See also GUIDE-003.

Implementation paths

Which path for whom

• smb (installers, small businesses with PV and charging): A, because mature EU energy-management products with grid-operator (section 14a EnWG) compliance exist at fair prices and the task is standard.
• private (households): C, because evcc or Home Assistant with EMHASS run locally on a Raspberry Pi (HW1), keep consumption data at home and avoid vendor lock-in; choose A instead if you have one dominant vendor ecosystem and do not want to tinker.
• developer: B, because tariff, weather and forecast APIs plus a hosted solver make it fast to build a product or installer service across many homes.

Path A — Buy (recommended for SMBs; also for households with one vendor ecosystem)

• Integrated HEMS / aggregators: 1KOMMA5 Heartbeat (EU), Tibber (EU, tariff + smart charging), gridX (EU, white-label HEMS platform), SMA Sunny Home Manager (EU), Fronius, SolarEdge, Enphase, Victron (EU, open interfaces), Sonnen (EU battery with VPP), Viessmann/Vaillant heat pump ecosystems, Octopus Energy (dynamic tariffs, Kraken platform).
• Check: open APIs, local control, §14a compliance (CLS/EEBUS), dynamic-tariff integration, data location, exit options.
• Choose A when: one dominant vendor ecosystem and no wish to tinker.

Path B — Build on cloud APIs

• Data: tariff prices from Tibber, aWATTar, Octopus or ENTSO-E transparency platform; PV/irradiance forecasts from Forecast.Solar, Solcast or Open-Meteo; Deutscher Wetterdienst open data.
• Optimisation: OR-Tools, HiGHS or a hosted solver; orchestration in Home Assistant, n8n or a small service.
• LLM layer: an EU-hosted API (e.g. Mistral) or a frontier model for set-up dialogues and reports; keep control logic out of the LLM.
• Choose B when: you build a product or an installer service across many homes.

Path C — Self-host (open source)

• evcc: open-source EV charging and energy management, supports many wallboxes, inverters, meters, dynamic tariffs and battery strategies; strong German community [2].
• Home Assistant + EMHASS: convex optimisation of deferrable loads, battery and PV with forecasts [3]; also openHAB and Predbat (battery planning) for specific ecosystems.
• Hardware: HW1 — a Raspberry Pi 4/5 or mini-PC is sufficient. A small local LLM is optional.
• Effort: a weekend for evcc; days to weeks for a tuned EMHASS set-up.

Path D — Custom training

Worth it for manufacturers, utilities or aggregators operating thousands of homes: per-home load forecasting, learned heat-pump thermal models, federated learning to avoid centralising raw data, and RL policies validated in simulation first. Needs months of 15-minute meter data per home.

State of the art (2026)

• MPC with good forecasts remains the practical benchmark; forecast quality for PV and load, plus correct device models (battery efficiency, heat pump COP curves), matter more than the solver.
• 15-minute day-ahead products in the European market make intra-hour price signals more relevant for home optimisation.
• Standards: EEBUS, OCPP, SunSpec/Modbus, SG-Ready and IEC 61850-style models improve interoperability; the Matter standard is adding energy-management device types. Bidirectional EV charging (V2H/V2G) is entering the market.
• Foundation models for time series (e.g. Chronos, TimesFM, Moirai) give decent zero-shot load forecasts but are not consistently better than tuned local models.
• Limits and failure modes: forecast errors on cloudy days, vendor cloud outages, undocumented or changing APIs, battery degradation not modelled, comfort violations from over-aggressive heat pump shifting, conflicts between several controllers fighting for the same device.

Shared resources & combinations

• Same stack (time-series + optimization-solver): OPT-011 storage dispatch, OPT-021 charging optimisation, OPT-007 building HVAC, OPT-023 district heating; PRED-007 supplies the forecasting models.
• Upstream: PRED-031 appliance disaggregation, PRED-008 price forecasting.
• Downstream: OPT-039 and OPT-022 when homes are pooled into VPPs or congestion management.
• Edge runtime (edge-runtime) shared with other home/IoT use cases; one Pi-class device can host the whole stack.

Effort, cost & KPIs

• Path A: hours to days with installer; hardware (gateway, controller) is the main cost, some vendors charge subscriptions.
• Path B: 1-3 months for a product-grade service including device integrations.
• Path C: days to weeks of hobbyist effort; minimal running cost.
• KPIs: self-consumption and autarky rate, average cost per kWh versus a flat-tariff baseline, share of EV energy charged in cheap/solar hours, forecast error (MAE/MAPE), comfort violations, curtailment events by the grid operator, battery cycles.

People & change

In a household, decide together with everyone who uses the home (end-users) which comfort limits apply (hot water, car departure). In a small business, involve the owner (management) for the budget, IT or the installer for integration, the grid operator and device suppliers for interfaces, and legal or compliance for section 14a EnWG and feed-in rules.

Works council: no in households and normally no for this use case in a business, since the control loop steers devices, not employee behaviour. Only if a company links charging to named employees' cars and logs who charges when would section 87(1) no. 6 BetrVG apply; then involve an existing works council (section 90(1) no. 3 for early information).

Data protection: load profiles reveal living habits and count as personal data (GDPR). Prefer local control, a signed AVV with any cloud provider (Art. 28 GDPR), and involve the DPO where employees or tenants are affected; a DPIA is rarely needed for a single home. AI literacy: support users with a short introduction on what the optimiser does, how to override it and how to read the savings report (GUIDE-006). Start with one device group, such as the wallbox, before adding the heat pump (GUIDE-009). Typical concern: "the system will leave the car uncharged or the house cold." Address with minimum battery level, departure rules and a manual override at any time (GUIDE-008, GUIDE-005).

Risks, regulation & compliance

• EU AI Act: minimal risk for a typical household HEMS; energy management of a single home is not critical infrastructure safety. A platform operated by a grid operator for load control could touch Annex III critical infrastructure only if safety components are involved; assess case by case [4]. AI literacy (Art. 4) applies to providers and installers.
• GDPR: 15-minute consumption data and presence patterns are personal data; legal basis, minimisation, local processing where possible, DPA with cloud vendors, EU hosting. Smart-meter data access rules under MsbG apply in Germany.
• Energy law: §14a EnWG controllability, Messstellenbetriebsgesetz (smart-meter gateways, BSI security requirements), EU Electricity Market Directive consumer rights on dynamic tariffs and data access [1][5].
• Cyber security: connected inverters and wallboxes are attractive targets; use network segmentation, signed firmware, and the EU Cyber Resilience Act-compliant products where possible.
• Mitigations: local fallback mode, hard limits for battery SoC and grid import, transparent override, audit log of decisions.

Getting started

1. Collect baseline data: 15-minute meter data, tariff, PV size, battery, heat pump and EV charging patterns.
2. Check which devices expose local APIs (Modbus/EEBUS/OCPP) and whether a smart-meter gateway is installed.
3. Pilot evcc or a vendor HEMS for 4 weeks and compare cost versus the previous flat tariff.
4. Add a dynamic tariff and PV forecast, then tune the battery reserve and departure times.
5. Review §14a registration with your grid operator and make sure the HEMS respects its control signals.

Sources

Note: web search was unavailable in this run; source URLs are stable primary pages from prior knowledge. Accessed 2026-10. 1. Bundesnetzagentur — §14a EnWG, steuerbare Verbrauchseinrichtungen — https://www.bundesnetzagentur.de/DE/Vportal/Energie/SteuerbareVBE/start.html 2. evcc — open-source EV charging and energy management — https://evcc.io/ and https://github.com/evcc-io/evcc 3. EMHASS — Energy Management for Home Assistant — https://github.com/davidusb-geek/emhass 4. Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj 5. Directive (EU) 2019/944 on common rules for the internal market for electricity — https://eur-lex.europa.eu/eli/dir/2019/944/oj 6. ENTSO-E Transparency Platform — https://transparency.entsoe.eu/ 7. Open-Meteo weather API — https://open-meteo.com/ 8. Google OR-Tools — https://developers.google.com/optimization