Quick Summary (TL;DR)
Start with native Home Assistant automations, not an optimiser. If your electricity tariff has a predictable cheap period, your EV charger has its own schedule, and your heat pump operates efficiently with a stable weather-compensated curve, a few well-tested rules will often deliver most of the achievable benefit. EMHASS becomes worth evaluating when several flexible loads compete for limited solar generation, battery capacity, grid import power or time-varying electricity prices, and you have sufficiently accurate forecasts and device interfaces to execute its plan.
EMHASS stands for Energy Management for Home Assistant. It is an open-source optimisation tool that can use forecasts and constraints to calculate planned actions. It is not a substitute for Home Assistant itself, the inverter battery-management system, the EV charger’s electrical protection, or a manufacturer’s heat-pump controller. The distinction is between deciding which action should happen next and optimising a sequence of actions over future hours.
This guide explains the mathematical trade-off without pretending that every house needs linear programming. It compares installation effort, data quality, operational reliability, savings opportunities and realistic validation methods for a UK or European household.
What is EMHASS, and what problem does it solve?
A normal automation reacts to a condition: “when export exceeds 1.5 kW for five minutes, enable a compatible load”, or “charge the car during the off-peak window”. EMHASS instead considers a time horizon. It can weigh forecasts for solar PV production, household consumption and electricity prices against the energy a flexible load needs and the times at which it must be ready. Its output is a schedule or set of planned values; your integrations and automations must still translate that plan into commands your actual devices support.
In a typical deployment, EMHASS runs as a Home Assistant add-on or another supported service, receives sensor values and forecast inputs, solves an optimisation problem, and publishes calculated entities or actions for Home Assistant to consume. Exact features, optimisation endpoints and parameter names depend on the installed EMHASS release. Follow the official EMHASS documentation rather than copying a configuration from an older forum post.
The optimisation is only as good as the physical model. A schedule based on an unrealistic 8 kW PV forecast, a missing household baseload, or a battery whose reserve cannot actually be changed can look mathematically excellent while performing poorly in the real house.
EMHASS vs native Home Assistant automations: comparison
| Decision factor | Native automations | EMHASS forecast optimisation |
|---|---|---|
| Core method | If/then logic, thresholds, time windows and helpers | Constrained optimisation across a future horizon |
| Initial setup | Low to moderate; depends on device integrations | Moderate to high; forecasts, parameters, solver and execution layer |
| Price awareness | Good for fixed and simple dynamic tariff rules | Can consider many price intervals together |
| Solar surplus | Thresholds and hysteresis | Forecast-based allocation between flexible loads |
| Battery scheduling | Possible, but vendor interfaces vary | Possible only if battery constraints and writable controls are supported |
| EV departure target | Straightforward with one charger and time window | Useful for balancing energy target against competing loads |
| Transparency | Easy to inspect individual triggers | Requires inspecting inputs, constraints and planned outputs |
| Offline resilience | Good with local sensors and fallbacks | Solver/forecast outage requires a fallback |
| Maintenance | Low for simple rules | Higher when prices, forecasts or integrations change |
| Best fit | One or two flexible loads and stable tariff | Several controllable assets and meaningful price variation |
Begin with a baseline: the three-rule energy manager
Before installing an optimiser, implement the simplest schedule that could plausibly work. A baseline is essential: without one, you cannot demonstrate that the extra complexity saves money rather than merely moving loads around.
- Rule 1 — protect essentials: heating comfort, hot water hygiene, EV departure readiness and battery reserve take priority over speculative savings.
- Rule 2 — use obvious cheap periods: schedule controllable loads during known off-peak tariff windows, with a device-native backup schedule where available.
- Rule 3 — respond to measured surplus: allow discretionary loads when export persists above a threshold, but add hysteresis and minimum on/off times.
A threshold must be based on net grid export from a correctly installed meter, not simply inverter PV output. For example, a 3.5 kW PV reading alongside 2.8 kW household consumption leaves only 0.7 kW available before battery behaviour and meter lag are considered. A 2 kW immersion heater would still import energy if switched on at that moment. See our Home Assistant Energy Dashboard entity guide for the metering foundations.
When forecasts genuinely add value
Optimisation is useful when there is an opportunity cost: charging the EV now may prevent charging the home battery, but waiting may miss a cheap electricity period or the driver’s departure. A simple “cheapest hour” rule cannot always resolve several competing deadlines and power limits.
| Household situation | Likely value of optimisation | Reason |
|---|---|---|
| Fixed overnight tariff; one EV | Usually low | Charger schedule can already exploit cheap window |
| Solar PV without battery; immersion diverter | Low to moderate | A local surplus diverter reacts well to real measurements |
| Dynamic half-hourly prices; EV and battery | Moderate to high | Price sequence and energy targets interact |
| PV, battery, EV, heat pump, flexible water heating | Potentially high | Multiple devices compete for energy and import headroom |
| Cloud-only devices with slow command response | Often limited | A theoretically optimal schedule may not execute |
| Weak PV forecast and irregular household loads | Uncertain | Forecast error can dominate the expected benefit |
The data EMHASS needs: forecasts, prices and actual consumption
Solar generation forecast
A PV forecast should reflect array size, orientation, tilt, shading and inverter clipping. Weather-driven errors can be significant on variable-cloud days. For a small rooftop array, predicting the exact minute of sunshine is less useful than estimating the energy available over the next few hours. Keep actual production measurements and compare them with forecast values; use a conservative margin before committing to an expensive load.
Household consumption forecast
A forecast of non-flexible household consumption prevents the optimiser from treating all PV output as available. Use historical load data separated from the controllable EV, immersion or battery charging loads wherever practical; otherwise the model can double-count consumption it intends to schedule. Occupancy, cooking, washing and unusually cold weather can change baseload considerably.
Import and export tariffs
Price inputs must use the same currency and energy unit, normally pence or euros per kWh, across all intervals. Confirm whether values include VAT and other relevant variable charges. Export payments may be different from import prices, and some contracts impose conditions on simultaneous import and export. Standing charges are generally not affected by shifting a load and should not be counted as avoidable savings.
State of charge and controllable assets
An EV needs a current battery estimate or at least a required energy target, a departure deadline and a realistic charging efficiency. A home battery needs capacity, maximum charge/discharge power, usable state-of-charge range, reserve and inverter restrictions. A hot-water cylinder requires temperature limits and a separately maintained hygiene strategy. If those values are unavailable or the device does not expose supported write controls, optimisation must not assume they exist.
Why device control matters more than the solver
An optimisation tool can request 1.2 kW from a load, but a conventional immersion element might only support on/off operation at 3 kW. An EV charger may have a minimum allowable current, per-phase limits and delayed responses; a heat pump may not accept arbitrary minute-by-minute power commands. Model the actual discrete or continuous controls, not an imaginary perfectly variable load.
| Asset | Typical practical control | Common constraint |
|---|---|---|
| EV charger | Start/stop or adjustable current on compatible model | Minimum current, phases, departure time, charger protections |
| Home battery | Vendor-supported charge windows or power limits | Reserve, grid permissions, BMS and inverter controls |
| Immersion heater | Certified diverter or installer-approved contactor | Element power, thermostat, high-limit cut-out, hygiene |
| Heat pump | Approved setpoint/schedule or demand interface | Compressor cycling, comfort, weather compensation |
| Dishwasher/washing machine | Device-supported delayed start | Not all models allow remote start; safety and manual loading |
| Solar inverter | Usually monitoring; limited approved settings | Grid-code compliance and installer controls |
Avoid direct control of mains equipment with a bare ESP32AliExpress price relay board. Mains switching, contactor selection, enclosure design, protective devices and local electrical compliance are installer work. Never bypass thermostats, over-temperature cut-outs, BMS protections or export limits. A Home Assistant outage must not leave a heating system without its independent safety controls.
Worked example: a dynamic-tariff household
Consider a home with 5 kWp of solar PV, a 10 kWh nominal home battery, a 7 kW-class single-phase EV charger, and a 3 kW immersion heater. Assume the EV needs 14 kWh delivered before 07:30. The tariff offers two cheap overnight hours at 12 p/kWh and other hours at 28 p/kWh. This is an illustrative scenario, not a prediction of current tariff prices or an installation specification.
If the charger can deliver 7 kW continuously, two hours theoretically supply 14 kWh at the wall. However, the EV may receive less after conversion losses and charging taper; at an illustrative 90% wall-to-battery efficiency, 14 kWh at the battery requires about 15.6 kWh from the grid. The nominal two-hour window is therefore too short for a guaranteed 14 kWh battery gain, even before charger delays or a household import limit are considered.
A simple rule can start charging earlier to protect the departure target. EMHASS can consider that target alongside expected overnight household consumption, battery charging and a forecast of morning solar. But it cannot create extra electrical capacity. A correctly commissioned charger load-management system must still enforce the site limit independently of the optimisation schedule.
| Input | Illustrative value | Implication |
|---|---|---|
| EV energy needed at battery | 14 kWh | Must be ready by 07:30 |
| Wall-to-battery efficiency assumption | 90% | Approximately 15.6 kWh wall energy |
| Cheap tariff window | 2 hours | At 7 kW nominal, maximum 14 kWh wall energy |
| Cheap price | 12 p/kWh | About £1.68 for 14 kWh at wall |
| Other price | 28 p/kWh | An extra 1.6 kWh costs about £0.45 |
| Optimisation opportunity | Move feasible energy to lower-priced intervals | Subject to deadlines and charger limits |
The potential saving in this simple example is small because the obvious cheap window already captures most of the value. An optimiser is more compelling when prices change across many intervals, export compensation matters, or several loads have different deadlines.
Calculating the value of better scheduling
Measure costs over identical operating conditions rather than comparing a sunny week with a cold cloudy week. At minimum record grid import energy, import price by interval, export energy and compensation, delivered EV energy, heating comfort and whether scheduled tasks completed. If a home battery is involved, consider degradation and conversion losses rather than treating stored energy as free.
For each tariff interval, a useful accounting expression is net variable energy cost = grid import (kWh) × import price − grid export (kWh) × export price. Add any variable demand or capacity charges that apply to the actual contract. Sum over the evaluation period. Savings are the difference against a realistic baseline under comparable conditions, not the difference between the optimised bill and an arbitrary flat-rate price.
Suppose forecast optimisation reduces net variable energy cost by £0.18 per day over 250 relevant days. That is £45 per year before the time spent maintaining forecasts and integrations. Even if the software itself is free, this may not justify an elaborate configuration. Conversely, a home with frequent high/negative price intervals and large flexible loads could have more to gain; verify using measured data.
EMHASS architecture with Home Assistant
Keep three layers separate: measurement, planning and actuation. Measurement provides metered grid import/export, PV output, battery state and device status. Planning uses native rules or EMHASS to decide preferred schedules. Actuation uses manufacturer-supported Home Assistant integrations or approved gateways, with device-native limits and fail-safes retained.
| Layer | Suggested responsibility | Failure response |
|---|---|---|
| Measurement | Trusted meter and validated sensors | Mark stale values unavailable; do not invent zero |
| Forecast | PV, baseload and tariff forecasts | Use conservative baseline schedule |
| Planning | EMHASS or native automation | Last valid plan expires; fallback takes over |
| Execution | Supported device API or local integration | Respect device constraints and manual overrides |
| Protection | Charger, inverter, heat-pump and electrical safeguards | Remain independent of Home Assistant |
For a wider architectural comparison, read Home Assistant, evcc and inverter-app controls. The article helps decide which system should own the scheduling logic. A practical approach is to let the charger or inverter enforce its own safety-critical constraints while Home Assistant provides a supervisory target.
How to evaluate EMHASS without risking household reliability
- Week 1: collect actual grid, solar, battery and flexible-load data; check timestamps, sign conventions and energy units.
- Week 2: build native automations and log their decisions; confirm comfort, hot water and departure deadlines.
- Week 3: install and configure EMHASS in monitoring or dry-run mode. Compare proposed schedules against the native baseline without issuing commands.
- Week 4: test one low-risk, reversible controllable load, with manual override and a defined fallback if data or the solver fails.
- Afterwards: expand only if the incremental savings and reliable execution justify the complexity.
A dry-run should record the planned action, the reason for it, actual tariff, measured energy and whether the device could have followed the plan. Do not claim success because the solver returns an “optimal” objective value; compare planned and achieved costs.
Forecast error: the hidden cost of optimisation
An optimiser may schedule battery discharge at 17:00 expecting solar production at 18:00, then encounter unexpected cloud. That can force expensive grid import later. Similarly, a heat pump scheduled to preheat during a cheap hour may consume more electricity if the requested temperature requires a higher flow temperature and reduces COP. Forecast optimisation is not automatically superior to a stable weather-compensated heating curve.
Use rolling re-optimisation where supported and appropriate, but avoid changing plans so often that chargers, compressors or relays cycle unnecessarily. Apply minimum runtime, minimum off-time and hysteresis constraints at the device control layer. Maintain a comfort and reserve margin, especially when forecasts are unreliable.
Native Home Assistant example: a simple tariff gate
The following is intentionally illustrative logic, not a copy-and-paste automation for an unknown charger. Use an integration-supported charge enable control and verify its real entity name, state model and fallback behaviour. A template sensor can flag an inexpensive interval when a trusted tariff sensor is available:
template:
- binary_sensor:
- name: "Electricity Cheap Now"
unique_id: electricity_cheap_now
availability: >-
{{ is_number(states('sensor.electricity_import_price')) }}
state: >-
{{ states('sensor.electricity_import_price') | float(999) < 0.15 }}This example assumes the tariff sensor is measured in currency per kWh and the illustrative threshold is 0.15 of that currency. A price sensor in pence/kWh requires a different threshold. Availability prevents an unavailable sensor from being silently treated as a free tariff. Use a separate automation that checks the EV’s departure requirement and respects the charger’s native protections before acting. Home Assistant template syntax and integration behaviour should be checked against the installed release.
What about EMHASS and batteries?
Battery optimisation can add value when import prices, export prices, forecast solar and battery reserve interact. However, model usable capacity rather than nameplate capacity, round-trip losses, maximum power, minimum reserve, permitted grid charging and any warranty restrictions. Some inverters expose only read-only telemetry; others provide time-of-use schedules but not fine-grained power setpoints. A solver output is not permission to write unsupported registers.
If your inverter already has reliable dynamic-tariff or solar self-consumption logic, compare that native mode against EMHASS before adding another controller. Two independent systems that both try to manage the same battery can create contradictory schedules.
When not to install EMHASS
- Your household has one flexible load and a simple, fixed cheap tariff window.
- Your inverter or charger already schedules the relevant asset effectively and exposes no safe supported external control.
- Your metering is incomplete or uses the wrong sign for import/export.
- You cannot obtain reliable tariff and generation forecasts for the optimisation horizon.
- Your heating or hot-water safety depends on Home Assistant remaining online.
- You do not have time to validate, monitor and maintain the configuration.
Buying considerations: spend on reliable measurements first
The most valuable upgrade may be a properly installed, supported energy meterAliExpress price rather than a more powerful server. An inexpensive Home Assistant host can run straightforward automations, while an optimisation service needs dependable historical data and forecast feeds more than raw CPU power in most domestic deployments. Choose metering that exposes accurate cumulative energy readings and current power with known units and direction.
| Purchase or setup item | Priority | What to check |
|---|---|---|
| Whole-home import/export meter | Essential | Correct phases, polarity, local data and installation |
| Home Assistant host and storage | Essential for HA-based control | Reliability, backups, supported installation |
| PV generation data | High for solar optimisation | Accurate real production, forecast calibration |
| Tariff data feed | High for dynamic tariffs | Time zone, intervals, VAT, outages |
| EV charger control | High if scheduling EV | Supported API, minimum current, fallback schedule |
| Battery control gateway | Only if supported and useful | Write permissions, reserve, warranty and inverter protections |
| Additional temperature sensors | Optional | Comfort validation and appropriate placement |
Related reading: correct grid, solar and battery entities and verify Home Assistant energy data against your utility bill. These checks should precede any optimiser.
Troubleshooting: why an optimisation plan fails in practice
| Symptom | Likely cause | What to investigate |
|---|---|---|
| Plan charges EV after departure | Deadline or time-zone mismatch | Local time, UTC offsets, interval boundaries |
| Battery empties before expensive period | Forecast or reserve constraint wrong | SOC limits, efficiency, actual baseload |
| PV appears available while importing | Wrong meter sign or stale data | Grid meter orientation and entity freshness |
| Optimiser changes schedule constantly | Over-frequent re-planning | Minimum runtime, hysteresis, lockout windows |
| Device ignores planned power | Unsupported or discrete control | Actual API, phase/current constraints |
| No improvement in bill | Baseline already captures cheap periods | Measured cost comparison and export value |
| Automation starts load at unknown price | Unavailable sensor treated as zero | Availability templates and safe fallback |
Frequently asked questions
Is EMHASS better than Home Assistant automations?
Not inherently. EMHASS is better suited to multi-period, multi-constraint scheduling. Native automations are often more reliable and easier to maintain for simple tariff and solar rules.
Does EMHASS replace Home Assistant?
No. It provides optimisation calculations and normally relies on Home Assistant or other supported systems for data and execution.
Does EMHASS need a home battery?
No. It can be useful for scheduling flexible loads such as EV charging, but a battery can create additional optimisation opportunities.
Will EMHASS work without the internet?
Local operation depends on deployment, but external weather, solar or tariff forecasts may require internet connectivity. Provide a fallback for missing feeds.
Can EMHASS control any EV charger?
No. Control depends on the charger integration and supported commands. Minimum current and manufacturer safety limits still apply.
Can it improve heat-pump COP?
Not automatically. Aggressive preheating can require higher flow temperatures and reduce COP. Measure comfort and electrical consumption before claiming savings.
Is the software free?
EMHASS is an open-source project, but deployment, data feeds, hardware and maintenance may have costs. Verify current licensing and service terms.
How often should it optimise?
That depends on tariff intervals, forecast update frequency and device constraints. More frequent optimisation is not always better.
How do I prove savings?
Compare measured interval-by-interval net energy cost with a realistic rules baseline under comparable conditions, including export revenue and device losses.
Can I optimise solar export and battery charging together?
Potentially, if forecasts, tariffs, device limits and safe supported battery controls are modelled correctly.
Should I let two systems schedule my EV?
Prefer one clearly designated scheduling owner. Conflicting car, charger and Home Assistant timers can cause missed charging windows.
What happens if EMHASS crashes?
A robust design expires its planned commands and returns to safe device-native schedules or simple Home Assistant rules without bypassing protections.
Start by measuring the opportunity, not installing another service
Energy optimisation is attractive because it promises one coherent schedule for solar, batteries, EV charging, heating and appliances. But the most useful first question is narrower: how many kilowatt-hours are currently purchased at an avoidably expensive rate, exported when they could have been used, or consumed by an inflexible schedule? If the household already charges its car overnight at the cheapest rate and exports little valuable solar during useful hours, the theoretical benefit of a sophisticated solver is modest. Software cannot recover savings that do not exist in the tariff or device capabilities.
Gather at least two weeks of interval data, preferably across varied weather and occupancy, before comparing controllers. Record site import/export, PV production, battery state of charge, actual device energy, prices, deadlines, and comfort results. Capture the original controller state, firmware revision, update frequency and whether internet access was available. A 15-minute price series coupled to 60-second measurements is more useful than a beautiful dashboard of instantaneous watts if it cannot reconstruct energy by billing interval.
Where possible, distinguish three monetary quantities: electricity paid for, export revenue forfeited by using solar at home, and incremental equipment and battery wear. A kilowatt-hour of free-looking solar is not necessarily free if the energy could have earned export payment. Likewise, a battery schedule that shifts a unit from one price period to another incurs losses and may affect degradation. A defensible comparison values all of these within its stated system boundary.
| Baseline indicator | How to calculate or observe it | Reason it matters | Common mistake |
|---|---|---|---|
| Avoidable high-tariff kWh | Load energy during expensive intervals that can actually be shifted | Upper bound on scheduling value | Treating all peak use as flexible |
| Forecast PV surplus | Expected generation minus non-flexible demand, adjusted for storage behaviour | Potential self-consumption window | Using total PV output as available surplus |
| EV deadline margin | Required wall energy divided by realistic charge power, then compare available hours | Whether rules can safely postpone charging | Confusing battery gain and wall energy |
| Battery arbitrage spread | Avoided import cost less charging source value and round-trip loss | Potential value of shifting through storage | Ignoring export opportunity cost |
| Control availability | Hours per week that all required commands and measurements are usable | How much optimisation can execute | Assuming sensor visibility implies device control |
| Baseline completion | Proportion of cycles where car, hot water and comfort goals were satisfied | Safety and usability constraint | Counting cheap runs that missed the deadline |
Three control strategies: fixed rules, predictive rules and optimisation
It helps to separate simple deterministic automation, forecast-assisted heuristics and mathematical optimisation. Native Home Assistant is not limited to primitive on/off thresholds. It can take account of a solar forecast, energy price array, minimum-off period, battery reserve and departure target with templates, scripts and helpers. The distinction is that a rule set generally resolves competing conditions through priorities chosen by its author, while EMHASS represents a set of objectives and constraints over a planning horizon. Neither approach guarantees optimal behaviour if inputs are wrong.
| Method | Typical decision | Strength | Weakness | Suitable starting point |
|---|---|---|---|---|
| Fixed automation | Start EV at 00:30 on a known cheap-rate tariff | Easy to test; limited dependencies | Ignores unexpected tariff changes | One EV and a two-rate tariff |
| Threshold with hysteresis | Enable compatible immersion when measured export exceeds threshold for several minutes | Responds to real measured surplus | May miss later better windows | Simple solar diverter alternative |
| Forecast-assisted native rule | Defer washing if expected low-price window occurs before deadline | Moderate complexity | Interacting deadlines can become unwieldy | One or two flexible loads |
| Day-ahead EMHASS | Compute next-day schedule from forecast and constraints | Explicit cross-device trade-offs | Plan can become stale | Multiple flexible loads and known next-day prices |
| Rolling-horizon EMHASS MPC | Replan using updated readings and forecasts | Can correct earlier prediction errors | Needs reliable state, frequent data and careful execution | Complex site with variable forecasts |
The first three strategies can be entirely legitimate end states. A rules-based system that consistently completes required tasks and costs £0.30 more per day than a theoretical optimiser may be economically preferable to an elaborate configuration needing periodic repairs, subscriptions or cloud data. Conversely, a site that regularly faces extreme dynamic prices, batteries and multiple competing charge deadlines may have enough potential to justify the extra engineering. Measure, then choose the simpler method unless quantified evidence favours the other.
How EMHASS actually runs: optimising is not the same as controlling
As documented in the current EMHASS usage guide, deployments can use the Home Assistant app/add-on path, Docker or a legacy Python CLI approach. In add-on and Docker modes, the service exposes actions such as dayahead-optim, naive-mpc-optim and publish-data. A successful optimisation calculates a plan; publishing exposes the current planned values to Home Assistant. It does not automatically implement appliance-specific safe switching, charger limits or inverter protections.
An installer should therefore design five explicit layers: measurement; forecast ingestion; optimisation; plan publication/health checks; and device execution. Home Assistant can own the execution automations and monitoring, while manufacturer-approved hardware and controllers retain equipment safety. If the optimiser stops running, the execution layer must recognise that the schedule is stale. “Last known good plan” is not always safe because departure deadlines, room temperatures, battery reserve and tariffs can all change.
| EMHASS interface / concept | Expected role | What to verify | Incorrect assumption |
|---|---|---|---|
dayahead-optim | Produce a horizon-wide schedule using forecast inputs | Forecast units, time step, cost objective and generated timestamp | Calling once means the published current state will update all day |
naive-mpc-optim | Replan from recent actual states and remaining constraints | Runtime state of charge, remaining run-hours and horizon | It automatically knows the battery SOC and unfinished tasks |
publish-data | Expose current schedule position and forecasts to HA | Publish cadence and correct entity mappings | An optimisation output turns a real relay on |
sensor.p_deferrable0 | Scheduled first deferrable power in watts | Nominal-power model, state freshness and device capabilities | The number is measured appliance consumption |
sensor.p_deferrable0_state | Optional simplified command state when configured | Enable corresponding publication option; supported version | The command is present with default settings |
sensor.optim_status | Optimisation status visibility where configured | State meaning, freshness and last successful run | Status alone proves the devices followed the plan |
The official publish-data documentation explains that publishing can use the saved schedule and nearest/current time step; manual publication may need to be repeated as time advances. Some releases support continual publishing and plan/last-run interfaces that help detect stale plans. Check your installed version, because release-specific entity naming, API status codes and schema are not immutable. For example, the current usage guide documents 200 OK for successful JSON action endpoints where old examples assumed 201.
A system using separate day-ahead and MPC runs must also avoid silently overwriting one set of entity IDs with another. Either nominate the MPC schedule as authoritative after each successful recalculation or use documented publish prefixes and verify the published entity you actually consume. Home Assistant should not act on an entity just because it has a plausible numeric state; verify that the plan corresponds to the current run, correct time zone and expected load.
Set the objective correctly: cheap electricity is not the entire goal
EMHASS provides configurable cost objectives, including documented profit, cost and self-consumption modes. These are not synonyms. The appropriate objective depends on whether exported electricity is paid, whether a battery can charge from the grid, and whether the household is seeking minimum import cost or maximum net monetary benefit. For high export prices, a profit-oriented plan may export midday solar and shift a flexible task to a cheaper period. A self-consumption plan might prefer using that same solar locally; one is not categorically better without the user’s objective.
Represent non-negotiable constraints before comparing objective values: site import limit, usable battery energy, protected reserve, inverter charge/discharge power, EV energy before departure, hot-water temperature requirements, appliance start times and minimum continuous run periods. Cost calculations that ignore a missed departure or failed heating comfort are not legitimate household savings. Similarly, a mathematically infeasible plan is a prompt to change a flexible objective or deadline, never permission to bypass protective current limits.
| Objective or restriction | Illustrative modelling treatment | Validation question |
|---|---|---|
| Import cost | Grid-import kWh multiplied by interval-specific delivered price | Does the price include appropriate unit charges? |
| Export value | Grid-export kWh multiplied by agreed export payment | Is the feed-in agreement fixed or time dependent? |
| Battery storage | SoC transition, charge/discharge efficiency and allowed bounds | Does the inverter truly allow every requested action? |
| EV deadline | Wall energy, measured charging efficiency and time available | Is 7 kW sustainable and is vehicle charge taper handled? |
| Hot-water readiness | Independent manufacturer control with suitable temperature constraints | Will domestic hot-water hygiene still be maintained? |
| Grid and circuit limit | Commissioned local protection independent of optimiser | What happens if HA/EMHASS or network fails? |
| Appliance cycle integrity | A continuous approved cycle, rather than arbitrary pulses | Can this appliance resume safely after interruption? |
Worked arithmetic: what one kilowatt-hour is really worth
Case A: shifting ordinary load on a dynamic tariff
Suppose a flexible 3 kWh load can run during either a 31 p/kWh evening period or a 13 p/kWh overnight period. The gross energy-price difference is 18 p/kWh and the illustrative saving is 3 × £0.18 = £0.54 per completed cycle. If the household repeats this five days a week for 40 weeks, the theoretical annual value is £108. But an already configured cheap-rate timer earns that value without EMHASS. The optimiser’s incremental benefit is only whatever it achieves beyond that working baseline, not £108.
Case B: PV self-consumption versus paid export
Assume a 2 kWh water-heating task can run in daylight using otherwise exportable solar worth 9 p/kWh or overnight using imported electricity at 12 p/kWh. The marginal day-versus-night cost difference is only 2 × (£0.12 − £0.09) = £0.06, ignoring storage and heat losses. Calling daytime PV “free” overstates the benefit. If the export payment were 16 p/kWh, it could be financially better to export in daytime and heat water using 12 p/kWh overnight, provided both choices meet hygiene, comfort and equipment constraints. A native rule using the correct tariff inputs could reach the same conclusion as EMHASS.
Case C: grid-to-battery arbitrage after losses
Consider charging a battery with 5 kWh at 10 p/kWh and later discharging at a round-trip efficiency of 85%. The household receives only 4.25 kWh of usable energy. If the avoided peak price is 30 p/kWh, avoided purchases are worth £1.275, while charging cost is £0.50. Gross arbitrage margin = £0.775 before battery wear, inverter operating consumption, export opportunity cost and tariff restrictions. If the battery’s incremental throughput cost were an illustrative 6 p per delivered kWh, subtract £0.255 to obtain approximately £0.52. These inputs are examples, not a promised return or battery-life estimate.
| Illustrative action | Input | Gross value | Important omitted or additional factor |
|---|---|---|---|
| 3 kWh task at 13p rather than 31p | 18p/kWh differential | £0.54 saved per cycle | Already achievable with a fixed timer |
| 2 kWh solar versus 12p import | 9p/kWh export foregone | £0.06 advantage for solar | Thermal losses and alternative loads |
| 5 kWh battery charge at 10p | 85% round-trip; 30p avoided peak | £0.775 gross spread | Battery wear, SoC reserve, operating costs |
| EV needs 16 kWh at battery | 90% illustrative charge efficiency | 17.78 kWh at wall | Real vehicle and charger power curves |
| Four high-price hours avoided | Must know actual flexible energy | Not calculable from price alone | Comfort, task constraints and site load |
Watch unit conversions carefully. EMHASS publishes most planned powers in watts, tariffs are commonly represented in currency per kilowatt-hour, and energy over an interval is power (W) × interval (h) / 1000. A 3,000 W immersion load running for one half-hour consumes 1.5 kWh, not 3 kWh. Combining prices expressed as pounds/kWh with a feed expressed as pence/kWh can create a 100-fold error while every sensor remains numerically plausible.
A realistic comparative case study: PV, battery, EV and hot water
Take an illustrative UK home with 5 kWp of PV, a 10 kWh nominal battery with 8.5 kWh usable for routine scheduling, a single-phase EVSE nominally capable of 7 kW and a 3 kW immersion heater. Assume a 24-hour price feed, a modest export payment and a morning EV departure. The charger has its own supply-current management and the cylinder retains its approved thermostat and hygiene settings. The higher-level system is allowed to request when tasks run, not bypass any of these controls.
At 16:00 the forecast might indicate a 2 kWh PV surplus remaining before sunset, a 4 kWh evening household requirement, and 14 kWh required into the EV battery by 07:30. One controller must make priorities explicit. Should the battery reserve cover evening cooking? Is export compensated? Does hot water need reheating today or can it wait until the cheap tariff? A simplistic “run every load when surplus appears” rule could start more load than the inverter can support, whereas an EMHASS schedule with correct constraints can select among competing periods. A carefully written native priority ladder could also solve this particular scenario.
| Time block | Illustrative environment | Native-rule candidate | Forecast-optimised candidate | Validation criterion |
|---|---|---|---|---|
| 16:00–18:00 | Intermittent solar; battery partly full | Use measured export with minimum-on time | Schedule available surplus to one suitable load | No unnecessary grid import from simultaneous loads |
| 18:00–22:00 | Higher tariff; household occupied | Keep reserve; block discretionary loads | Reserve energy for evening essentials | No reserve violation |
| 22:00–00:30 | Moderate tariff | Leave charger waiting | May charge only if deadline requires it | Correct vehicle energy forecast |
| 00:30–04:30 | Cheap window | Charge EV at permitted current | Allocate EV and other loads under site limit | Departure target met and circuit current remains safe |
| 04:30–07:30 | Tariff rises; departure approaches | Fallback top-up if required | Replan on actual SoC and missed tasks | No departure failures |
| Next day midday | Forecast variable sunshine | Respond to measured surplus | Use latest PV forecast and battery SoC | No assumptions that forecast equals measurement |
The best comparison uses the same measured weather, household load, prices and device constraints. Running a day-ahead simulation on a historical day with the actual next-day solar curve is not a fair operational test: that is hindsight. EMHASS offers perfect-optimisation methods for evaluation, but a result based on future facts should be reported as a theoretical lower-cost bound, not as proof that a forecast-based real-time controller would have achieved it.
Installation choices and a minimum viable EMHASS deployment
Before installation, inventory the supported data sources: a reliable grid import/export meter; PV output (if installed); a household load sensor excluding scheduled loads; import and export tariff forecasts; device state; and any battery SoC. Review the current EMHASS configuration reference for parameter names and supported services. A configuration that launches with demonstration defaults is not necessarily reading your actual home correctly. In particular, EMHASS documentation explicitly expects sensor_power_load_no_var_loads to exclude the controllable loads represented elsewhere in the optimiser.
- Stage 1: Confirm that utility-meter or certified meter data agree with the bill within an explained tolerance. Resolve energy-sign conventions before creating forecasts.
- Stage 2: Select one truly shiftable task, such as a charger with an approved schedule interface and an explicit ready-by time. Leave battery control disabled initially.
- Stage 3: Build daily price and demand forecasts, inspect timestamp alignment and document whether the feed includes VAT or other variable charges.
- Stage 4: Install the supported EMHASS deployment type, configure site values and run a day-ahead plan without controlling devices.
- Stage 5: Check published sensors against the saved plan, including schedule updates when the clock advances and after Home Assistant restarts.
- Stage 6: Run at least one to two weeks in shadow mode. Compare simulated cost and missed requirements with the native automation baseline.
- Stage 7: If savings and reliability are convincing, allow a single non-critical schedule action through an approved device API, retaining a manual and local fallback.
Read-only example: freshness and optimisation observation
This Home Assistant YAML example deliberately does not control any load. It reports whether the first published deferrable-power sensor appears numeric and exposes the age of its most recent entity update in minutes. It is illustrative: substitute the actual EMHASS entity ID and separately check the optimiser’s own run timestamp. A sensor may be republished on schedule even if the source optimisation itself is old, so entity age alone is necessary but not sufficient.
template:
- sensor:
- name: "EMHASS deferrable plan age"
unique_id: emhass_deferrable_plan_age_minutes
unit_of_measurement: "min"
state: >
{% set obj = states.sensor.p_deferrable0 %}
{% if obj is not none %}
{{ ((as_timestamp(now()) - as_timestamp(obj.last_updated)) / 60) | round(1) }}
{% else %}
{{ none }}
{% endif %}
- name: "EMHASS scheduled first load"
unique_id: emhass_scheduled_first_load_w
unit_of_measurement: "W"
device_class: power
state: >
{% set v = states('sensor.p_deferrable0') %}
{{ v | float if is_number(v) else none }}The last_updated attribute is a Home Assistant entity update indicator, not an assurance that a new optimised plan has been calculated. On versions supporting the EMHASS last-run or plan API, use its optimiser run identifier and timestamp as the definitive source of freshness. To keep this example monitoring-only, do not connect these template entities directly to a charger, relay, immersion controller or battery write service.
A safe execution architecture: one authority per device
A solver-generated schedule is advice to the execution layer. Choose one authoritative controller for the EVSE target current, one authority for the inverter’s storage operating mode, and one equipment-approved controller for domestic hot water. If the car’s app, charger timer, evcc, Home Assistant and EMHASS all attempt to start or stop charging, the site can oscillate between incompatible modes. Explicitly document who has write permissions and disable competing non-safety routines. Protective systems remain active regardless of that ownership decision.
| Asset | Safe control owner | What EMHASS can request | Required fail-safe |
|---|---|---|---|
| EV charger | Commissioned EVSE and approved supply/load management | Preferred charging windows through supported API | Electrical current limits, RCD measures and charge-state fallback |
| Solar inverter / battery | Vendor inverter/BMS firmware | Documented high-level reserve or mode preference, only where supported | SoC, cell limits, export compliance, warranty controls |
| Heat pump | Manufacturer controller | Optional non-critical schedule preferences | Minimum flow, anti-freeze, defrost, compressor limits |
| Hot-water cylinder | Certified thermostat, over-temperature protection and approved controller | Timing for permissible reheating windows | Scald/temperature protection and hygiene regime |
| Washing machine | Appliance’s approved timer or remote-start interface | Suggested start before a user-defined deadline | No unsafe mains switching or unattended remote start |
| Household grid limit | Installer-approved local load-limit apparatus | Stay within scheduled discretionary import target | Hard limit independent of LAN, cloud and optimiser |
A robust plan executor should pass several checks before acting: the optimiser run is recent; the current schedule belongs to the current timezone interval; measured power and price are plausible; the target device is available; no higher-priority manual or safety lockout is active; and the expected task has not already finished. When any check fails, do not substitute an imaginary zero tariff, stale battery SoC or an expired schedule. Instead, fall back to a conservative local rule or the device’s native schedule.
For example, if EMHASS planned two hours of charging overnight but the network fails at 02:00, a critical next-morning departure target must not depend on repeated internet requests to continue. The fallback could be a known charger-native deadline schedule already commissioned for the vehicle and supply. Conversely, a discretionary immersion boost can simply be skipped if the approved cylinder controller continues to ensure required temperature and hygiene. The right fallback is asset-specific; a blanket command to “turn everything off” is not always safe.
Day-ahead versus rolling-horizon MPC: choose the cadence carefully
Day-ahead optimisation is straightforward when the tariff publishes tomorrow’s prices in advance and the planned loads have deadlines. The method typically solves the whole horizon and publishes a schedule. Rolling-horizon MPC repeatedly uses new measurements and forecasts, executes only the immediate portion of the result, then solves again. It can correct unexpected solar production or an EV arriving later than expected, but a new run may move previously promised loads unless their already-executed energy and remaining requirements are updated correctly.
The current official MPC walkthrough uses runtime inputs such as prediction_horizon, soc_init, soc_final and def_total_hours. Importantly, the documentation notes that omitting soc_final does not mean “finish at today’s SOC”; a configured default may apply. Likewise, the remaining hours for a deferrable appliance should fall as it actually operates. Treat runtime input preparation as a small, testable software component, not as a casual template copied from a demonstration.
| Planning horizon / cadence | Best fit | What goes wrong | Verification |
|---|---|---|---|
| Once daily, 30-minute slots | Published day-ahead price and modest loads | Forecast stale after changed occupancy or PV | Check actual energy by the next day |
| Every 30 minutes, 30-minute slots | Materially varying PV and battery SoC | State updates incorrect; plan flaps | Track run ID, SoC and remaining demand |
| Every 5–15 minutes | Rapidly changing load and sufficiently controllable device | Chattering, insufficient sensor accuracy, API quotas | Minimum hold time and command limits |
| Event-driven replan | Vehicle arrival, changed departure, lost tariff feed | Excessive or simultaneous re-optimisations | Debounce events and log causal reasons |
| No replan, fixed native schedule | Simple, predictable tariff and one device | Can miss genuinely exceptional prices | Compare against optimisation counterfactual |
Do not confuse timestep resolution with metering resolution. A 30-minute optimisation interval represents average energy/power in that interval and cannot enforce a sub-second circuit protection constraint. Nor can a generic Wi-Fi smart plugAliExpress price guarantee the integrity of an EV charge or a 3 kW immersion load. Where the installed hardware requires minimum on/off times, anti-short-cycle timers or local fallback, those properties must survive restart and network loss without depending on the solver.
Data quality: the errors most likely to distort an optimisation
Separating controllable energy from the baseload
One of the least obvious data problems is double counting flexible load demand. EMHASS is asked to schedule an appliance, yet its household load forecast may already include the same appliance’s historical consumption. The optimiser then treats that expected consumption as fixed and adds a second scheduled instance. Build a consistent measured power balance using site flow meters and appliance meters, taking account of inverter signs and battery contributions. The documentation’s sensor_power_load_no_var_loads setting exists for this reason. A simple subtraction can work when both inputs describe the same phase and measurement boundary, but it can fail if one is AC input power and another is net import or if the meter signs are reversed.
Price timestamps and daylight saving time
Electricity-price periods are timestamped intervals, not strings such as “hour 02”. Across the spring change to daylight-saving time a day may contain 23 local hours; across the autumn change it may contain 25. The same wall-clock label can occur twice with different UTC offsets. Maintain timezone-aware timestamps, align forecasts to the interval start/end convention used by the supplier, and validate array lengths against the configured optimisation timestep. The current EMHASS configuration documentation explicitly discusses local-calendar-day forecast windows across DST transitions.
Forecast model drift and exceptionally bad days
Sunshine forecasts may be systematically optimistic for a shaded array, roof orientation or microclimate. A household load profile learned from ordinary weekdays can be poor during holidays or guests. Heating demand can change with wind, thermal lag and occupant behaviour. Compare forecast versus realised load and PV by interval, not just total kWh; a forecast that predicts exactly 12 kWh of daily solar but places it three hours late can still produce a bad plan. If a household’s error becomes large or data freshness drops, use actual meter readings and a conservative rule until the forecast source recovers.
| Error | Observable symptom | Likely consequence | First check |
|---|---|---|---|
| W instead of kW | Power is scaled by 1,000 | Unusable constraints or implausible cost | Entity unit and configured input |
| p/kWh instead of £/kWh | Forecast cost off by factor 100 | Nonsensical profit ranking | Normalize price unit explicitly |
| Net import fed as baseload | Load turns negative during PV export | Unrealistic demand curve | Derive real household consumption correctly |
| Flexible load already in forecast | Load model contains planned EV/heater energy | Demand counted twice | Separate variable from non-variable load |
| Incorrect battery power sign | SoC forecast rises while battery discharges | Wrong arbitrage schedule | Verify with a physical charge/discharge event |
| SoC represented as 63 not 0.63 | Battery state infeasible | Optimiser errors or wrong limits | Check expected fraction/percentage for installed release |
| Tariff 02:00 duplicated at DST | Misaligned prices and slots | Schedules run in wrong period | UTC timestamps and locale alignment |
| Old plan republished as current | Plan sensor changes timestamp but not intent | Runs under expired assumptions | Last-run ID and horizon start |
| Cloud EV SoC delayed | Battery target already achieved or impossible | Missed departure or wasteful charging | Measure charged energy and confirm vehicle |
| Device ignores schedule | Plan cost low, actual bill unchanged | False claimed savings | Compare commanded and measured execution |
How to measure whether EMHASS actually beats native rules
A comparison should evaluate realised net electricity cost, not merely the optimiser’s predicted cost function. For each billing interval, record actual grid import in kWh, retail import price, actual export in kWh and export compensation; add any relevant standing charge consistently, and document if the battery wear estimate is excluded. Then compare periods with similar load, weather and user requirements, or replay both control strategies using the same forecast available at decision time. A solver granted knowledge of tomorrow’s actual weather has an unfair advantage over the production automation.
Three benchmarking levels are useful. First, a simple native schedule is the primary baseline, because that is the plausible alternative the owner would use. Second, EMHASS operated in shadow mode can show planned actions and projected cost without ever switching a relay. Third, a supervised live pilot on one low-risk device measures whether the plan is actually executable. If a shadow simulation says save 40 p/day but repeated charger handshakes, delayed sensor updates or an incompatible appliance prevent half the actions, the observed gain will be smaller.
| Metric | Definition | What counts as a pass |
|---|---|---|
| Gross energy cost | Sum of interval grid import × price | Lower cost under comparable conditions |
| Net energy cost | Gross import cost minus export earnings | Improves after export opportunity cost |
| Savings per flexible kWh | Baseline net cost minus pilot net cost, divided by shifted kWh | Positive after losses and constraints |
| Plan execution rate | Planned feasible actions actually completed / intended actions | Near-complete, with failures explained |
| Departure readiness | EV meets specified usable energy by deadline | No deterioration versus baseline |
| Thermal comfort compliance | Temperature and approved hot-water requirements met | No sacrificed comfort/safety |
| Control reliability | Time with valid forecast, price, meter and device API | Sufficient for operational dependence |
| Automation interventions | Manual fixes or resets per month | Manageable maintenance burden |
Cost study: how much incremental saving buys the extra complexity?
Assume the owner estimates EMHASS might reduce the household’s net electricity bill by an additional £0.25 per day beyond working native rules for 300 relevant days. That is £75 per year. If the setup needs £150 of incremental equipment and the owner values annual maintenance at £25, a simple first-year net benefit is £75 − £150 − £25 = −£100. Over five years with the same illustrative savings and maintenance cost, gross saving is £375 and the combined extra spend is £275, for a nominal £100 advantage before discounting, electricity-market changes and unforeseen repairs. The model is not a tariff forecast; it demonstrates why “optimisation saves energy” is too vague to justify a purchase.
At an extra £1 per day for 300 days, the gross potential becomes £300 per year and the economics change considerably. The point is not to promise either result; it is to estimate the actual marginal value in your usage pattern and check whether the chosen devices can follow the plan. An inexpensive locally hosted EMHASS service may still be worthwhile as an engineering project even where payback is marginal, provided the owner labels that choice honestly rather than inventing household savings.
Case studies: when forecast optimisation is and is not worth it
House A: flat overnight discount and one EV
The house has no solar battery, one EV, a charger with a reliable deadline timer and an electricity contract with an unchanged cheap overnight window. Native charger scheduling is the default recommendation. EMHASS may be interesting for experimenting with occasional solar charging, but the financial margin beyond a correctly configured native timer is likely to be limited. Spend effort confirming charger efficiency and completed overnight charges rather than building a solver.
House B: variable prices, rooftop solar and an EV
This house has a true dynamic price feed, 5 kWp PV, a capable EVSE, an afternoon return time that varies and a target energy before morning. A forecast-based controller may beat a simplistic solar-export threshold, particularly when a sunny afternoon is expected but a very cheap overnight interval is available. Compare EMHASS with a good price-aware native automation first. If both reach similar costs and one is simpler, choose simplicity. If the solver reliably meets departure targets while reducing measured net cost, its extra complexity is easier to justify.
House C: PV, home battery and two deadlines
Suppose the home battery needs a protective evening reserve, the EV requires a charge before 07:00 and an approved immersion heater needs a reheating window. Several competing constraints can make a hand-written set of priorities brittle. EMHASS may give a clearer, auditable plan, but only if battery modes and charger current controls are genuinely supported. If the inverter firmware refuses third-party schedules or the charger consumes battery power despite the plan, the idealised optimisation is irrelevant. Vendor controls and actual interface support determine feasibility.
House D: weather-compensated heat pump and underfloor heating
A stable heat-pump weather-compensation curve and well-balanced underfloor heating often outperform aggressive on/off scheduling in comfort and compressor operation. A cost optimiser that preheats the slab must model the building’s thermal response, flow-temperature-dependent COP, maximum comfort limits and any manufacturer minimum run times. Otherwise it may shift kWh to a cheap period while using more electricity and causing worse comfort. First optimise the native heat-pump controls, then consider forecast-based preferences where the manufacturer interface and measured COP justify them.
House E: cheap-price automation with fragile internet
This home has unreliable WAN service and a mixture of cloud-only vehicle and inverter integrations. Moving to an EMHASS solver on the local Home Assistant host does not make those remote APIs local. A grid meter and a few offline-capable schedules may deliver greater reliability than an ambitious multi-device optimiser that loses commands when the vendor cloud becomes unavailable. Consider replacing a critical data path with a documented local interface before adding scheduling sophistication.
Security and operational ownership
An energy optimiser exposes a new command surface. Keep the EMHASS web service and any REST endpoints on the trusted local network; do not expose its default HTTP endpoint or Home Assistant long-lived token directly to the public internet. Apply software updates, protect secrets, and limit the service account to the permissions needed. If a remote price feed or MQTT broker is unavailable, the schedule should be treated as degraded rather than silently accepting stale data. A command path able to alter inverter operating modes deserves tighter access control and audit logging than a read-only dashboard.
Backup and restore testing matters because a site may operate differently after reboot: the solver process may start after Home Assistant, forecast arrays can be missing, and the saved plan may belong to yesterday. Record the version, configuration snapshot and entity mapping. Perform controlled failure tests with the installer-approved protections in place: disconnect the WAN, restart the optimiser, make a price entity unavailable, simulate a stale forecast and cancel a vehicle charge. Confirm both that scheduled comfort or departure goals are handled sensibly and that no unsupported control command is issued.
| Failure test | Expected result | Red flag |
|---|---|---|
| Forecast service unavailable | Skip re-optimisation or use explicitly degraded baseline | Unknown solar treated as perfect sunshine |
| Tariff API returns empty series | Conservative native rate schedule or alert | Missing prices assumed zero |
| HA restarts during cheap window | Restore safe schedule with freshness check | Rapid charger start/stop cycling |
| Battery SoC stale | Disable storage-dependent optimisation | Inverter pushed beyond reserve target |
| EV remote API stops updating | Use approved charger-local deadlines | Vehicle ready-by promise relies on stale SoC |
| Device refuses planned action | Log failure and re-evaluate remaining demand | Theoretical savings recorded anyway |
| Manual override activated | Manual preference takes priority until explicitly reset | Optimizer immediately reverses the user |
| Optimiser and native timer both enabled | One authoritative scheduling owner | Opposing start/stop commands every minute |
Commissioning and maintenance checklist for a real installation
- Metering: Verify direction, phase mapping, kW/kWh units, time stamps and equality to the supplier bill over a suitable period.
- Prices: Check pence versus pounds and whether the feed represents actual retail import cost or only wholesale energy.
- Forecast inputs: Compare forecast PV and background load with the last two weeks of realised observations, paying attention to hourly shape.
- Flexible devices: Confirm supported start/stop or power interfaces, ready-by deadlines, continuous-run constraints and local fallback.
- Battery: Document useful capacity, SoC range, efficiency, reserve, firmware control permissions and manufacturer restrictions.
- Safety: Retain approved charger load management, temperature protection, heat-pump minimum flow and all inverter protections.
- Planner: Log EMHASS release, optimisation endpoint, solver status, objective and run timestamp. Validate any new release in shadow mode.
- Published entities: Confirm which schedule is authoritative and whether the current state actually advances over time.
- Actuation: Enforce freshness, manual override, minimum on/off times and device status checks before commands.
- Finance: Compare measured import and export value against the same feasible native-rule baseline.
- Maintenance: Test DST, restarts, firmware upgrades and network outages; keep a working rollback and export of the last known configuration.
For related esp32AliExpress price.co.uk guides, read Home Assistant Energy Dashboard: correct grid, solar and battery entities, how to verify energy measurements against your utility bill, solar surplus EV charging with Home Assistant, and Forecast.Solar versus Solcast. These explain measurement and forecast inputs you should validate before giving an optimisation output control over a household load.
Official references consulted for this section: EMHASS core concepts and cost objectives, optimisation endpoints, configuration and modelling requirements, runtime forecast data, published data, rolling-horizon MPC, and Home Assistant template integration. Configuration, entity availability and API response behaviour can change between releases, so check the version installed on your own system.
Verdict: use optimisation only after measurement and simple rules
For most homes, native Home Assistant automations are the correct first step. They are understandable, testable and sufficient for fixed off-peak windows or basic solar-surplus switching. EMHASS becomes attractive when accurate forecasts and several controllable loads create genuine trade-offs that simple rules cannot manage efficiently. Treat it as a planning layer, validate it in dry-run mode, and retain manufacturer-approved safety and fallback controls.