Quick Summary (TL;DR)
Price-aware Home Assistant automations should move flexible electricity use into genuinely cheaper periods without sacrificing safety, comfort or deadlines. The most reliable starting point is simple: use the device’s approved scheduling interface, confirm the actual import tariff, set a latest-finish time, measure what happened, and give the household an explicit manual override. A cheap-looking interval does not justify leaving an EV undercharged, bypassing a cylinder thermostat, or remotely starting an appliance that cannot safely support it.
For EVs, the strongest setup combines a charger- or vehicle-supported start schedule with a realistic wall-energy target and departure deadline. For stored hot water, favour the cylinder or heat pump’s approved control path and preserve over-temperature, hygiene and backup-heating provisions. For dishwashers and washing machines, verify whether the appliance supports a manufacturer-approved delayed or remote start; a basic energy-monitoring plug cannot create that capability.
This guide compares fixed overnight, time-of-use, dynamic-price and solar-surplus strategies; explains priorities and failure modes; supplies monitoring-first Home Assistant YAML; and shows how to calculate savings with import prices, export value and measured energy. All example tariffs, powers and costs are illustrative, not live quotes. Confirm features against the exact firmware, model, region and installer documentation before enabling any control.
A simple baseline typically beats a complex optimiser when you have one flexible load and a predictable cheap window. More elaborate schedules help when multiple loads compete for a limited supply, prices fluctuate materially, or you have a battery and solar generation. In all cases, the original equipment must retain its protective functions and each actuator must be verified in commissioning.
What makes an automation genuinely price-aware?
An automation is not price-aware merely because it runs at night. It must understand the difference between the current and alternative time windows, whether the load can be moved, and what happens if the cheaper period is missed. The decision is a small scheduling problem: assign a bounded quantity of energy to feasible future intervals, subject to power limits and a latest completion time. A fixed economy tariff makes this relatively straightforward; variable and market-linked rates need a trusted time series and repeated validity checks.
A practical installation has three different layers. Observation provides trustworthy metering, tariffs, device readiness, capacity and timestamps. Decision selects a window or power target based on a cost rule and deadline. Execution asks a supported controller to act, observes whether the command actually succeeded and abandons optimisation if a safety-critical condition or data dependency fails. Treating all three layers as one “if price low, turn switch on” rule hides most of the real engineering risks.
| Question | EV charger | Hot-water cylinder | Washing machine / dishwasher |
|---|---|---|---|
| Required result | Battery receives sufficient energy by departure | Usable water and compliant temperature routine | Cycle completed before needed |
| Time flexibility | Often hours, limited by vehicle presence | Depends on storage and heat loss | Only when loaded and supported for deferred start |
| Approved command path | Manufacturer-supported charger/vehicle API or timer | Approved immersion diverter, heat-pump or cylinder controller | Vendor delayed/remote-start mechanism |
| Critical independent controls | Electrical load management, protective functions | Thermostat, thermal cut-out, hygiene regime | Appliance interlocks and manufacturer safety logic |
| Measured confirmation | Wall kWh, current, charge state if exposed | Thermal/electrical data and tank sensor | Actual running/completed cycle or metered consumption |
| Common error | Assume vehicle SOC exists or power matches nameplate | Treat mains smart plugAliExpress price as a certified immersion switch | Power-cycle a machine to simulate pressing Start |
Choose a tariff model before writing any schedules
For a fixed-rate tariff, there may be little financial advantage in shifting a load at all; solar self-consumption or peak-network constraints can still matter. A peak/off-peak tariff offers recurring windows, but local times and day types must match your actual contract. A dynamic tariff varies by published settlement interval—often 30 or 15 minutes depending on supplier and market. Those intervals are not a promise that the same price will be available tomorrow, and a wholesale-market integration may omit supplier margin, network charges, levies or tax.
Model the marginal cost of one additional imported kilowatt-hour, not the household’s entire average bill divided by kWh. The standing charge generally does not change if the car charges at 02:00 instead of 19:00; it belongs in total bill reconciliation but not in the marginal savings calculation. If an electric load consumes solar that would otherwise be exported, the relevant opportunity cost may be the lost export payment rather than zero. For grid-charged batteries, round-trip losses and incremental battery use matter as well.
| Tariff input | Correct unit | A valid use | Typical trap |
|---|---|---|---|
| Import retail rate | £/kWh or €/kWh | Cost of consuming one additional imported kWh | Mixing pence/kWh with pounds/kWh |
| Export payment | Currency/kWh | Opportunity value of using PV locally | Assuming all exported solar earns the same value |
| Settlement start/end | Timezone-aware timestamps | Apply the rate to the proper consumption interval | Assuming every calendar day has 24 one-hour slots |
| Standing charge | Currency/day | Bill reconciliation and tariff comparison | Claiming it is saved by shifting 3 kWh |
| Load energy | kWh | Sum price × energy across valid slots | Multiplying watts by pence/kWh |
| Load feasibility | kW and minutes | Verify completion before deadline | Assuming vehicle always accepts rated current |
A conservative forecast-driven controller should label every price as known and valid, known but old, or unavailable. “Unavailable” is not £0.00/kWh. If tomorrow’s dynamic tariff has not arrived, do not fill it with free energy. Instead retain the approved device timer, enforce the household deadline and notify the user that cost optimisation is suspended. The companion guide Home Assistant electricity tariff sensors covers rates, entities, Utility Meter and interval alignment in more detail.
Hardware and interfaces: buy capabilities, not just a cloud logo
The most important buying question is not whether an app displays live watts: it is whether the device exposes an authorised, stable control path for the intended operation. A device can expose beautiful statistics and still offer no supported start/stop API. Conversely, a charger may implement safe local schedules without exposing a rich Home Assistant entity. Integration depth varies by model, region and software revision, and some functions rely on a vendor account or WAN connection.
| Device class | Useful capability | Minimum evidence before buying | What not to infer |
|---|---|---|---|
| EV wallbox | Schedule control, enable/pause, adjustable current when supported | Exact model firmware, HA integration actions, API rate limits, local fallback | OCPP support guarantees every smart-charging feature |
| EV via manufacturer cloud | Car charge target and status | Rate limits, authentication, availability, charge-state refresh | Displayed SOC always reflects battery immediately |
| Approved PV diverter | Immersion power modulation and thermal safety coordination | Compatible heater rating, metering, wiring and temperature protection | Any solid-state relay replicates a certified controller |
| Heat-pump DHW scheduler | DHW target/time window with native protections | Manufacturer API, compressor protection, backup heat and hygiene configuration | Generic relay can manage compressor safely |
| Smart appliance with remote start | Manufacturer-approved scheduled or remote cycle | Feature supported by that exact appliance and door/start conditions | A switched socket can simulate a remote Start button |
| Energy monitor | Reliable kWh and net import/export readings | CT placement, direction, accuracy and uptime | Power sensor alone can authoritatively control plant |
| Home Assistant host | Local rules, helpers, history and notifications | Reliable storage, time sync, backup and supported integration | Local HA automatically removes cloud dependencies |
For a new installation, pay attention to offline behaviour. Will the EV charger continue a locally stored cheap-rate schedule with internet disconnected? Will the water-heating controller keep its thermostat and schedule without Home Assistant? Can the washer finish its programme if the Wi-Fi drops? Ask these questions before purchasing gateway hardware or chasing a more complex energy-management stack. You can often get more resilience from a suitable charger with native scheduling than from a cloud-only device linked through six automations.
For electrical equipment, local regulations, protective devices, cable ratings, phase balancing and manufacturer instructions take precedence over software. Home Assistant should never defeat an EVSE’s dynamic load-balancing protection, a heat source’s high-limit thermostat or appliance interlocks. Immersion heaters are commonly high-current, fixed-wired loads: control must use appropriate, professionally installed equipment, not an unverified general-purpose plug. That distinction is especially relevant when comparing Wi-Fi relays and approved immersion controllers.
Start with an automation architecture that has one scheduling owner
A robust design names the owner of each decision. The wallbox can own electrical current limits and safety. A native charger timer or Home Assistant can own the charging schedule, but not both independently. The cylinder controller owns temperature protections and any required pasteurisation or hygiene cycle. Home Assistant can ask for a DHW window only where the manufacturer supports it. The washing machine retains its door, motor and programme logic. One source of truth for scheduling prevents a cascade of contradictory start/stop commands.
| Layer | Example input/output | Owner | Response to failure |
|---|---|---|---|
| Tariff feed | Interval price in £/kWh | Supplier or trusted integration | Mark stale; fall back to approved schedule |
| Site measurement | Import/export kW and cumulative kWh | Correctly installed energy meterAliExpress price | Stop optimisation that depends on surplus |
| Readiness | Vehicle plugged in, tank requires heat, appliance armed | Device/native controller | Do not attempt start when not ready |
| Price decision | Cheap-window suggestion and latest start | HA automation or optimiser | Deadline-first conservative schedule |
| Execution | Supported API call or preconfigured timer | Device/controller | Do not bypass protection; report failure |
| Completion proof | Delivered kWh, temperature or cycle ended | Measured or vendor state | Alert and leave user in control |
| Manual override | Pause optimisation or finish now | Household dashboard | Overrides remain effective until intentionally reset |
Build a dashboard with three plain-language states per load: Ready, Waiting for cheaper period and Running, plus Disabled/Needs attention. Show why the automation made its decision: the expected effective price, deadline, energy remaining, planned run time, last valid data timestamp and active override. An opaque “optimisation active” binary sensor is less useful than one sentence explaining why the EV has not started.
Calculate the EV charging deadline before optimising price
Imagine an EV that must gain 24 kWh of battery energy by 07:30. At a 7.0 kW AC wallbox and assumed 90% energy transfer efficiency, it needs approximately 26.7 kWh at the wall. A realistic charge time is 26.7 ÷ 7.0 = 3.81 hours, before pauses, taper, cold-weather conditioning or current limits. If the car arrives at 19:00, the usable window is 12.5 hours; the schedule can favour cheaper slots as long as it preserves a sufficient margin before departure.
These numbers are examples, not a universal charger efficiency claim. Actual AC charging power can vary with onboard charger, minimum current, supply voltage, single- versus three-phase wiring, battery management and simultaneous house load. If the charger offers a supported measured-energy target, prefer it over a guessed SOC conversion. If vehicle SOC is unavailable, treat delivered wall energy as the measured quantity and keep a wider buffer. Avoid presenting “battery fully ready” based solely on a wall energy estimate.
| EV calculation | Illustrative value | Method or constraint |
|---|---|---|
| Required battery energy | 24.0 kWh | Owner-set energy target |
| Assumed transfer efficiency | 90% | Scenario assumption; measure for your setup |
| Wall energy target | 26.7 kWh | 24.0 / 0.90 |
| Available AC power | 7.0 kW | Actual charge power, not marketing maximum |
| Ideal charging duration | 3.81 h | 26.7 / 7.0 |
| Planning allowance | 0.75 h | Example buffer for intermittent limitations |
| Planned latest start | 02:56 for 07:30 target | 07:30 minus 3.81 h minus 0.75 h |
| Fail-safe response | Start earlier when target is at risk | Use charger-approved deadline/ready-by option |
A cheap interval beginning at 03:00 may be too late even if it has the lowest price. The correct optimiser weighs the marginal saving against missing the departure target; an owner may reasonably choose to pay a little more to guarantee readiness. If the household changes departure time, the schedule must be rebuilt and the car’s existing charge target respected. Vehicle charging should remain possible manually even when tariff APIs are unavailable.
Worked EV example: choose feasible cheap intervals, not just the single cheapest number
Assume a simplified 4-hour charge requirement and four available one-hour windows, each able to deliver 7 kWh at the wall. Let the hypothetical import rates be 12p, 14p, 30p and 9p/kWh over four eligible hours. The cost is the sum of each interval’s charge energy multiplied by that interval’s rate; for the four slots that is 7 × (£0.12 + £0.14 + £0.30 + £0.09) = £4.55. If one more eligible hour at 10p existed, replacing the 30p hour would save 7 × (£0.30 − £0.10) = £1.40. No savings are realised if the device fails to start, the rate is actually wholesale-only, or the replacement slot falls after departure.
For quarter-hour settlement periods, compute capacity for each interval as kW × 0.25 h. A 7 kW charger can ideally deliver 1.75 kWh in a 15-minute slot. The optimiser must account for partly used slots, connection time, ramping, available current and minimum power of the EVSE. A quarter-hour with a negative price may look attractive, but the EVSE may be unable to start and stop cleanly at that cadence; repeated toggles can also conflict with car sleep/wake behaviour and device-specific rate limits.
| Price scheduling rule | Potential benefit | Non-negotiable constraint | Failure signal |
|---|---|---|---|
| Fixed cheap window | Predictable cost, little software | Ready-by deadline | EV has not started when expected |
| Cheapest-N intervals | Lower import cost in variable tariff | Energy requirement and slot timing | Insufficient remaining capacity |
| Solar surplus first | Use PV when its value beats import | Correct export price and metering | Imports rise because supposed surplus was wrong |
| PV + cheap grid fallback | More robust completion | Limit charge source conflicts | EV remains unfinished by morning |
| Departure-first emergency | Protect vehicle readiness | Manufacturer-approved control | Departure still missed or API unresponsive |
Home Assistant example 1: a monitoring-only charging cost and feasibility sensor
The following YAML demonstrates calculation without actuating a charger. Replace example entities with your validated imported retail-price sensor, supported EV wall-power limit and owner-selected energy requirement. The input helper values are examples; create them in Settings → Devices & services → Helpers if you use the UI. The template deliberately reports an unavailable value when the price input is unavailable rather than silently treating bad data as cheap electricity.
# Example configuration.yaml; customise IDs and units.
input_number:
ev_wall_energy_needed:
name: EV wall energy needed
min: 0
max: 100
step: 0.5
unit_of_measurement: kWh
ev_available_power_kw:
name: EV available wall charging power
min: 1
max: 22
step: 0.5
unit_of_measurement: kW
template:
- sensor:
- name: "EV charging hours needed"
unique_id: ev_charging_hours_needed_demo
unit_of_measurement: h
availability: >
{{ states('input_number.ev_available_power_kw') | float(0) > 0 }}
state: >
{% set e = states('input_number.ev_wall_energy_needed') | float(0) %}
{% set p = states('input_number.ev_available_power_kw') | float(0) %}
{{ (e / p) | round(2) if p > 0 else none }}
- name: "EV charging cost at current price"
unique_id: ev_charging_cost_current_demo
unit_of_measurement: GBP
availability: >
{{ is_number(states('sensor.retail_import_price_gbp_kwh')) }}
state: >
{% set e = states('input_number.ev_wall_energy_needed') | float(0) %}
{% set rate = states('sensor.retail_import_price_gbp_kwh') | float(0) %}
{{ (e * rate) | round(2) }}This example calculates an all-at-current-rate estimate, not a forecast charge bill. The estimate will be misleading if the charge spans several changing prices, if the sensor includes VAT inconsistently, or if required battery energy was entered as if it were wall kWh. It is useful precisely because it exposes those assumptions. Before adopting a predictive scheduler, first make sure the measured energy and tariff sensors match the utility bill.
Example 2: a manual override helper and a safe notification-only cheap-price rule
A user override must beat cost optimisation. One practical approach is a toggle helper called input_boolean.price_automation_enabled, restored to off after restart until the homeowner confirms that scheduled control is appropriate. You can make a second “charge now” override in the device’s approved interface. The YAML below merely sends a persistent notification for the owner to review; it does not start an appliance, charger or heater. It therefore demonstrates price-trigger and manual-control logic without suggesting a universal actuator.
input_boolean:
price_automation_enabled:
name: Price scheduling enabled
initial: false
automation:
- id: price_aware_low_rate_notice
alias: Price-aware low rate notice (no switching)
mode: single
triggers:
- trigger: numeric_state
entity_id: sensor.retail_import_price_gbp_kwh
below: 0.12
- trigger: time_pattern
minutes: "/15"
conditions:
- condition: state
entity_id: input_boolean.price_automation_enabled
state: "on"
- condition: template
value_template: >
{{ is_number(states('sensor.retail_import_price_gbp_kwh'))
and states('sensor.retail_import_price_gbp_kwh') | float(999) < 0.12 }}
actions:
- action: persistent_notification.create
data:
title: "Low electricity price"
notification_id: "price_aware_low_rate"
message: >
Retail import price is currently
{{ states('sensor.retail_import_price_gbp_kwh') }} GBP/kWh.
Verify the appliance is ready and its approved controls
before starting a flexible load.The repeated 15-minute trigger is not an instruction to switch at every 15-minute boundary; it only refreshes the alert when the rate is already cheap and the helper is enabled. The numeric_state trigger reacts when the threshold is crossed, so pairing it with a periodic trigger avoids missing the cheap condition after a restart. If the sensor becomes unavailable, the explicit numeric validity checks prevent a bogus £0 rate from triggering the alert. Where possible, also check a separate last successful tariff update or effective-period timestamp supplied by the integration, because a numeric value can be old but still parse as a number.
Why repeated commands and minimum on/off times matter
A naive controller watches an import/export sensor and switches whenever its power crosses zero. In a house where clouds repeatedly pass over the panels, that can trigger dozens of on/off requests in an hour. A large immersion heater may chatter through contactors, a compressor may be subject to anti-short-cycle restrictions, and an EV may repeatedly wake up or stop. Some devices have their own dwell timers; Home Assistant should not rely on discovering these by accident.
Use distinct start and stop thresholds (hysteresis), a minimum continuous period, a limit on commands per hour, and a lockout after hardware faults. For a heat pump, prefer the manufacturer’s heating/DHW programme and weather compensation; avoid directly controlling compressor power or safety-critical pumps. For an EV, rely on the wallbox’s built-in current and load-management protections and respect its minimum operating current and ramp limits. If the vendor API rejects an action, show it as rejected rather than assuming the last command succeeded.
| Control guard | Illustrative configuration | Purpose | Warning |
|---|---|---|---|
| Price hysteresis | Start below 12p, stop above 17p | Avoid switching around one noisy threshold | Price alone should not stop a device mid-critical cycle |
| Surplus stability | Sustained positive export 2–5 minutes | Reduce cloud-induced toggling | Seconds-to-minutes values depend on actual controller |
| Minimum on-time | Equipment-approved value | Reduce cycling | Never override manufacturer safety timing |
| Command rate limit | Device API documented limit | Avoid vendor bans and conflicting jobs | Limits change by model/API |
| Ready-by buffer | Extra planning time beyond minimum run | Meet practical deadline | Battery and EV charging rate vary |
| Max simultaneously active loads | Respect whole-home available capacity | Avoid overload | Not a substitute for certified protective hardware |
| Manual stop | Retained until owner resumes control | Preserve household agency | Do not silently auto-reset on refresh |
Solar surplus control: power measurements and export opportunity cost
Solar surplus is not simply “PV power minus EV power”. A safe load scheduler needs net import/export at the grid connection and the capacity of each protected circuit. In a property with a home battery, increased EV load can cause the battery to discharge even when the original dashboard showed export. If the intention is to avoid battery depletion, use supported inverter or charger behaviour to preserve the reserve, and verify it using measured battery flows. The site meter should remain the primary reference for total export rather than adding overlapping component meters that double count energy.
Consider 2.8 kW measured export, a 2.4 kW approved immersion diverter and a battery that may absorb additional solar. The instantaneous gross surplus is not necessarily 2.8 kW available for a new load after all control changes; the battery management system may change its operating mode. Even where there is genuine export, diverting 1 kWh from a 5p/kWh export agreement to an immersion heater has a 5p opportunity cost. Buying that kWh overnight for 8p implies a theoretical 3p/kWh advantage to using surplus, before diverter losses, alternative heat-pump efficiency and storage losses.
If a heat pump can deliver hot water at a suitable seasonal COP of 2.5, one kWh of electrical input produces approximately 2.5 kWh of heat under the chosen measurement boundary. An immersion heater produces roughly 1 kWh of heat per kWh electrical input. A direct comparison of 5p solar export value and 8p grid price is therefore insufficient. For 2.5 kWh of useful heat, the heat pump would hypothetically need 1.0 kWh of 8p grid electricity, while an immersion element would consume 2.5 kWh of 5p foregone export worth 12.5p. This simplified case favours the heat pump at 8p, assuming that COP and those tariff conditions actually apply. Real cylinder losses, compressor starts and DHW modes modify the result.
| Heating choice for 2.5 kWh useful heat | Electrical input | Marginal energy value | Illustrative cost |
|---|---|---|---|
| Immersion from exportable PV | 2.5 kWh | 5p/kWh export forgone | 12.5p |
| Heat pump from 8p overnight grid, COP 2.5 | 1.0 kWh | 8p/kWh import | 8.0p |
| Immersion from 8p overnight grid | 2.5 kWh | 8p/kWh import | 20.0p |
| Heat pump from PV, COP 2.5 | 1.0 kWh | 5p/kWh export forgone | 5.0p |
These calculations use deliberately simple, illustrative values. A heat pump’s real COP in domestic-hot-water mode can be lower than its space-heating COP, and a PV diverter may have minimum-power behaviour. The correct choice depends on the water-temperature target, manufacturer-approved modes, hourly export value and system energy balance. Read solar surplus automation for hot water for hardware boundaries and solar surplus EV charging for charger control architectures.
Hot-water cylinder scheduling: energy capacity, comfort and hygiene
A cylinder stores thermal energy, not electricity. Nominal cylinder volume does not equal a perfectly mixed volume at a uniform useful temperature. A rough energy estimate for water is 0.001163 kWh per litre per kelvin. Raising 180 litres of water by 20°C therefore requires about 180 × 20 × 0.001163 = 4.19 kWh of useful heat, excluding standing losses, stratification and heat-source inefficiencies. Heating it with a 3 kW resistance element ideally needs approximately 1.4 hours; a heat pump with 2 kW delivered thermal output ideally needs about 2.1 hours. The heat pump’s electrical draw would be less than thermal output by the applicable COP, but its recovery duration might differ.
The controller should maintain a minimum usable reserve or approved reheating schedule even when prices are high. The cylinder thermostat, independent over-temperature cut-out, expansion/pressure protection and any manufacturer-required hygiene programme must remain active regardless of Home Assistant status. Public-health guidance on Legionella varies with installation type, vulnerability, jurisdiction and manufacturer. Do not replace a required heating and storage-temperature regime with an arbitrary “once a week to 60°C” internet rule. An installer or responsible competent person should assess the actual system, including scalding risk and any thermostatic mixing valves.
Home Assistant is valuable for observing hot-water performance: record electricity during each recovery, water temperature at an appropriate sensor location, time since the last successful heat cycle and any authorised DHW mode flag. A single sensor halfway up a stratified cylinder does not necessarily measure safe storage conditions throughout. Where an approved controller exposes a request for additional heating, Home Assistant may request it during cheap hours while leaving all safety limits intact; that interface is product-specific and cannot be replaced with a generic wiring recipe.
| Hot-water control issue | Monitoring evidence | Safe design response |
|---|---|---|
| Occupants run out of water | Use/temperature drop before usual shower time | Move approved DHW window earlier or increase available stored heat |
| Overheating risk | Independent thermostat/high-limit fault | Controller protection must remain hardwired and autonomous |
| Legionella control | Manufacturer hygiene routine and actual achieved temperatures | Follow documented scheme and competent professional advice |
| Cold snap raises heat demand | Longer recovery time, changed COP | Allow deadline margin; do not overrule heat source interlocks |
| Solar PV unexpectedly low | Site export does not reach planned surplus | Use an approved backup schedule |
| HA server unavailable | Missing schedule requests and logs | Native hot-water programme remains functional |
| Price feed stale | No fresh valid rate series | Complete essential hot-water reheating anyway |
Appliances are different: a smart plug does not provide remote-start logic
A dishwasher, washer or tumble dryer is not equivalent to an EV charger. Many appliances must be physically loaded, their door closed, programme selected and remote-start permission enabled on the panel. Some permit delayed start on the device; some vendor-connected models permit remote activation subject to safety conditions; others cannot legally or reliably be started remotely. The absence of remote-start control is a genuine product limitation, not a Home Assistant configuration problem.
Never assume cutting and restoring mains power will make an appliance begin a programme. Some models resume after an outage, others cancel or enter an error state, and others should not be unattended for safety reasons. Do not defeat lid/door interlocks, manually short control contacts, or adapt a generic mains plug to loads beyond its rating. Heating appliances, especially tumble dryers, add fire-risk considerations. Follow manufacturer guidance about unattended operation, cleaning, ventilation and filters before planning any autonomous start.
For models offering a documented delayed-start feature, the simplest arrangement is often to load the appliance, set a native completion deadline and let its own controller manage the cycle. Home Assistant can alert the owner when prices are favourable and record measured consumption; an approved manufacturer integration can sometimes issue or adjust a remote-start command when the device is armed. The automation should detect “not ready” and avoid silently claiming savings from a cycle that never ran.
| Appliance state | Meaning | Appropriate price-aware action |
|---|---|---|
| Off / door open | Not armed for a programme | No remote-start command; notify user if useful |
| Loaded and native delay timer set | Manufacturer has accepted future start | Do not compete with the appliance timer |
| Remote start enabled (vendor documented) | Supported command path may exist | Use only the documented vendor integration |
| Running | Cycle currently under way | Avoid interruption purely to save pennies |
| Completed | Programme ended | Measure actual energy and record completion |
| Unavailable/cloud offline | Cannot confirm readiness or status | Use native programme; stop remote assumptions |
Prioritise devices when cheap windows overlap
Three flexible loads can compete for the same low-price hour. A wallbox limited to 7 kW, a 3 kW immersion element and a 2 kW appliance could imply 12 kW of concurrent demand, before the rest of the household. Actual electrical limits depend on phase allocation, diversity, import capacity and protective hardware. Home Assistant may sequence loads to reduce the peak but must not act as the sole overload-protection mechanism. Manufacturer-certified charger load management and correctly designed circuits remain responsible for electrical safety.
Use a priority ladder based on consequences. First satisfy safety-critical and essential comfort requirements. Next respect fixed deadlines such as EV departure or mandatory hot-water availability. Then optimise optional flexible loads, potentially favouring appliances with shorter cycle duration. If a dynamic price spike occurs after charging has started, only pause equipment where safe and supported. A half-finished dishwasher or unnecessary heat-pump stop is not equivalent to deferring an EV that still has many spare hours before departure.
| Priority | Example constraint | Scheduling principle | Owner override |
|---|---|---|---|
| 1 — equipment protections | Supply and temperature limits | Never traded against tariff price | Cannot disable via automation |
| 2 — essential completion | Hot water by morning; EV by departure | Start early enough with margin | Finish now |
| 3 — household restrictions | Quiet hours, occupants and safe operating windows | Exclude prohibited intervals | Allow/disallow by deliberate setting |
| 4 — price | Retail cost and export opportunity | Minimise cost within valid windows | Disable optimisation |
| 5 — convenience | Notifications, dashboard visibility | Report intent and result | Manual scheduling |
A practical six-hour schedule: EV, cylinder and dishwasher
Imagine a home on a fictional electricity tariff from midnight to 06:00 with one notably expensive interval. The EV needs 14 kWh at the wall and accepts 7 kW, an approved cylinder controller needs 3 kWh electricity at 3 kW, and the dishwasher needs 1.2 kWh over a vendor-managed 90-minute programme. The main supply arrangement is assumed to permit EV charging plus one smaller load only after a qualified installer has confirmed the available capacity. This is a scheduling illustration, not a specification for electrical protection.
| Window | Import price | Possible scheduled load | Reason |
|---|---|---|---|
| 00:00–01:00 | 10p/kWh | Cylinder approved DHW window (3 kWh) | Hot water ready early |
| 01:00–02:00 | 8p/kWh | EV (7 kWh) | Low-price supported charging |
| 02:00–03:00 | 7p/kWh | EV (7 kWh) | EV reaches energy target |
| 03:00–04:00 | 28p/kWh | No optional new load | High price, all deadlines still feasible |
| 04:00–05:30 | 9p/kWh | Dishwasher native delayed-start cycle | Completes before morning |
| 05:30–06:00 | 12p/kWh | Reserved margin; no scheduled load | Recovery buffer |
At those illustrative rates the EV cost is 7×£0.08 + 7×£0.07 = £1.05. The cylinder costs 3×£0.10 = £0.30. The dishwasher’s 1.2 kWh is simplistically valued at 9p/kWh, or £0.108, though a real cycle draws energy non-uniformly and may cross price boundaries. Combined estimated cost is about £1.46. Compare this with a feasible baseline using the same delivered energy, not a fictitious baseline that runs everything at the most expensive hour. Metering and actual interval allocation should replace assumed appliance energy in the final savings report.
The schedule may also be less expensive if loads overlap safely or if PV is available after sunrise. But supply constraints, departure deadlines, manufacturer schedules and network limits are not flexible assumptions. The right response to insufficient capacity is to adjust the schedule or commissioning design, not to relax electrical limits in an automation.
Time-of-use tariffs versus genuinely dynamic price optimisation
A static cheap window—say 00:30 to 05:30—requires no cloud forecast if the supplier contract guarantees that rate. It may be implemented more reliably in the charger or appliance itself. In contrast, a dynamic tariff can have several separate low-rate intervals and unpredictable daytime spikes. Home Assistant can schedule from the published interval array if the supplier’s data is current and the corresponding command API supports it. Price publication times, effective start and timezones are supplier-specific; build checks around the provider you actually use.
A simple native Home Assistant policy might say: if the vehicle has at least five spare hours before departure, prefer the cheapest eligible rate interval; otherwise schedule the charge immediately enough to guarantee the target. An optimiser such as EMHASS can solve several competing constraints mathematically, but its inputs remain estimates. For one EV on a two-rate tariff, that complexity often brings very little benefit. Compare with our EV charging on dynamic tariffs guide for more detailed deadline and price-interval methods.
Home Assistant example 3: fixed off-peak reminder with a strict time window
The next automation is intentionally a reminder for an owner who already has a native-device timer, not an unauthorised switch command. It only notifies during a known rate window and confirms that the scheduling helper is enabled. The quoted times are fictional; change them to match the electricity contract and account for weekends and holidays where applicable. The device timer should still be verified to finish on time.
automation:
- id: off_peak_check_reminder
alias: Confirm off-peak appliance schedule
mode: single
triggers:
- trigger: time
at: "00:35:00"
conditions:
- condition: state
entity_id: input_boolean.price_automation_enabled
state: "on"
- condition: time
after: "00:30:00"
before: "05:30:00"
actions:
- action: persistent_notification.create
data:
title: "Check native off-peak schedule"
notification_id: "off_peak_schedule"
message: >
Your example cheap-rate period is active. Verify the EV,
water-heating controller or appliance has an approved
schedule and will finish before its deadline.Because the automation only triggers at one fixed time, a Home Assistant restart after 00:35 can cause that day’s reminder to be missed. This is not a serious problem for a non-critical notification, but for actual charge deadlines use an independent device schedule and a repeated reconciliation trigger. A trigger being true is not a continuously monitored condition: Home Assistant evaluates the automation when the trigger fires. Its documentation explicitly distinguishes these behaviours.
Home Assistant example 4: record a valid price boundary without remote switching
Logging the moment a tariff threshold is crossed is useful when testing a price strategy. The snippet below uses a template condition to ignore invalid price states and logs an event rather than commanding hardware. It also demonstrates repeated evaluation rather than depending only on a crossing event. A production controller should additionally compare price feed timestamps and validate that the rate applies to the current settlement interval.
automation:
- id: price_boundary_audit
alias: Log effective cheap-rate intervals
mode: single
triggers:
- trigger: time_pattern
minutes: "/15"
actions:
- choose:
- conditions:
- condition: template
value_template: >
{{ is_number(states('sensor.retail_import_price_gbp_kwh'))
and states('sensor.retail_import_price_gbp_kwh') | float(999) <= 0.10 }}
sequence:
- action: logbook.log
data:
name: Price scheduling
message: >
Example low-price interval detected at
{{ now().isoformat() }}.
entity_id: input_boolean.price_automation_enabledIn the actual Home Assistant installation, test entity names using Developer Tools → States, check the automation trace and ensure the price sensor delivers retail £/kWh rather than p/kWh. A threshold of 0.10 in a pounds-denominated sensor means ten pence per kWh; the same numeric constant in a pence sensor would mean one tenth of a penny. Unit errors can be more costly than any theoretical scheduling improvement.
Working with a supported device controller: the actuator is deliberately product-specific
Home Assistant examples on the internet often show switch.turn_on pointed at a fictional switch.ev_charger and imply the result is generic. It is not. On one charger the entity may mean “allow charging”, on another it may mean mains power, and some chargers expose no such switch. Equivalent differences exist between a hot-water controller’s boost action, a heat pump’s DHW setpoint and a heater contactor. Confusing them can damage equipment or defeat a locally configured schedule.
After completing the read-only phase, implement actuation in the device’s own integration or an installer-approved interface with an explicit contract: the exact action name, allowed state transitions, maximum requests, what happens after restart, which safety functions remain independent, and what a rejected command looks like. Keep a single owner of the intended schedule. Build logging around the entity that reports actual operation instead of assuming success merely because the action call returned without an exception.
| Actuation question | Good evidence | When to stop and investigate |
|---|---|---|
| Is the command supported? | Official model-specific control/API documentation | Only an unofficial guessed entity appears |
| Will it survive disconnection? | Native stored timer or documented offline behaviour | Cloud call is necessary every few minutes |
| Can the device refuse? | Explicit response or status transition | Automation interprets silence as successful start |
| Does safety remain local? | Certified electrical/hot-water controls unaffected | HA relay bypasses a thermostat or load protection |
| Can manual operation take over? | Visible disable/finish-now function | Software immediately reverses the owner |
| Can the operation be measured? | Metered kWh or real cycle status | Savings depend only on planned state |
| Who handles a missed deadline? | Device timer/fallback and owner notification | Automation simply waits for another cheap period |
Input data integrity: price timestamps, solar meters and unavailable values
Tariff-aware automation is only as reliable as its inputs. All hourly or quarter-hourly readings should be associated with an explicit start time and duration. The clock changes during daylight-saving transitions make “24 hourly values per day” an unsafe assumption for a local billing day: it may contain 23 or 25 hourly periods, or a corresponding different number of quarter-hour intervals. Prefer timezone-aware timestamps over comparing string-formatted clock hours, particularly when carrying a charge plan through a DST change.
Verify that grid import is a measured cumulative kWh stream, not an integral of a noisy instantaneous reading without sufficient sampling. Confirm import and export directions against the utility meter and bill. Detect source unavailability, zero timestamps, unknown entities and implausibly large values. Where tariffs are supplier-specific, request an all-in import price if one is supplied; when only the spot-market component is available, add documented contract charges using correct units and taxes or label the estimate as wholesale-only.
| Validation test | Pass condition | Failure action |
|---|---|---|
| Price numeric | Finite, correct unit and credible range | Do not optimise; keep fallback schedule |
| Price timestamp | Interval effective now and feed not stale | Use known fixed rate or alert |
| Time series completeness | All required slots before deadline exist | Use conservative earlier schedule |
| Grid energy reading | Monotonic where expected; correct import/export polarity | Suspend energy-based claims |
| Power reading | Fresh and plausible compared with capacity | Do not calculate surplus-driven start |
| Device ready | Vendor status supports this action | Notify; do not energise |
| Manual override | Off means off until user changes it | Never auto-re-enable after an error |
| Fallback completion | Known deadline still feasible | Prioritise readiness over savings |
How to assess actual savings instead of projected savings
For each flexible device, compare two feasible schedules under the same realised tariff and service requirement. The first is the original fixed timer or normal household routine. The second is the new price-aware policy, with the same amount of useful output—EV wall energy, delivered hot water or completed programme—and any conversion losses. Evaluate imported electricity at the rate for each interval and exported electricity at the applicable export rate. This avoids rewarding a controller that merely consumed less energy because the EV was undercharged or a hot-water cylinder ended cold.
For a single load, a simplified period cost is sum(imported_kWh_interval × import_price_interval) − sum(exported_kWh_interval × export_value_interval). When comparing two policies, subtract total net energy value and account for additional device or battery use if material. Treat battery cycle degradation or inconvenience separately rather than presenting a falsely precise fraction of a penny. Retain the utility bill as the reconciliation reference; monitoring can reasonably disagree with billing because of CT accuracy, interval offsets, measurement boundaries or tariff adjustments.
| Measurement | Baseline schedule | Price-aware schedule | Evidence required |
|---|---|---|---|
| EV energy delivered | 26.5 kWh | 26.7 kWh | Comparable wall energy and vehicle readiness |
| Cost of EV import | £5.83 illustrative | £3.20 illustrative | Actual interval prices and grid import |
| Hot-water availability | Ready at 07:00 | Ready at 07:00 | Temperature/recovery proof |
| Appliance cycle | Completed by 08:00 | Completed by 08:00 | Actual programme-complete state |
| Missed / overridden runs | Counted | Counted | Owner intervention log |
| Connection and API failures | Recorded | Recorded | Availability / rejection events |
In the illustrative EV comparison, £5.83 − £3.20 = £2.63 per comparable charge. If such conditions occurred 80 times a year, the ideal arithmetic is £210.40 annually, but only if both schedules deliver the same required charge, the rate differential actually recurs and no hidden costs or losses offset it. A single dramatic cheap-day result should not become a guaranteed annual saving in a buying guide. Track at least several billing cycles where practical and identify seasonal differences.
Is a dedicated optimiser such as EMHASS worth adding?
For a homeowner who simply charges an EV every night between 00:30 and 05:30 and does not have a battery, a native charger timer may already solve the problem. For a house with a dynamic retail tariff, PV, battery, two EVs and hot water, there may be multiple simultaneous decisions and constraints. An optimiser can help create a cost-minimising plan, but only if each controllable device can accept the relevant commands and the model reflects true physical limitations.
EMHASS and similar tools do not automatically become electrical safety controllers. They calculate intended schedules and power targets; a separate approved execution layer must implement them, with minimum run times, limits, manual overrides and validity checks. No optimiser can guarantee that a manufacturer cloud service remains available or that a washing machine accepts remote start. For a deeper platform comparison see the related guide on Home Assistant versus evcc and inverter applications when it becomes available on esp32AliExpress price.co.uk; for now the key principle is to establish a trustworthy native-rule baseline before adding a solver.
| Household situation | Recommended first approach | When complexity could pay |
|---|---|---|
| One EV with fixed cheap-rate tariff | Charger/vehicle-native schedule | Rarely necessary unless special constraints |
| EV with dynamic prices and fixed departure | Supported tariff-aware HA schedule plus charger fallback | Price spread and feasible hour count vary significantly |
| Solar PV and immersion diverter | Approved diverter or manufacturer controller | Variable export value and several flexible demands |
| PV + home battery + two EVs | Metering and clear priority scheme | Competing deadlines and dynamic intervals |
| A few smart appliances | Built-in delayed-start and notifications | Vendor remote start is robust and supported |
| Heat pump and mixed heating zones | Manufacturer weather-compensated controls | Validated ability to shift demand without COP penalty |
Troubleshooting: an automation that looks correct but does the wrong thing
| Symptom | Likely explanation | Diagnosis | Correction |
|---|---|---|---|
| Price shows 0 while feed unavailable | Template defaulted to zero | Inspect raw entity and availability | Mark state unavailable; avoid using 0 fallback |
| EV did not finish before departure | Wrong wall kWh, power or latest start | Compare wall meter with expected duration | Increase margin; use native departure guarantee |
| EV and hot water both start on cheap tariff | Independent automations own load schedule | Check automation traces and supply headroom | Centralise scheduling and preserve hardware protections |
| Dashboard says appliance started but it did not | Action sent, but vendor rejected remote start | Compare command response with real programme state | Require explicit armed state and completion feedback |
| Cycle repeats every few minutes | Price/surplus threshold without hysteresis | Count command events and state changes | Equipment-approved dwell time and distinct thresholds |
| Hot water colder after optimisation | Shifted too far or underestimated recovery | Temperature profile and reheating duration | Restore native conservative hot-water schedule |
| Unexpected grid import during solar mode | Battery or other load changed dispatch | Site meter and battery flow history | Use correct import boundary and priority |
| Schedule misfires on clock change | Naive local hour timestamps | Compare UTC timestamps and tariff effective slots | Use timezone-aware interval alignment |
| Automation remains silent after restart | Trigger crossing was missed | Trace trigger and last run | Reconciliation periodic trigger or device fallback |
| Bill savings do not match dashboard | Wholesale vs retail, fees or inaccurate meter | Compare invoice and interval cost model | Use contractual rates and correct boundaries |
The Home Assistant trigger documentation warns that state and template triggers represent change events and not continuous enforcement. A periodic reconciliation mechanism helps after restarts, but timer completion events that occur while Home Assistant is down are not necessarily replayed on start-up. The Timer integration documentation explicitly notes that a restored timer can expire during downtime without firing the missed finish automation. Never make a critical deadline depend on such an event alone.
Failure modes: what should happen during outages?
Test four failures separately: internet outage, Home Assistant restart, energy-meter failure and vendor device unavailability. They should not all be handled by the same “try again” loop. A cloud-only car interface may need internet to change its target; a charger with a built-in schedule may continue independently. A cylinder must remain thermally protected even if all automation equipment has lost power. A washer that is already running should normally complete through its own programme rather than be interrupted by a stale price command.
In a house with battery storage, reserve control and export settings remain responsibilities of the inverter and its certified BMS. Home Assistant should not assume that reading the battery SoC authorises overriding inverter modes. When an EV charger supports dynamic load balancing, it should retain independent site-current protection even if HA’s energy sensor is stale. Any integration that lacks documented failure behaviour should start in monitoring-only mode until the risk is understood.
| Failure | EV response | Hot-water response | Appliance response |
|---|---|---|---|
| Internet down | Native charger timer remains available where supported | Native tank/hot-water schedule operates | Native delayed start and cycle only |
| HA restarted | Re-check target and deadline; avoid duplicate commands | Do not override protected controller | No forced power cut to resume |
| Tariff series missing | Choose known safe/normal completion schedule | Meet required heating schedule regardless of price | Notify and use appliance delay timer |
| Energy meterAliExpress price stale | Do not infer PV surplus or spare import capacity | Do not claim surplus; use approved controller | No energy-based remote start |
| Vendor cloud unavailable | Manual or local approved charging | Independent thermostat/hygiene protection | No remote-start command until supported |
| Household override | User decision remains active | User can request approved boost | Owner chooses native programme |
Commissioning a price-aware installation: the 20-point checklist
- Document electricity contract: capture correct import rate, export rate, standing charge and tax treatment.
- Verify supplier interval definition: 15-minute/30-minute/hourly and daylight-saving time handling.
- Match units: pounds versus pence, kilowatts versus kilowatt-hours, UTC versus local timestamps.
- Check source freshness: record publication time and valid-to timestamp for each tariff series.
- Prove meter polarity: compare grid import/export and PV generation with physical meter readings.
- Record electrical limits: have a competent installer confirm usable supply and phase allocation.
- Identify approved control path: exact supported charger, heating controller and appliance API/model.
- Preserve independent protections: EVSE load management, heater high limit and appliance interlocks.
- Assign a single scheduling owner: avoid fighting between HA, inverter, car and wallbox timers.
- Define the useful-output requirement: EV wall energy, hot-water readiness and appliance completion.
- Define deadlines: actual departure, occupancy and safe running windows.
- Set a buffer: take realistic charge rate, recovery time, network failures and price uncertainty into account.
- Provide manual override: finish now, disable price control and inspect the planned reason.
- Test restart behaviour: restart HA while a cheap window is active and while a load is running.
- Test WAN outage: confirm the native equipment can still finish the important task.
- Test sensor failure: ensure an unavailable rate or meter does not become a false zero.
- Validate command feedback: record real device starts, stops, kWh and completion—not just action calls.
- Test DST and midnight: verify interval indexing and local date changes.
- Compare a real baseline: equal energy/service against the same tariff schedule.
- Back up configuration: preserve YAML, automation traces, API versions and rollback instructions.
A commissioning trial should begin in shadow mode: calculate the proposed schedule and send notifications only, while devices remain on their known-safe native schedules. Compare whether the proposed plan would have been feasible and cheaper. Next, enable one supported device at a time, with installer-approved settings and explicit rollback. Only expand control when the observed results prove reliability. This staged approach often exposes wrong price units or unreachable device APIs before they can create missed EV charging or unpleasant morning showers.
Frequently asked questions
Can Home Assistant automatically charge my EV at the cheapest time?
Yes, where the charger or vehicle exposes a supported scheduling interface and the tariff feed is reliable. Start by calculating the required wall energy and latest feasible charging window. Retain the charger’s native deadline or approved fallback; a cheap-rate threshold by itself is insufficient.
Do I need a dynamic electricity tariff to benefit?
No. A recurring off-peak rate can be scheduled with a charger-native timer. Dynamic rates offer more opportunities to choose intervals, but also increase the need to validate price data, timestamps and missed-deadline behaviour.
Does Nord Pool provide the retail price I actually pay?
Not necessarily. Nord Pool data are wholesale market prices; your supplier may add margin, fees, tax and other charges, or offer a contract not directly tied to the spot series. Use your contract’s effective import rate for monetary comparisons.
Can I use a smart plug to start a dishwasher overnight?
Only if the appliance manufacturer explicitly supports the desired operation and the switching arrangement is electrically and operationally appropriate. Cutting and restoring power is not a generic or recommended substitute for a documented remote-start feature.
Can Home Assistant safely control a 3 kW immersion heater?
It can request heating through a manufacturer-approved, correctly rated installed controller. It must not replace or bypass high-limit protection, suitable switching equipment or hot-water safety provisions. Ask a qualified installer to specify the electrical arrangement.
What happens if the internet goes down during a cheap period?
A locally stored device schedule may continue; a cloud-only remote-control path may not. Design critical deadlines around the manufacturer’s own supported operation, and make Home Assistant price optimisation optional rather than the only route to hot water or EV charging.
What does a negative electricity price mean for appliances?
It can mean the market energy component is negative, but it does not necessarily mean your final retail cost is negative. Check all contract adders, import charges, export rules and whether the negative value is valid for that settlement period.
Should I always use the cheapest 15-minute intervals?
Not if frequent starting and stopping harms comfort, equipment operation, completion likelihood or API reliability. A realistic schedule incorporates continuous-run restrictions, deadlines, minimum device power and command-rate limits.
How can I stop price automation temporarily?
Use a clearly named input_boolean helper or native device control. An explicit manual override should persist until the owner intentionally re-enables optimisation; do not let a periodic update immediately reverse the user.
What if a car is charging but the reported battery percentage is stale?
Prefer metered wall energy for cost and delivery calculations, use the latest validated car state only when current, and leave a wider time margin. Do not claim the car will be ready based on an old SOC reading.
Should I prefer a heat pump or immersion element for solar hot water?
Compare useful heat delivered per electrical kWh, export opportunity cost, the heat pump’s actual domestic-hot-water COP, recovery time and manufacturer constraints. The cheapest grid or solar source for one kWh of electricity is not automatically the cheapest source of one kWh of hot water.
How do I avoid using the home battery to charge the EV unintentionally?
Measure site import/export and battery flow, and use approved inverter or charger operating modes. A surplus sensor alone cannot guarantee battery discharge will not rise when a new load starts.
Can EMHASS replace these Home Assistant rules?
It can optimise a schedule when the constraints and inputs are correctly modelled. It does not independently provide certified electrical protection or create unsupported device APIs. Keep the same execution safety, freshness checks, manual overrides and completion monitoring.
How much money can I realistically save?
Measure avoided cost against an equal-service baseline. The result depends on annual flexible kWh, contract price spreads, exported solar value, device losses, missed/overridden runs and any subscriptions. Do not extrapolate a single cheap day into guaranteed annual savings.
Why did my automation fail on the daylight-saving change?
It may have indexed local clock hours instead of timezone-aware tariff intervals, causing duplicated or missing apparent times. Use explicit effective timestamps and validate boundary behaviour on the 23- and 25-hour days.
How do I prove a schedule actually happened?
Record commands, vendor acknowledgement, measured electricity, actual start/stop times and the completed outcome. Compare the resulting cost with the supplier bill. A scheduled state is not the same as delivered service.
Verdict: cheapest is only useful if the task finishes safely
The best price-aware Home Assistant automation is not the one with the most templates or the lowest theoretical bill. It is the one that reliably finishes the required job, respects independent device protections, survives stale sensors and outages, and produces measurable net savings. Use charger-native timers for predictable off-peak EV charging; use approved hot-water controls for cylinder scheduling; and use manufacturer-approved delayed start for appliances. Let Home Assistant coordinate prices, deadlines and evidence while keeping the equipment’s own safety logic authoritative.
Build one load at a time: first verify price and metering, then run a read-only shadow schedule, finally enable supported control with manual overrides and a clear fallback. Compare the actual interval-weighted cost to a feasible baseline, including export opportunity value where applicable. If those measurements show no meaningful gain, simpler automation is the better engineering choice.
Sources, further reading and related esp32.co.uk guides
- Home Assistant: automation triggers and change-event behaviour — documentation for time and state triggers.
- Home Assistant: automation conditions — evaluation of state, time and template conditions.
- Home Assistant: Utility Meter — tariff-aware energy tracking and tariff-select entities.
- Home Assistant: Input Boolean — manual enable/disable toggles and restart behaviour.
- Home Assistant: Input Datetime — deadline helpers and time-trigger support.
- Home Assistant: Timer — restore behaviour and events missed during downtime.
- Home Assistant: Nord Pool — spot market prices and integration scope.
- ESP32.co.uk: Home Assistant electricity tariff sensors — retail rates, time-of-use models and dynamic prices.
- ESP32.co.uk: Charging an EV on dynamic tariffs — departure deadlines and EV charging logic.
- ESP32.co.uk: Solar surplus automation for hot water — immersion diverter and load design.
- ESP32.co.uk: Solar surplus EV charging — meters, EVSE constraints and charge priorities.
- ESP32.co.uk: Energy Dashboard metering entities — correct import/export measurement.
- ESP32.co.uk: Verify Home Assistant energy data against your utility bill — financial validation.
Editorial note: Product interfaces, local-control capabilities, tariffs and Home Assistant action schemas may change. The YAML examples are educational, monitoring/notification-only patterns that require entity substitution and testing in the installed Home Assistant version. The article deliberately avoids giving universal mains wiring or bypass instructions; a qualified professional should approve fixed electrical and hot-water control installations.