Quick Summary (TL;DR)
Home battery dispatch is the decision about when a battery should charge, discharge or preserve energy. Home Assistant can be an excellent supervisor for that decision, but it should not replace the inverter's certified grid controls, the battery management system (BMS), the manufacturer's minimum state-of-charge (SOC) protections or backup switching. In most houses, the safest first improvement is to understand the built-in inverter mode, set a sensible manufacturer-supported backup reserve, measure grid import/export correctly and compare the result with a simple baseline. Advanced forecasts are useful only when a material amount of flexible energy remains after losses and constraints.
Practical recommendation: choose a supported, documented control interface before designing any automation. Use your inverter's native self-consumption, time-of-use or backup modes for the underlying safety behaviour. Use Home Assistant to record SOC, metered energy, tariff periods and PV forecasts; run proposed dispatch decisions in advisory-only mode; and promote only explicitly supported, reversible setpoints after a qualified commissioning review. Neither an arbitrary Modbus register nor a community-made entity should be assumed safe to write to merely because it is visible in a dashboard.
This guide works through reserve planning, realistic charge/discharge limits, forecast confidence, battery ageing, import-cap constraints, EV interaction, worked cost scenarios, communications failures and a Home Assistant dashboard. All prices and example loads are illustrative—not live tariffs, installation quotations or guarantees of savings. The correct control permissions depend on your exact inverter, battery, firmware, electricity contract, grid-connection conditions and local rules.
What Battery Dispatch Actually Means
A home battery does not have a single economically optimal behaviour in every situation. It might be asked to absorb excess solar generation at lunchtime, avoid buying electricity in an expensive evening period, preserve a backup reserve during a storm, charge from the grid on an unusually cheap night, or reduce a peak import period. The same kilowatt-hour of battery capacity cannot be committed simultaneously to every purpose. A controller therefore needs an order of priorities and an honest model of how much energy is usable.
Three decision layers should remain separate. Electrical and battery safety belongs to the certified inverter, BMS and protective devices. Operational dispatch chooses among supported modes and limits within that safe envelope. Economic optimisation compares candidate operating schedules using forecasts, tariffs, battery efficiency and opportunity cost. Home Assistant can make the last two layers visible, but it has no authority to waive the first.
It helps to distinguish dispatch from a normal monitoring dashboard. A dashboard that shows 40% SOC and 1.8 kW discharge is observing an outcome. A dispatch plan that asks to hold 30% reserve until 18:00 is making an operational request. A register write that attempts to force 4 kW export is a control action with grid, warranty and safety consequences. Those should never be treated as interchangeable features.
| Layer | Typical information or action | Owner of the function | Appropriate failure behaviour |
|---|---|---|---|
| Battery and inverter protection | Cell voltage, temperature, current, isolation, grid-code limits | BMS/inverter and installed protection | Protection remains active without Home Assistant |
| Certified grid and backup operation | Anti-islanding, backup transfer, export limits, power quality | Approved equipment and installer configuration | Revert to compliant device-native operation |
| Dispatch preferences | Self-consumption, scheduled charge, reserve target, export permission | Supported manufacturer controls | Restore a documented default or stop supervisory writes |
| Home Assistant monitoring | SOC, power, price, grid flow, forecast and alarm status | Monitoring integration and local storage | Display unavailable/stale rather than inventing zero |
| External optimiser | Chooses low-cost periods subject to constraints | Optional software such as EMHASS or a supported controller | Fall back to simpler native schedule |
Five meanings of 'battery control'
Marketing descriptions often say an inverter has a local API or a Home Assistant integration. That statement by itself does not reveal whether it can actually accept a dispatch schedule. The interface may expose only measurements, allow a backup-reserve adjustment, permit switching among predefined operating modes, provide power limits, or support a full externally commanded ESS loop. Each level is a major step in responsibility and risk.
An interface that can report SOC but cannot alter charging is useful for forecasting and diagnostics. A supported reserve setting may be all that is needed for many homes. Explicit charge/discharge power control is not necessarily better: if two controllers send contradictory commands, battery behaviour can become less predictable. An installer should document which system is the final authority and which third-party functions are approved for that installation.
Start With the Manufacturer's Native Operating Modes
Before building automations, record the battery's existing configuration. Photograph or export the inverter settings and obtain the latest model-specific manuals. Note the currently commissioned operating mode, backup reserve, permitted grid charging, export permissions, CT or meter arrangement and any automatic storm or utility controls. Check whether a supplier or virtual power plant (VPP) contract has authority over charging. A third-party schedule may be blocked, overridden or contractually prohibited.
The baseline should be measured for at least several representative days. Record morning SOC, solar charge, evening discharge, overnight grid consumption and import/export energy. If you do not know how the unmodified installation behaves, you cannot demonstrate that external automation made it better. A week's data during mild weather may not represent a dark winter week, so label the baseline seasonally.
| Native mode | Usually intended behaviour | Good candidate when | Typical limitation |
|---|---|---|---|
| Self-consumption | Store surplus PV, discharge into household demand | Export payments are low relative to imports | May not respond to dynamic price spreads |
| Backup-first / higher reserve | Keep a defined fraction for outages | Reliability matters or storms are plausible | Less usable energy for daily arbitrage |
| Time-of-use / scheduled charging | Charge or hold in selected tariff periods | Supplier contract has reliable cheap windows | Timetables can be coarser than changing prices |
| Manufacturer dynamic optimisation | Device/vendor chooses dispatch using forecasts | Supported on exact model and contract | Cloud dependence, subscriptions and opaque decisions vary |
| Export or grid services mode | Discharge to support export or VPP programme | Installer and contract explicitly permit it | Tariff eligibility, cycling and network restrictions matter |
| External supervisory setpoints | Third-party controller adjusts supported parameters | Clear documented controls and a tested fallback exist | More configuration, failure modes and liability |
Avoid the 'two captains' problem. Do not operate the vendor's automatic TOU controller, an EMHASS schedule, a Home Assistant reserve automation and a tariff-provider VPP schedule as independent masters. One controller should own each adjustable setpoint; others can supply forecasts, monitoring or supervisory constraints. Configure an explicit relinquish-control action when the external controller is disabled.
Which Systems Can Home Assistant Actually Control?
Support is model-, firmware-, region- and integration-specific. Home Assistant's battery energy guide concerns measurement of energy entering and leaving storage; that does not imply write access. Check entities after integration and inspect the vendor's current commissioning manual before assuming an entity will accept a charging command.
Victron GX, Venus OS and ESS
Victron is useful for explaining a documented external-control architecture. The official Victron GX Home Assistant integration connects to GX devices over MQTT for monitoring and supported controls. Separately, Victron documents ESS Mode 2 and Mode 3, including supported grid-power setpoints and charging constraints. Mode 2 retains the ESS control loop while permitting specified external adjustments; Mode 3 gives the external controller much greater responsibility and is not an appropriate casual smart-home experiment.
A particularly important technical detail is that register maps are version-dependent. Victron's documentation states that on Venus OS 3.50 and later, the recommended 32-bit grid setpoint uses registers 2716–2717 rather than the older 2700/2703 path. The article deliberately provides no generic write-to-register example, because copying one without confirming device IDs, register representation, grid-code permissions and commissioned ESS mode would be irresponsible. Victron also explains that protections such as sustain mode can override requested behaviour. An external controller must read the resulting actual power, not assume that a request was executed.
Victron's Dynamic ESS may already account for electricity prices and battery efficiency. Compare it against a simple TOU schedule before adding a separate optimiser. Verify any mutual exclusions between native Dynamic ESS and third-party dispatch. Further reading: the existing Victron GX integration comparison on esp32AliExpress price.co.uk.
Tesla Powerwall
The native Home Assistant Tesla Powerwall integration exposes local power-flow and SOC information, but it should not be described as an unrestricted local dispatcher. Powerwall 3 local API support is more limited than Powerwall 2 in the official integration documentation. Tesla's Backup Reserve guidance explains the homeowner's backup setting through the Tesla app. Other connected services may expose more controls, potentially with subscriptions or cloud/authorisation dependencies, but those require their own security and compatibility evaluation.
Where Tesla's operating modes or grid-services participation govern the battery, treat Home Assistant as monitoring unless the chosen authorised integration explicitly supports the desired operation for the specific site. Do not represent a Home Assistant sensor named 'Backup Reserve' as proof that the standard integration supports editing it.
Enphase IQ batteries
The official Enphase Envoy integration documents battery entities, reserve and storage-mode capabilities for some hardware generations. Crucially, it also warns that particular Envoy firmware versions restrict battery-setting operations through the local REST API. As of the documented Envoy 8.2.4225 limitation, local mode, grid-charge and reserve writes are no longer supported through that path. Therefore a previous version of an automation, or a screenshot of an older entity, does not demonstrate current control support. Monitor by default; use the authorised Enphase app for settings where local controls are restricted.
SolarEdge, hybrid inverters and third-party integrations
The Home Assistant SolarEdge Modbus integration documents locally accessible inverter and meter data and additional supported functionality, but access varies by inverter and commissioning. Some third-party integrations expose extra battery parameters whose own documentation warns that certain controls are based on non-public or reverse-engineered mappings. Such an entity is not automatically an endorsed manufacturer control. For Huawei, Solis, Growatt and other hybrids, compare exact firmware, local gateway, battery model, installation region, installer password requirements and current integration documentation. An inverter advertising 'Modbus TCP' is not enough evidence to build a dispatcher.
| Ecosystem | Monitoring route | Possible dispatch route | Decision before automating |
|---|---|---|---|
| Victron GX / ESS | Native Home Assistant GX MQTT and vendor data | Documented ESS supervisory setpoints in appropriate modes | Confirm ESS mode, Venus OS version, native optimiser and installer setup |
| Tesla Powerwall | Native local Powerwall monitoring | Tesla app/authorised control services; support varies | Do not assume native Powerwall sensor entities are writable |
| Enphase IQ | Official local Envoy integration where supported | Enphase app or supported device/firmware functions | Check documented firmware restrictions on local writes |
| SolarEdge hybrids | Model-supported Modbus/local data | Only documented and authorised controls for exact device | Distinguish supported controls from unofficial community mappings |
| Other hybrid brands | Vendor LAN/cloud, Modbus, inverter gateway | Device-dependent native schedules or supported API | Obtain model and firmware-specific write permissions |
| Generic CT meter and Home Assistant | Grid and circuit measurement | None by itself | A meter is not a battery control interface |
Define the System Boundary Before Calculating Dispatch
Solar panels, battery, hybrid inverter, household loads and grid meter exchange power across different boundaries. If you calculate energy from the wrong boundary you can make a perfectly functioning battery look inefficient. An AC-coupled battery may report inverter AC power; a DC-coupled hybrid may expose PV-side, DC-bus and AC grid quantities. These values are not interchangeable. Decide whether your objective is to minimise metered grid import, retail bill cost, peak contracted import, annual carbon intensity or reserve depletion. Those objectives can conflict.
Use a consistent sign convention. For the examples below, grid import is positive and export is negative; battery discharge to AC is positive and charging from AC is negative. Some vendor systems use the opposite signs. The Home Assistant Energy dashboard usually expects cumulative, separately accounted energy paths, not an instantaneous signed power reading stuffed into an energy entity. In each system document whether 'battery charging energy' means AC input, DC energy into the cells or metered delivered energy.
For a simplified AC-bus system, ignoring measurement error, grid power = household consumption + battery charging power − PV production − battery discharging power, if charging and discharging are represented as separate non-negative quantities. The real topology may include inverter losses, inverter clipping or export constraints. Use a measured grid meter to validate any reconstructed balance, rather than substituting a calculated value for the settlement meter.
| Measurement | Unit | Source priority | Why it matters |
|---|---|---|---|
| Grid import and export | Separate kWh totals plus W | Utility/approved boundary meter | Financial settlement and site limits |
| Battery SOC | % | Inverter/BMS | Reserve and usable energy estimate |
| Battery charge and discharge | W and separate kWh totals | Supported inverter telemetry | Efficiency and requested-vs-actual behaviour |
| PV generation | W and cumulative kWh | PV inverter or approved meter | Forecast validation and surplus estimation |
| Household demand | W and kWh | Proper total-consumption meter | Expected discharge and future load |
| Import/export retail price | Currency/kWh by interval | Actual supplier tariff | Economic objective rather than wholesale proxy |
| Battery alarms, operating mode | Enumerated state | Manufacturer integration | Safety gates and control conflict detection |
| Last successful measurement | Timestamp | Integration/source | Prevent action based on stale data |
SOC Is Not the Same as Available AC Energy
State of charge is a percentage estimate, not a guaranteed number of kilowatt-hours at the household socket. The installed battery may have a manufacturer-defined usable capacity, lower and upper operating bounds, age-related capacity loss, battery-temperature restrictions and inverter efficiency losses. A 10 kWh nominal pack at 50% SOC does not necessarily deliver 5 kWh AC before stopping. The correct capacity comes from the exact product manual and, where available, a measured discharge under comparable conditions.
An illustrative calculation: assume 10 kWh usable at the battery-side convention used in the example, 70% SOC, a chosen 30% reserve and 92% discharge-side conversion efficiency. The nominal energy above reserve is (0.70 − 0.30) × 10 = 4.0 kWh. Estimated AC energy delivered is 4.0 × 0.92 = 3.68 kWh, before accounting for standby losses, extra device limits or the difference between calibrated and reported SOC. If the 10 kWh quoted capacity is already an AC usable-energy rating, do not multiply it by another inverter efficiency: that would double-count losses.
A useful dispatcher therefore operates with at least three distinct quantities: observed SOC, effective protected reserve and estimated AC energy remaining above the reserve. Consider uncertainty: if reported SOC has several percentage points of error and the battery may be cold, reduce the confidently available energy. Avoid tiny dispatch adjustments that rely on spurious precision in the SOC estimate.
Reserve is a planning decision, not just a percentage
A fixed 20% reserve might be appropriate for one household and unacceptable for another. Backup loads, outage duration, available solar recharge, battery size, medical or critical equipment, winter weather and user preference all matter. Some BMS products maintain an inaccessible technical buffer below the user-selected backup reserve. Do not attempt to lower that internal protection through unofficial controls.
Work backwards from an outage scenario. Suppose the desired emergency circuits average 400 W over a six-hour outage and the backup system needs 100 W of self-consumption during operation. Approximate energy requirement is (0.4 + 0.1) kW × 6 h = 3.0 kWh AC. For an illustrative 10 kWh usable battery and 90% discharge efficiency, 3.0/0.90 = 3.33 kWh battery-side, or about 33% of capacity. A user reserve nearer 35–40% might be justified once uncertainty is allowed, assuming the load estimate and backup topology are sound. The actual backup operating mode may have additional constraints and must be checked with the installer.
| Reserve approach | Benefit | Cost or drawback | Suitable when |
|---|---|---|---|
| Fixed moderate reserve | Predictable, easy to audit | Overprotects capacity on some days | Standard self-consumption household |
| Higher storm reserve | Greater outage resilience | More evening imports | Bad-weather periods or vulnerable loads |
| Forecast-informed reserve | Better use of expected PV recharge | Forecast and communication uncertainty | Reliable historical data exists |
| Time-based reserve profile | Protects for morning peak or outage window | Extra schedules to maintain | Predictable household pattern |
| Lowest vendor-permitted reserve | Maximises daily cycling | Reduces backup buffer and can increase cycling | Only where no backup objective and installer approves |
| Manufacturer Dynamic ESS | Device-native optimisation may account for constraints | Less transparent or contract dependent | Supported ecosystem and tariff |
Battery Power Limits: Energy and kW Are Different Problems
A battery that stores 10 kWh is not necessarily capable of providing 10 kW. The discharge power limit may be 2.5, 3.6, 5 or another value depending on inverter, cells, temperature, SOC and grid rules. Charge power can differ from discharge power. A three-phase system may have independent per-phase constraints. A heat pump or EV charger can exceed the battery's instantaneous output even when the battery has plenty of remaining energy.
In a simplified example, a 5 kWh expected evening load at an average of 1 kW can be covered by a 3 kW battery if sufficient energy remains. A short 7 kW cooker and induction-hob coincidence cannot be fully met by that same battery and will draw from the grid unless other devices reduce power. A forecast optimiser working with hourly kWh bins may miss the peak. Import-cap strategies require an appropriately responsive, certified device-native controller, not a once-per-hour Home Assistant automation.
| Constraint | Example | Implication for dispatch |
|---|---|---|
| Energy capacity | 8 usable kWh | Total storage across hours |
| Discharge power | 3 kW continuous | Cannot cover 5 kW household peak alone |
| Charge power | 2 kW continuous | Four delivered kWh need at least two hours plus losses |
| SOC operating envelope | Vendor-defined minimum/maximum | External requested limits are subordinate |
| PV export permission | Zero-export or limited-export site | Do not schedule forced battery export without approval |
| Grid charging permission | Supplier and inverter settings | Negative prices do not prove grid charging is allowed |
| Phase imbalance | Three-phase import limits | Aggregate grid kW may hide per-phase overload |
| Battery temperature | Cold or hot derating | Actual power may be far lower than nameplate |
| Grid outage mode | Islanding and backup circuits | Dispatch commands may be ignored or prohibited |
How a Forecast-Aware Dispatch Plan Works
A useful day-ahead plan starts with forecast PV, forecast load, current battery energy, available charge/discharge power, tariff intervals, export price, reserve requirement and the manufacturer's available control modes. It should also know how old each input is. The optimiser then evaluates what will happen if charging is delayed, discharge is preserved for a high-price interval or reserve is increased before an expected outage. Forecast.Solar's Home Assistant integration supplies estimated generation, not certainty. Actual output can be reduced by cloud cover, snow, shading, inverter curtailment, a tripped breaker or a disconnected solar system.
Most mistakes come from using solar generation forecast as if it were battery charging forecast. First subtract household demand, required EV charging and other committed flexible loads at the appropriate time resolution. Then account for expected battery charge limits and reserve. If grid export is rewarded, surplus PV has an economic value even if it is available without additional grid import. A battery that absorbs 4 kWh otherwise exported has not obtained 4 kWh of zero-opportunity-cost energy.
A basic forecast structure
For each 15-minute or one-hour period, represent expected PV production, unavoidable household demand, battery SOC, electricity import price and export value. Add weather uncertainty and a default operating mode. A simple decision may ask: is the next expensive interval valuable enough to preserve energy, or will enough solar arrive before then that keeping the battery full wastes PV export opportunity? Answer separately for winter and summer; the correct policy can reverse with season.
For each candidate schedule, calculate predicted grid purchases, exports, battery throughput and unmet reserve constraint. Add transaction and reliability costs rather than using retail price alone. Apply only setpoints your inverter documents and permits. Recalculate when fresh forecast or actual measurements arrive, but avoid excessive write frequency and continuous 'hunting' that destabilises the vendor's own control loop.
| Forecast input | Typical weakness | More robust treatment |
|---|---|---|
| PV generation by interval | Cloud forecast error, shading, clipping | Use historical bias and low/central/high cases |
| Household baseline | Occupancy, cooking, heat pump variation | Use weekday profiles and a conservative upper bound |
| Retail import price | Missing charges and VAT, time-zone errors | Use contracted all-in marginal price per interval |
| Export value | Fixed rate, dynamic rate or no payment | Verify supplier settlement rules |
| Battery SOC | Sensor delay or estimation drift | Gate on freshness; allow SOC margin |
| Available capacity | Age, thermal and firmware limits | Use conservative measured usable energy |
| Availability | Internet feed or local gateway outage | Native mode operates safely without forecast |
Worked Example 1: Solar Self-Consumption Versus Export
Consider a household with 4 kWh midday surplus PV after ordinary loads and a battery capable of accepting that energy. Import electricity costs an illustrative £0.29/kWh and the export contract pays £0.12/kWh. Suppose 85% of battery input energy can later reach useful household loads after the complete relevant loss path. Charging from PV produces 4 × 0.85 = 3.4 kWh of future avoided imports, worth 3.4 × £0.29 = £0.986. The foregone export revenue is 4 × £0.12 = £0.48. The gross net value is £0.506, before assigning battery wear or any marginal standing/transaction costs.
If the wear allowance is an illustrative £0.05 for each kWh charged, it costs £0.20. The resulting illustrative value is about £0.31. If the evening's demand is only 2 kWh, the battery cannot usefully deliver all 3.4 kWh that night; unused energy may carry value to the following day, but today's calculation should not count it as an immediate saving. If the export payment rose to £0.25/kWh, the same 4 kWh would earn £1.00 and storage for £0.986 in avoided imports would already be unattractive before battery ageing.
This example is intentionally simple. A real inverter can have self-consumption and conversion losses even while idle, and the marginal battery wear cost is uncertain. Crucially, solar self-consumption ratio and financial value are not the same metric. More solar consumed at home is not automatically cheaper than exporting it.
Worked Example 2: Overnight Grid Charging on a Dynamic Tariff
Suppose an off-peak period costs £0.09/kWh, an evening peak costs £0.31/kWh and the battery's total grid-to-grid usable efficiency is 85%. Buying 5 kWh overnight puts roughly 4.25 kWh of useful AC output at your disposal. The energy bought costs 5 × £0.09 = £0.45. Avoiding 4.25 kWh at £0.31/kWh saves £1.3175, giving a gross spread of about £0.87. Deduct an illustrative wear allowance of £0.05 per kWh charged (£0.25) and the illustrative net economic value becomes about £0.62 for that cycle.
This calculation is not a recommendation to force-charge nightly. Charging may be prohibited by contract or device policy, forecast PV may arrive before the evening peak, battery temperature may limit charge, the usable reserve might be higher, or the household might not consume 4.25 kWh in the expensive period. Any cycle-throughput based wear estimate is a modelling assumption, not a manufacturer's guarantee.
A simple break-even approximation, ignoring different fixed charges, is: displaced peak import price × delivered efficiency > off-peak charge price + battery wear per charged kWh. With 85% efficiency, 9p off-peak electricity and a 5p/kWh charged wear allowance, the required displaced peak price exceeds (9p + 5p)/0.85 ≈ 16.5p/kWh. Change the assumptions and the threshold changes; highly volatile markets make the calculation more useful than a blanket 'charge every night' rule.
| Parameter | Worked assumption | Calculation impact |
|---|---|---|
| Off-peak energy purchased | 5.0 kWh | Energy cost base |
| Cheap-period price | £0.09/kWh | £0.45 purchase cost |
| Overall usable efficiency | 85% | 4.25 kWh displaced peak imports |
| Peak price | £0.31/kWh | £1.3175 avoided imports |
| Gross arbitrage | — | £0.8675 |
| Illustrative wear | £0.05/charged kWh | £0.25 |
| Illustrative net contribution | — | £0.6175 before further costs |
| Key validity check | 4.25 kWh peak demand available | Otherwise savings are overstated |
Worked Example 3: Preserve Battery for the Evening Peak
Assume your battery is at 55% SOC at 15:00. The usable battery-side capacity for this example is 10 kWh and you want a 25% reserve. You have roughly 3 kWh battery-side available above reserve; at 90% discharge conversion this corresponds to around 2.7 kWh of AC output. In the next two hours the household expects 1.2 kWh consumption at £0.18/kWh. From 17:00 to 20:00 it expects 3.8 kWh at £0.37/kWh. You might choose to preserve the 2.7 kWh of available output for the expensive period rather than discharge immediately.
If preserving 1.2 kWh at 18p means buying it from the grid and that same 1.2 kWh can later avoid 37p purchases, the maximum extra value is 1.2 × (£0.37 − £0.18) = £0.228 before any additional losses or wear. Whether this is worthwhile depends on what the system would otherwise do, whether it can enforce a supported reserve or mode without inefficient round trips, and whether evening load actually occurs. It would be erroneous to count all 2.7 kWh as new savings when the simple self-consumption baseline would have used much of that energy anyway.
If the optimiser forecasts strong late-afternoon PV, preserving space may be preferable to preserving SOC. A full battery can cause valuable solar energy to be exported or curtailed. The choice is therefore not merely 'save battery for peak'; it is 'choose the least costly feasible trajectory across PV, demand, price, reserve and charging limits'.
Worked Example 4: Import Cap and Phase Limits
A home may have a contractually configured import cap or a supply arrangement that requires active load management. Imagine a single-phase connection with a hypothetical 8 kW agreed operating target; an EV charges at 5.5 kW, other appliances consume 3.2 kW and a heat pump adds 1.5 kW. Total demand before the battery is 10.2 kW. A battery delivering 2.2 kW could reduce grid import to 8.0 kW, but only if it is already available, at adequate SOC, allowed to discharge, within its certified power capability and the inverter is designed to provide that response.
If the battery is only able to deliver 1 kW, grid import would still be 9.2 kW. A sluggish hourly Home Assistant forecast cannot provide a trustworthy protective response. Use approved EV charger dynamic load management and correctly installed electrical protective devices. Where a utility connection imposes a hard export or import condition, commission the manufacturer's power-limiting system; Home Assistant can log the outcome and perhaps request lower discretionary demand through an approved interface. It must not be described as the sole protection against exceeding supply limits.
On three-phase systems, total positive grid kW can conceal significant imbalance. A 9 kW three-phase sum does not mean each phase is below its individual limit. Record phase currents and neutral considerations with qualified installer involvement. Neither an inverter with three-phase marketing nor a software aggregate proves balanced load reduction in the required timeframe.
Battery Reserve and Grid-Limit Policies: An Explicit Priority Order
A practical dispatch policy should be written in plain English before any entity automation is created. The highest priority is always safety and commissioned equipment permissions. The next priority is maintaining sufficient reserve for essential backup, followed by any contractual grid and export restrictions. Only then consider avoiding expensive imports, maximising solar use or acquiring speculative arbitrage value. Users should be able to make a manual choice that remains visible through a restart and expires deliberately rather than being silently overwritten.
| Priority | Policy | Example rule | What the supervisor may do |
|---|---|---|---|
| 0 | Respect certified protection and BMS | Battery alarm or grid event | Stop issuing requests; native system handles condition |
| 1 | Preserve essential backup | SOC below protected reserve | Advise or request approved reserve mode |
| 2 | Stay within commissioned site limits | Near import/export threshold | Observe native limiter; reduce supported discretionary loads |
| 3 | Meet fixed commitments | EV must reach target by morning | Coordinate charger within its own safe controls |
| 4 | Use forecast PV reasonably | High expected excess solar | Delay optional charging if reserve permits |
| 5 | Minimise tariff cost | Store for expensive period | Request reversible supported operating mode |
| 6 | Reduce avoidable wear | Spread is too small to justify throughput | Prefer simpler native operation |
Reserve changes should use hysteresis
Suppose a policy calls for an ordinary reserve of 25% and a temporary bad-weather reserve of 40%. Switching back and forth every five minutes when forecasts fluctuate creates unnecessary control traffic and an inconsistent occupant experience. Use stable triggers, explicit entry/exit bands and a minimum dwell time. A storm alert from a reputable provider may justify a planned higher reserve, but a missing forecast should not be interpreted as zero rain or zero PV. Record why the target changed and provide an expiry time for the exception.
When setting an advisory target, remember that a battery already below the proposed reserve cannot become charged merely because Home Assistant displays a higher requested reserve. Its subsequent behaviour depends on the manufacturer's mode. Some systems might buy grid electricity, others preserve whatever SOC remains, and others may refuse the command. Never promise storm readiness without measuring actual SOC and available backup circuits.
Coordinating Batteries With EV Charging and Heat Pumps
EV charging and heat pumps are often much larger flexible loads than the battery itself. If an EV arrives home requiring 20 kWh before morning, a 10 kWh battery can be emptied quickly if the EV charger unknowingly treats battery discharge as 'solar surplus'. Some EV chargers identify surplus from the grid meter, which might read near-zero while the battery is discharging. Without coordination, the EV consumes stored energy at a time when that battery was intended for household peak shaving.
A better design defines whether the charger is permitted to use battery energy. Native charger settings may provide 'avoid battery discharge' or equivalent behaviour depending on manufacturer. Home Assistant can display planned EV demand and identify conflicts. The charger must still own safety-relevant current limits and its departure deadline. During winter, electric heating may reasonably have precedence over speculative battery arbitrage if comfort and defrost conditions demand it. A heat pump's own protection and compressor control cannot be treated as a flexible interruptible electrical load.
| Contending load | Likely problem | Better coordination |
|---|---|---|
| EV charger | Discharges home battery despite planned reserve | Prefer charger's supported solar and battery interaction settings |
| Electric immersion | Uses stored energy at low efficiency | Compare supplier rate and heat source alternatives; preserve hygiene controls |
| Heat pump | Overnight preheat competes with battery charge | Model thermal storage and COP; leave compressor safety native |
| Dishwasher | Delayed start may not be supported or safe | Use appliance-native remote-start approval only |
| Battery itself | Grid charge coincides with EV and exceeds supply target | Coordinate native schedules; respect approved load limits |
| VPP/utility event | Vendor remotely reserves or exports energy | Do not fight programme controls; verify contract obligations |
Home Assistant Architecture: Observe, Advise, Then Control Only if Supported
A robust smart-home architecture has a measurement plane, a planning plane and an optional actuation plane. Measurement reads SOC, power and energy sensors from official or vendor-supported sources. Planning combines these with the price feed and forecast to compute advisory targets. Only a separately approved actuation adapter should translate an authorised target into a supported inverter or gateway operation. The last element needs watchdog behaviour, write rate limits, logging and a documented method to relinquish external control.
You can build a useful system without the actuation plane. A dashboard might display 'Evening energy above reserve: 3.7 kWh' and 'Tomorrow's forecast PV: 7.5 kWh' with a note that the estimate is uncertain. Record proposed target reserve and actual SOC. Compare a modelled overnight charge with what the inverter actually did. After a month you can determine whether additional controllability is worth paying for.
Home Assistant YAML example 1: Read-only battery energy above reserve
The following configuration is advisory-only. Replace the example sensor.home_battery_soc entity with the actual reported SOC, verify that the quoted 10 kWh is an appropriate usable-capacity basis and adjust the reserve helper to an installer-approved value. The availability check ensures the estimate does not silently turn an unavailable battery sensor into zero.
input_number:
battery_reserve_advisory:
name: Battery reserve for planning only
min: 10
max: 80
step: 5
initial: 30
unit_of_measurement: "%"
battery_usable_kwh_assumption:
name: Battery usable energy planning assumption
min: 1
max: 40
step: 0.5
initial: 10
unit_of_measurement: "kWh"
template:
- sensor:
- name: "Battery energy above planning reserve"
unique_id: battery_energy_above_planning_reserve
unit_of_measurement: "kWh"
state_class: measurement
availability: >
{{ is_number(states('sensor.home_battery_soc'))
and is_number(states('input_number.battery_reserve_advisory'))
and is_number(states('input_number.battery_usable_kwh_assumption')) }}
state: >
{% set soc = states('sensor.home_battery_soc') | float %}
{% set reserve = states('input_number.battery_reserve_advisory') | float %}
{% set capacity = states('input_number.battery_usable_kwh_assumption') | float %}
{{ ([soc - reserve, 0] | max * capacity / 100) | round(2) }}
This returns a battery-side planning estimate, not necessarily useful AC energy. It does not write the reserve value to the inverter. For example, a 60% SOC, 30% assumed reserve and 10 kWh battery produces 3.0 kWh above reserve before conversion and other limitations. Remove the initial values if you want the UI helpers to persist changes without an intended reset on configuration reload; test their behaviour after restarting Home Assistant. The supported manual-control setting on the inverter remains independent.
Home Assistant YAML example 2: A data-quality gate
Real-time dispatch should never use a price or SOC sensor that silently went stale. Not every integration exposes its last successful sample time. The next example is a deliberately conservative health indicator based on entity validity and a separate example heartbeat (sensor.battery_telemetry_age_minutes). The heartbeat must come from a reliable last-update source; adding an auto-updating Home Assistant template that always says zero would defeat the check.
template:
- binary_sensor:
- name: "Battery dispatch inputs valid"
unique_id: battery_dispatch_inputs_valid
state: >
{{ is_number(states('sensor.home_battery_soc'))
and is_number(states('sensor.grid_import_power'))
and is_number(states('sensor.retail_import_price'))
and is_number(states('sensor.battery_telemetry_age_minutes'))
and (states('sensor.battery_telemetry_age_minutes') | float(999)) < 5 }}
- name: "Battery below advisory reserve"
unique_id: battery_below_advisory_reserve
availability: >
{{ is_number(states('sensor.home_battery_soc'))
and is_number(states('input_number.battery_reserve_advisory')) }}
state: >
{{ (states('sensor.home_battery_soc') | float)
< (states('input_number.battery_reserve_advisory') | float) }}
The first indicator is not a safety certificate or proof that metering is correct. Price feeds may include wholesale rather than retail prices; grid power signs vary; and some battery telemetry can remain numerically valid while it is old. The five-minute threshold is an illustrative engineering policy, not a manufacturer requirement. Nothing here writes a power setpoint or changes a reserve.
Home Assistant YAML example 3: Notify about a forecast/reserve conflict
A simple notification can be more useful than full autonomy. This automation advises when the battery is below the planning reserve and the data-quality checks pass. A 30-minute interval prevents noisy repetitions, and the message explicitly states that the issue needs review rather than trying to force a charge. Replace notify.mobile_app_your_phone with your actual notification service.
automation:
- id: battery_reserve_monitor_only
alias: "Battery reserve advisory notification"
description: "Monitor only; no inverter control commands"
triggers:
- trigger: time_pattern
minutes: "/30"
conditions:
- condition: state
entity_id: binary_sensor.battery_dispatch_inputs_valid
state: "on"
- condition: state
entity_id: binary_sensor.battery_below_advisory_reserve
state: "on"
actions:
- action: notify.mobile_app_your_phone
data:
title: "Battery planning reserve"
message: >-
Battery SOC is below the advisory reserve.
Check the manufacturer's native mode and actual backup readiness.
mode: single
A production setup needs a separate check that Home Assistant's named entities have not changed, along with a notification policy appropriate for occupants. The example does not request grid charging or issue an emergency instruction. To avoid recurring alerts during a known low-SOC period, you can add a silence helper or trigger only on the transition into the alert state; ensure the detection is reliable across restarts.
Home Assistant YAML example 4: Estimate a price spread without controlling the battery
For a quick candidate-screening calculation, compare the projected peak retail import price with an off-peak charge price, applying an assumed overall efficiency and wear allowance. This is not an optimiser; it assumes that charged energy can displace actual peak imports and that the figures are all in the same currency per kWh.
input_number:
battery_round_trip_efficiency_assumption:
name: Battery round trip efficiency for planning
min: 0.60
max: 0.98
step: 0.01
initial: 0.85
battery_wear_cost_per_kwh_assumption:
name: Battery wear assumption per input kWh
min: 0
max: 0.20
step: 0.005
initial: 0.05
unit_of_measurement: "GBP/kWh"
template:
- sensor:
- name: "Battery hypothetical dispatch margin per charged kWh"
unique_id: battery_hypothetical_margin_per_kwh
unit_of_measurement: "GBP/kWh"
state_class: measurement
availability: >
{{ is_number(states('sensor.cheap_import_price'))
and is_number(states('sensor.peak_import_price'))
and is_number(states('input_number.battery_round_trip_efficiency_assumption'))
and is_number(states('input_number.battery_wear_cost_per_kwh_assumption')) }}
state: >
{% set peak = states('sensor.peak_import_price') | float %}
{% set cheap = states('sensor.cheap_import_price') | float %}
{% set eff = states('input_number.battery_round_trip_efficiency_assumption') | float %}
{% set wear = states('input_number.battery_wear_cost_per_kwh_assumption') | float %}
{{ (peak * eff - cheap - wear) | round(3) }}
Do not copy the sensor names blindly: they represent prepared retail price inputs, not necessarily sensors produced by your existing integration. A positive margin is only a necessary screening condition, not proof that a battery cycle is advisable. Check spare capacity, reserve, actual evening demand, export opportunity, charge rate, site tariff and device permission before making a control decision.
Designing a Supervisory Control Adapter Safely
If your inverter explicitly supports external mode or reserve commands, the control adapter deserves its own design and testing. Home Assistant should send a bounded intent, such as 'prefer a higher reserve until 18:00', rather than an unvalidated register value. The adapter should confirm model and firmware compatibility, clamp inputs to approved limits, respect rate limits, use authenticated local access where available and record both requested and measured states. It should relinquish control after a defined timeout and leave the device in an agreed native fallback mode. Never expose Modbus TCP on the public internet or allow arbitrary requests to sensitive control registers from the household Wi-Fi.
Before going live, make a table of allowable commands from the manufacturer and installer, the exact response semantics, allowed numerical range, effect during a grid failure, persistence across reboot and interaction with native optimiser/VPP operation. Test in a non-critical period with supervision. Confirm the output using independently measured grid power and actual SOC evolution. If a command is not explicitly documented, omit it. A 'works on my inverter' community example is not sufficient grounds to control your home backup supply.
| Control requirement | Safe engineering practice | Unsafe shortcut |
|---|---|---|
| Known model and firmware | Record the precise manufacturer documentation version | Assume every inverter in a brand uses the same registers |
| Rate limiting | Change setpoints only at approved cadence | Write every second to chase a fluctuating tariff |
| Acknowledgement | Observe accepted mode and resulting grid/battery power | Assume sending a command guarantees execution |
| Limits | Clamp reserve, power and SOC to documented allowances | Attempt to exceed inverter/BMS limits |
| Fallback | Restore permitted native mode on loss of control | Leave device in external mode indefinitely |
| Cybersecurity | Local segmented network and restricted permissions | Internet-facing unauthenticated Modbus TCP |
| Change ownership | One named master per setting | Multiple independent schedules fight each other |
| Backout | Keep installer-approved rollback procedure | Experiment with undocumented registers without a backup |
Forecast Uncertainty, Backtesting and Model Confidence
Forecast-driven dispatch fails most often because the optimiser assumes its predictions will occur exactly. Clouds arrive early, a family cooks unexpectedly, an EV needs more charge than scheduled, and prices can change at a 15-minute boundary. A robust plan uses uncertainty bounds: a conservative PV forecast for reserve planning, a central case for expected financial benefit and an optimistic case only as a sensitivity analysis. An optimiser that profits by £0.10 in its central case but loses £0.70 under a plausible forecast error has a weak justification for acting.
Backtest at least a fortnight of predictions against interval-level actuals and compare with a simple fixed reserve/self-consumption baseline. Use time-aligned measurements. Evaluate mean absolute error, bias and how often SOC would have approached protected reserve. Avoid training a model on the same periods used to claim its savings. Include weekends, cold spells and cloud transients. A model may look accurate for daily total PV energy while being poor at estimating when surplus occurs; timing is what determines charge/discharge value.
A plan should log its original prediction, actual outcome, tariff seen at decision time, charge/discharge energy and reasons for override. Otherwise unexpected behaviour cannot be reconstructed. The best change may be to improve load forecasts or stop an EV charger from draining the battery rather than install a larger optimisation stack.
| Test | Useful acceptance question | Common failure |
|---|---|---|
| Forecast PV bias | Is tomorrow's low case credibly conservative? | Seasonal shading ignored |
| Price alignment | Does the right tariff apply to each local interval? | UTC/DST or 15-minute mismatch |
| SOC projection | Does modelled SOC resemble observed SOC? | Wrong usable-capacity or efficiency assumption |
| Constraint compliance | Did actual power respect inverter and grid limits? | Hourly optimiser missed instantaneous peak |
| Reserve adequacy | Was required reserve available at the promised time? | Charging plan depended on PV that never arrived |
| Net financial result | Is saving greater than baseline after losses/wear? | Comparing with theoretical rather than measured baseline |
| Command execution | Did the inverter actually accept the approved action? | A control readback reports last requested setting only |
The Hidden Cost of Battery Cycling
Battery life is not a single universal number of cycles. Manufacturers specify warranty terms involving years, throughput, usable capacity, retained capacity or a combination; ambient temperature, depth of discharge, high-power operation and time at high SOC can influence ageing. The popular shortcut 'battery purchase cost divided by assumed lifetime kWh' is a scenario estimate, not a measurable marginal wear invoice for each cycle. Nevertheless, some wear allowance is useful when deciding whether a tiny price difference justifies extra throughput.
For an illustrative economic model, suppose a future replacement cost allocated to additional usable throughput amounts to £0.04–£0.10 per charged kWh. That interval is an analyst's sensitivity range, not a claim that a particular Powerwall, Victron-connected battery or hybrid system has that warranty cost. Test the margin at several values. If a dispatch decision stops being attractive when wear is 6p rather than 4p, it is not a robust opportunity. Conversely, if the native battery system would cycle anyway to absorb otherwise curtailed PV, the incremental wear attributable to your proposed change may be smaller than charging the entire day's throughput to the decision.
| Economic item | Common mistaken assumption | More defensible method |
|---|---|---|
| Battery efficiency | Fixed 100% conversion | Use observed or conservative complete-path efficiency |
| Battery degradation | 'Free' cycling | Sensitivity range based on product and usage |
| Export opportunity | Surplus PV has no value | Deduct actual foregone export payment |
| Purchase price | Wholesale day-ahead equals bill tariff | Use retail contract including marginal charges |
| Fixed charges | Entire standing charge varies with schedule | Exclude charges unchanged by shifting |
| Back-up value | Always zero or always infinite | Set a separate reserve requirement and value judgement |
| Control software | No running cost | Include gateway, subscriptions, backup and support time |
Seasonal Planning: Winter, Summer and Shoulder Months
In summer, a battery may reach high SOC by late morning. It can be more valuable to leave space for solar, unless evening prices are unusually high or a backup event is expected. In winter, daily PV can be scarce and preserving reserve may be the dominant need; low-rate grid charging could be sensible on a permitted TOU contract. In shoulder months, changing heat-pump loads and variable cloud conditions make forecasts especially important.
Build at least three representative scenarios rather than one annual average. For each, calculate the likely overnight demand, sunrise SOC, PV charging window, evening peak and protected reserve. Then ask whether a simple native mode already delivers 80–90% of the value. That percentage is a hypothetical test criterion, not a measured universal result. External automation may not repay its own development and failure-handling costs if it adds only a few pounds a year.
A battery's installation also changes over time. New EV usage can turn yesterday's optimal schedule into one that empties the backup reserve. An export tariff can expire or increase. A manufacturer firmware update can remove a local control capability. Schedule a periodic review, especially after adding solar panels, a heat pump, a smart EV charger or a new electricity contract.
Network Failures, Cloud Outages and Recovery
An internet outage may stop a price feed or solar forecast while the local inverter continues its last permitted mode. A LAN outage can cut Home Assistant off from the device. MQTT or Modbus session failure can leave cached numbers that look healthy until their timestamps are inspected. A Home Assistant restart can repeat a startup automation, and firmware updates can change entity identifiers or supported operations. A safe system needs a response for each, not merely a generic 'unavailable' warning.
The preferred fallback is the manufacturer's documented self-consumption or backup behaviour, not an arbitrary assumption that 'battery charging off' equals safe. On Victron, for example, documented ESS sustain and hardware limits may override external preferences; in other ecosystems, a stale external command may persist or expire differently. Verify on the actual commissioned system. During outages, grid-charging permissions and VPP behaviour may change. Never test a genuine grid disconnection casually just to see if an automation works: use the manufacturer's approved commissioning procedure and professional support.
| Failure | What Home Assistant may observe | Recommended supervisory response |
|---|---|---|
| Internet lost | Forecast and prices stop updating | Suspend economic optimisation; use native schedule |
| LAN/gateway lost | Device sensors become unavailable | Stop new writes; native controller retains safety |
| MQTT broker lost | Old retained values may remain visible | Enforce source timestamp and heartbeat checks |
| Home Assistant restarts | Automations/helpers reload | No automatic forced charge on boot; reconcile state first |
| SOC drops rapidly | Forecast disagrees with reality | Give reserve protection precedence |
| Battery alarm | BMS/inverter reports limitation | Do not push through limit; service/diagnose as instructed |
| Grid outage | Backup switching is native to hardware | Monitor only; do not force export/grid modes |
| Firmware updated | Features or writable entities differ | Disable external adapter pending regression test |
| Export/import restriction | Grid meter approaches threshold | Rely on approved native limiter, not cloud latency |
Commissioning and a 30-Day Evaluation Plan
Do not begin with an automatic dispatch write. During the first week, inventory equipment, validate readings and document the native schedule and reserve. Confirm grid import/export directions against the utility meter and compare SOC trends against actual stored energy. Identify who may change settings: homeowner, installer, cloud app, energy supplier, VPP and Home Assistant. You need a baseline that includes ordinary weekdays and weekends.
During the second week, run Home Assistant's planning dashboard without controlling the inverter. Log each recommended action, expected saving and reserve impact. At the end of the week compare hypothetical actions against what actually happened. Reject suggestions that assume nonexistent evening demand or optimistic solar forecasts. During the third week, test only authorised controls with an installer or appropriate supervision, one setting at a time. Confirm rollback. During the fourth week, evaluate real settlement-meter costs, reserve compliance, cycling and occupant satisfaction against the baseline.
| Stage | Required evidence | Pass condition before proceeding |
|---|---|---|
| Inventory | Hardware model, firmware, grid agreement, VPP terms | Control permissions documented |
| Meter validation | Import/export, PV, battery signs and timestamps | Totals reconcile within known metering limits |
| Baseline | Native modes, daily SOC and tariff costs | Meaningful comparison available |
| Advisory trial | Predictions and actual outcomes | No reserve or safety conflicts in model |
| Control authorisation | Manufacturer control path, installer consent | Supported action and fallback documented |
| Limited live trial | Command/readback/energy results | Native protection overrides remain active |
| Failure drills | Lost internet, stale data, restart, firmware change | No uncontrolled charging or export |
| Monthly review | Measured bill change, wear assumptions, errors | Improvement demonstrated, not merely predicted |
A practical handover checklist
Record the approved native operating mode, backup reserve, whether grid charging is allowed, the energy tariff source, export restrictions, the Home Assistant host address, relevant software versions, the device that owns each setting, alarm pathways and the process for restoring default operation. Label all assumptions with units and date. A homeowner should not need to reverse engineer an old YAML file to understand why their battery stopped discharging into the evening load.
Troubleshooting: When the Battery Ignores the Plan
Battery charges when the automation says it should stop. First check whether you are reading an actual power or a desired setpoint. The BMS may be exercising a safety or sustain function, the inverter may be in a manufacturer's native schedule, or a solar surplus may be charging it independently of the grid request. Some devices intentionally ignore commands outside permitted operating modes. Check vendor diagnostics rather than attempting to override the behaviour repeatedly.
A negative grid price triggers no charging. A day-ahead market price might be negative while the contracted household retail rate remains positive after margin, taxes and charges. Your inverter may not allow grid charging, or capacity/reserve bounds may prevent it. Verify the price entity's units, sign and time zone, then the device's authorised scheduling method.
SOC falls much faster than the model predicts. Check whether loads such as EV charging or electric heating are drawing through the battery. Re-evaluate the assumed usable energy capacity, inverter losses, power measurement boundaries and temperature. A temporary mismatch is not evidence of a battery fault, but repeated discrepancies can justify installer review.
Battery will not export even with a high sale price. Export might be prohibited, the supplier may not pay for energy from grid-charged storage, the system may have a no-export setting, or the inverter may be limiting output. Do not change export controls without checking grid-connection consent and manufacturer rules.
A Modbus write appears to work but nothing happens. Some registers are read-only, use unexpected scaling or unit IDs, or represent requested rather than realised power. Firmware changes can alter behaviour. Check the exact official mapping and actual measured output. Never experiment with undocumented write paths on a live battery or grid-connected inverter.
Home Assistant shows stale yet believable values. A retained MQTT message is not a heartbeat. Confirm the actual source timestamp or last successful poll; make templates unavailable when the input is too old. A new local dashboard display of an old SOC is not evidence of live battery telemetry.
Forecast optimisation appears profitable on graphs but not on bills. The comparison may be against an unrealistically expensive baseline, may omit foregone export value, may assume battery energy is lossless or may apply wholesale rather than all-in import prices. Recalculate using settlement-meter import/export totals and contract-specific rates, then assign a conservative battery-throughput allowance.
The charge plan changes too often. Add forecast confidence bands, minimum dwell times and write-rate limits; use a single controller per setting. A sequence of fine-grained reversals can waste energy without delivering useful arbitrage. Test a simpler time-of-use rule as the benchmark.
Frequently Asked Questions
Can Home Assistant control the charge and discharge of every home battery?
No. Many integrations expose monitoring data, and some support only a limited set of manufacturer-approved settings. Write permissions depend on inverter model, firmware, region and integration. A visible battery power sensor does not mean direct dispatch is supported.
What is the best battery reserve percentage?
There is no universal answer. Size the reserve against essential backup demand, expected outage duration, usable energy, conversion loss, expected solar recharge and the household's risk preference. Respect the manufacturer's minimum SOC and any warranty or VPP requirements.
Does more solar self-consumption always save money?
No. Battery losses, wear and foregone export income can make some stored solar less valuable than exporting it. Compare the marginal avoided import value with the actual export opportunity and incremental battery costs.
Should I grid-charge the battery whenever electricity is cheap?
Only if grid charging is permitted and the spread after round-trip losses and wear is positive, there is space and time to charge, and the energy can actually displace higher-cost consumption. Strong solar the following morning can change the answer.
Is Modbus TCP a safe way to force battery dispatch?
Modbus is a communication mechanism, not an automatic guarantee of safe control. Use only the manufacturer's documented settings on the exact supported model and firmware, with properly commissioned grid and battery protections. Unofficial registers should not be treated as supported.
Why is my battery discharging into the EV charger?
Depending on charger and inverter configuration, the EV's electricity demand may look like ordinary household demand. The inverter may discharge to maintain low grid import. Look for supported charger battery-avoidance settings and coordinate native schedules rather than forcing untested controls.
Can I use Home Assistant to enforce a household grid import limit?
Home Assistant can monitor import and coordinate non-critical demand, but it is not a substitute for an approved fast electrical load-management or supply-protection system. Use certified charger and inverter controls, and have connection limits assessed by a qualified installer.
How often should a battery dispatch plan update?
Fast enough to account for material forecast and tariff changes, but not so often that controllers hunt or devices receive excessive writes. The correct cadence depends on the manufacturer's interface and the market settlement interval. Preserve the approved grid-control loop and limit supervisory changes.
Does Tesla Powerwall's Home Assistant integration allow backup-reserve changes?
The standard local Powerwall integration primarily exposes sensor and switch information and does not provide a universal editable reserve control. Use the Tesla app or a separately authorised supported integration for settings; check Powerwall generation and firmware limitations.
Can I rely on Enphase local reserve settings?
Not on every firmware. The official Envoy integration specifically documents restrictions on local battery setting operations in some newer firmware, so verify the exact current capability rather than copying a previous automation.
Is Victron Mode 3 the best route for DIY optimisation?
Usually not. Victron Mode 3 puts more responsibility on the external control loop, which is a major engineering task. Prefer properly commissioned native ESS and, where justified, documented Mode 2 supervisory controls. Do not disable the manufacturer's normal protective behaviour.
Do battery energy forecasts need 15-minute intervals?
That resolution can help when prices or loads change quickly, but hourly data may be sufficient for a simple schedule. Use intervals consistent with the actual tariff and device responsiveness. Better temporal resolution cannot compensate for poor input measurements.
What happens if forecasts or price feeds disappear?
Suspend economic optimisation and use a verified native operating mode that maintains reserve, complies with grid conditions and leaves the inverter/BMS in control. Never interpret missing prices as zero or missing SOC as a fully charged battery.
How do I know whether dispatch has saved money?
Compare settlement-meter import/export energy and actual contract prices with a reasonable native-mode baseline for similar conditions. Deduct losses, foregone export income and an explicit wear allowance. Track observed rather than merely simulated outcomes.
Can negative electricity prices make forced export profitable?
Possibly, but only under the actual retail contract, export settlement rules and grid permissions. Taxes, supplier restrictions, export caps and battery throughput can reverse a wholesale-market result. Never infer legal or contractual permission from a negative market-price sensor.
Is battery backup reserve wasted energy?
No. Energy kept for resilience has a different purpose from reducing the electricity bill. It may also become usable after a grid event or a change of preference. The correct reserve is a household risk decision, not simply a financial inefficiency.
Will the battery accept an external power command immediately?
Not necessarily. Battery temperature, SOC, BMS current limits, grid-code ramp restrictions, firmware, native schedules and other controllers may prevent or delay a response. Always compare actual measured behaviour with the requested state.
Is an external optimiser worth it for a simple fixed-rate household?
Often the native self-consumption mode and a well-chosen reserve are sufficient. Forecast optimisation can be useful with a large price spread, time-varying export values, substantial flexible loads or backup requirements, but it must demonstrate benefits against a simple baseline.
Related ESP32.co.uk Guides
For details about the economics of the hardware itself, see Home Battery ROI: Degradation, Electricity Tariffs and Backup Value. For how an EV can compete with a stationary battery, see EV Charging with a Home Battery: Grid Limits and Solar Priorities. For the communication architecture of an open battery ecosystem, see Victron GX to Home Assistant: MQTT vs Modbus TCP vs Official Integrations. For trustworthy energy totals, see Solar Import and Export Metering: Avoiding Double Counting in Home Assistant. For broader software architecture, see Whole-Home Energy Monitoring Without Cloud.
Official Sources and Further Reading
- Home Assistant — Integrating Home Batteries: measurement and Energy dashboard requirements.
- Home Assistant — Victron GX: supported MQTT connectivity and entities.
- Victron Energy — ESS Mode 2 and Mode 3: documented external-control architecture and restrictions.
- Home Assistant — Tesla Powerwall: native integration capabilities and hardware limitations.
- Tesla — Backup Reserve: user-facing backup settings.
- Home Assistant — Enphase Envoy: telemetry, control entities and firmware limitations.
- Home Assistant — Forecast.Solar: production forecasts and refresh behaviour.
- Home Assistant — Nord Pool: market-price data and interval caveats, not retail settlement rates.
- Home Assistant — Template: read-only helper sensors and entity availability.
Final Recommendation
For most houses, an excellent first battery automation is a reliable monitoring and advisory system, not a collection of forced charge and export commands. Get the grid-meter data, SOC, inverter configuration, backup-reserve policy and actual tariff right. Compare the vendor's existing mode against a realistic alternative, including efficiency, export value and wear. Treat any advanced dispatcher as a supervisor requesting supported reversible preferences, with one clear owner of each control and a documented native fallback. If the financial improvement is small or the interface is unsupported, keep the system simpler. Reliability and retained backup power are real benefits, even when they do not appear in a daily arbitrage chart.
Editorial note: this guide discusses monitoring and manufacturer-supported supervisory planning. It does not authorise inverter wiring, battery-pack modification, bypass of BMS protections, undocumented Modbus writes, grid export without permission or replacement of certified electrical protection. All sample prices and technical sizes are illustrative and should be checked against your installation and contract.
