Quick Summary (TL;DR)
A complete smart-home energy system is not a collection of individually smart boxes: it is a correctly metered electrical installation with clear control ownership. Start at the grid connection, establish where solar production, battery energy, vehicle charging and heat-pump consumption are measured, then choose supported local interfaces. Put electrical protection, certified EV load management, inverter/BMS operation and heating safety inside their respective approved systems. Use Home Assistant for visibility, records, notifications and carefully bounded supervisory requests—not as the last line of safety protection.
Best starting architecture: an appropriate bidirectional grid meter and inverter telemetry; a compatible battery gateway where storage is fitted; an EV charger with its own approved load-management arrangement; the heat pump’s native controller; and Home Assistant on a reliable local host. Prefer Ethernet for fixed gateways, use UPS-backed infrastructure where justified, and record cumulative import/export kWh as well as instantaneous power. Confirm protocol support on the exact model and firmware before buying. Neither a Modbus socket nor a Matter badge guarantees the control functions you want.
For most households the sensible purchase order is meter → local data → trustworthy dashboard → one controllable flexible load → verified economic benefit → more automation. A household without solar or an EV may never justify a complex optimiser. Conversely, a property with solar, a battery, two EVs and a heat pump benefits from an architecture document, clear priorities and controlled commissioning before installing additional software. Worked prices and tariffs below are illustrative planning assumptions, not live quotations or predicted savings.
What a complete home-energy system must actually do
It should answer four different questions. Measurement: what is happening at each electrical boundary right now, and how much energy has flowed over the billing period? Operational control: which equipment may respond to prices or solar surplus without violating equipment constraints? Protection: what prevents overload, unsafe battery operation, uncontrolled heating or dangerous backfeed during faults? Recovery: what happens during loss of broadband, Wi-Fi, a data gateway, Home Assistant, mains power or an individual appliance?
These are different jobs and should not be outsourced to one dashboard. An attractive energy flow chart can be built with inferred numbers that are wrong; a working solar-surplus charger can still exceed a property’s supply allowance if its load-limit equipment is misconfigured; an optimised heat-pump schedule can increase total cost if it raises flow temperature or uses resistance heating. The goal is a measurable, maintainable and electrically safe system, not maximum automation count.
| Layer | Principal components | What it should own | What it must not be asked to replace |
|---|---|---|---|
| Electrical protection | Protective devices, cable design, RCD/RCBOs, earthing, isolators, approved grid protection | Shock, overload, fault and isolation protection | An automation, MQTT value or Wi-Fi relay |
| Device protection | Battery management system, inverter protection, charger safeguards, heat-pump safeties | Device operating envelope and safety interlocks | External scripts or unsupported register writes |
| Native operating control | Inverter energy controller, approved EV load balancing, heating controller | Fast closed-loop control, protective fallbacks and local operating logic | Cloud optimisation promises |
| Site metering | Bidirectional grid meter, PV/battery/EV/circuit energy data | Consistent measured boundaries and billing reconciliation | Adding incompatible energy counters |
| Supervisory optimisation | Home Assistant, evcc, manufacturer APIs, optional forecast tools | Schedules, user preferences, price-aware requests, alerts | Certified real-time supply limitation |
| Presentation and records | Recorder, dashboards, optional time-series database | Trends, costs, anomaly investigation, audit trail | Source-of-truth device protection |
Architectural rule: one owner for every control
Document which device has the final say over an EV charger’s current, a battery’s reserve, the heat pump’s space-heating target, the hot-water cylinder’s hygiene programme and export limitation. Several platforms can observe one value; only one should be its ordinary supervisory writer. Native safety logic may always override it. If a supplier app, EV charger schedule, evcc and a Home Assistant automation all issue contradictory start/stop requests, the installation is neither predictable nor easy to debug.
| Controlled function | Recommended ordinary owner | Permitted supervisory request | Required independent boundary |
|---|---|---|---|
| Site connection and protective current limits | Designed electrical installation / approved charger load manager | None that relaxes the limits | Protective devices and manufacturer-approved limits |
| PV conversion and grid compliance | Inverter firmware and certified grid interface | Read-only monitoring; documented power limit if explicitly supported | Anti-islanding and export compliance |
| Battery charge, discharge and reserve | Inverter/ESS and BMS | Supported reserve or schedule target inside permitted limits | BMS temperature/current/voltage limits |
| EV charge current | EVSE and its approved load-management controller | Charging plan, current preference or schedule where officially supported | EVSE electrical safety and supply headroom |
| Heat pump compressor and pumps | Heat-pump controller | Supported setpoint, mode or setback; avoid repeated on/off commands | Refrigerant, frost, flow, high-temperature and compressor protection |
| Hot-water hygiene and overtemperature | Approved cylinder/heating safety controls | Schedule preference within hygiene requirements | Independent thermostat, overtemperature cut-out, manufacturer hygiene programme |
| Smart-home optimisation | One explicitly nominated platform | Economic schedule, alerts, non-critical discretionary loads | Offline fallback and operator override |
Reference architecture: five energy domains, one monitoring layer
Draw the physical one-line diagram before designing the software diagram. Electricity enters through the supply and its protective apparatus. A bidirectional import/export meter sees the net exchange with the public grid. A PV inverter feeds an AC bus, possibly sharing a hybrid inverter with a battery. EV charging and the heat pump are downstream loads. The Home Assistant host, network switch and gateways connect for data, but they are not in the certified protective path. In an islanding/backup installation the backup output, transfer arrangements, permitted circuits and neutral/earthing arrangements require a separate professionally engineered drawing.
Conceptual data path: grid meter / approved supply meter → vendor gateway or supported local API → Home Assistant energy entities; PV inverter → inverter integration; battery → ESS telemetry; smart EVSE → supported charger API or OCPP controller; heat pump → manufacturer integration or supported Modbus mapping. Optional evcc communicates with the charger and energy meters to optimise EV charging; Home Assistant may display the resulting states without also attempting to own every charger command.
Conceptual power path: public grid ↔ bidirectional connection ↔ household distribution; PV AC production → distribution; battery AC output ↔ distribution (or DC-coupled inside hybrid inverter); EV charger ← distribution; heat pump ← distribution. These arrows describe logical flow only and are not wiring instructions. In DC-coupled hybrids, a PV DC figure cannot automatically be added to an AC-side battery/PV figure without accounting for the inverter boundary and losses.
| Energy domain | Essential observation | Strongly preferred measurement | Typical supported local route | Control owner |
|---|---|---|---|---|
| Public grid | Import/export power and cumulative kWh | Meter at actual supply boundary; per-phase data if applicable | Vendor gateway, compatible Modbus meter or official smart-meter integration | Utility-certified metering/protection, not Home Assistant |
| Solar | AC production power and cumulative AC energy | Inverter AC production sensor; clarify DC MPPT telemetry | Local inverter API, vendor integration, SunSpec/Modbus as supported | Inverter |
| Home battery | SOC, charge/discharge power and energy, operating mode | Battery/inverter telemetry with documented sign conventions | Vendor ESS gateway, supported API or Modbus | Inverter/BMS |
| EV charging | Charge state, measured power, session kWh, optional vehicle SOC | EVSE energy meterAliExpress price and approved grid CT/meter for load management | Manufacturer-supported LAN API, OCPP or evcc-supported interface | EVSE/load manager |
| Heat pump | Electric consumption, delivered heat where available, flow/return and mode | Dedicated electrical meter and a proper heat meter for COP measurement | Manufacturer-native API, validated Modbus integration | Heat-pump controller |
| Household flexibility | Cylinder heat, selected appliances, optional subcircuits | Appropriately rated circuit meters where needed | Supported local controls, monitoring plugs where rated | Native appliance and certified switching arrangement |
Is the design for single-phase or three-phase supply?
Confirm the actual incoming supply, service capacity, country, tariff, permitted export and connection arrangements. Never translate a nameplate 3-phase charger rating into a guaranteed household charge speed. A 7.4 kW single-phase charger typically draws approximately 32 A at 230 V, while approximately 11 kW on a 400 V three-phase system is about 16 A per phase; those are nominal calculations, not an endorsement of that demand on your supply. The instantaneous current on each phase, neutral arrangement, load diversity and approved protection all matter. A three-phase energy meterAliExpress price must map its voltage inputs and CTs to the correct phases. A solar-heavy installation can import on one phase while exporting on another; the supplier’s settlement arrangement and the meter’s aggregation behaviour determine how that is billed.
For an introductory comparison of phase supplies and hardware sizing, see our single-phase versus three-phase energy monitoring guide and 7/11/22 kW EV charger comparison.
Step 1: select a meter that you can trust
The first hardware purchase should be driven by the energy questions the system must answer. A bidirectional grid sensor must distinguish import from export and preferably provide separate monotonically increasing import and export energy counters. A net power reading can show direction but cannot simply be integrated into one total for both directions without correct sign splitting and handling missing samples. The utility meter’s bill remains the commercial reference even if a private CT monitor is excellent for control and diagnostics.
Meters have different installation contexts. A DIN-rail Modbus instrument might suit a distribution board with correct professional installation; a multi-channel CT monitor can expose several circuits but demands suitable conductor access and correctly matched clamps; vendor smart meters may be required for an inverter’s own energy flows. Do not substitute a third-party measurement for a manufacturer’s listed grid-control meter unless the vendor approves that configuration. Current-transformer orientation, CT ratio, voltage reference and phase mapping can all produce plausible but wrong results.
| Meter type | Strong fit | Weakness or purchasing trap | Commissioning evidence |
|---|---|---|---|
| Bidirectional supply meter with official data access | Import/export billing comparison | Access latency, supplier/region restrictions | Compare daily import and export kWh with bill/data portal |
| Compatible DIN-rail Modbus energy meterAliExpress price | Local panel metering and reliable LAN/RS-485 | Qualified installation; exact register map and meter class required | Document phase mapping, register scaling and counter reset behaviour |
| Multi-channel CT monitor | Home total plus selected circuits | CT orientation, voltage reference, phase matching and enclosure space | Check load steps and three-phase totals |
| Inverter-branded smart meter | ESS self-consumption and manufacturer control | May not expose every value to Home Assistant | Validate inverter app versus independent grid import/export |
| Charger-integrated kWh meter | EV session accounting | Not the same as service-entrance load-management meter | Compare delivered session energy with upstream circuit data |
| Smart plugAliExpress price energy meterAliExpress price | A selected low-power appliance | Load/current rating, appliance start behaviour, metrology | Check rated use, repeatability and idle reporting |
Power and energy are not interchangeable
Watts (W) are a rate at an instant; kilowatt-hours (kWh) accumulate energy. The expected relationship is energy in kWh = integral of power in kW over time. A 2 kW heater operating for 90 minutes consumes about 3 kWh; it does not consume 2 kWh simply because the sensor reads 2,000 W. Home Assistant’s Energy dashboard expects appropriate energy statistics or compatible power entities, and long-term recording must be enabled for relevant sensors. Choose energy entities according to their physical measurement boundary. Do not add a downstream device meter to the whole-house meter and claim the sum is total consumption: that counts the same electricity twice.
Use the site’s detailed guide to correct grid, solar and battery energy entities before configuring charts. Home Assistant also supports individual device energy hierarchies, making it possible to avoid counting nested devices twice when they share an upstream circuit.
Worked instantaneous energy-flow balance
Consider a sunny afternoon with PV output = 5.0 kW, battery charging = 1.0 kW, EV charging = 2.0 kW, heat pump = 0.8 kW, and other household consumption = 0.7 kW. Loads plus battery charging total 4.5 kW. Therefore grid export is approximately 0.5 kW at that moment, assuming no other unmetered conversion flows and all values are measured at compatible boundaries. If battery charging rises by 0.8 kW while nothing else changes, the grid begins importing approximately 0.3 kW. The signs and AC/DC boundaries must be consistent for this arithmetic to be useful.
| Flow at matched AC boundary | kW | Balance treatment |
|---|---|---|
| Solar production | +5.0 | Supply |
| EV charging | −2.0 | Load |
| Heat pump | −0.8 | Load |
| Other circuits | −0.7 | Load |
| Battery charging | −1.0 | Storage absorption |
| Net grid exchange | 0.5 export | Supply minus consumption |
The relationship is useful for diagnostic plausibility, not for deriving every measurement from the others. If the installed PV sensor is DC-string power and the other sensors are AC, include the conversion difference or use a different source. If one of the readings is delayed by 30 seconds, an instantaneous balance during a compressor start or EV current step can look wrong even when daily totals are accurate.
Step 2: select a solar inverter by local data and service support
A solar inverter purchase has to make sense as an electrical and solar installation first. Long-term warranty, installer competence, battery compatibility, grid approval, MPPT configuration and after-sales support outweigh a fashionable smart-home integration. Only after these are established should you compare data access, polling rates, phase data, inverter AC energy counters, storage setpoints and networking options.
Fronius, Victron, Huawei, Solis, Growatt, SolarEdge and other vendors do not share one universal integration contract. Even within a product family, local Modbus may require a compatible dongle, dedicated meter, enabled server option, particular firmware or register-map revision. Home Assistant’s official Fronius integration documents local Solar API monitoring and optional Modbus controls where supported; that does not mean every Fronius register may safely be written. The generic Modbus integration can read model-specific registers, but the mere existence of a Modbus interface does not prove any control is available. Consult the solar inverter integration comparison for the model-level shortlist.
| Pre-purchase check | Why it matters | Acceptable evidence |
|---|---|---|
| Inverter model, region and firmware | Same marketing family may support different gateways | Exact product documentation and support list |
| Required smart meter | Grid control/export limit may require listed hardware | Installation guide identifying approved meter part numbers |
| Local read-only telemetry | Dashboard should survive cloud outage | Official LAN API/register or supported integration documentation |
| Writable control points | Limits, battery reserve and modes are model-specific | Vendor-published safe control interface and constraints |
| Internet independence | Native system may continue while app stops | Installer demonstration with WAN disconnected |
| Battery expansion | Chemistry, inverter communication and warranty binding | Matched inverter/BMS interoperability list |
| Three-phase/load support | Grid and consumption numbers must align | Signed phase diagrams and commissioning results |
| Backup capability | Not every hybrid inverter supplies power in an outage | Certified backup/EPS design with transfer and allowed circuits |
Treat cloud history and local measurements as separate features
A supplier portal may offer excellent historical charts while polling data through the internet. That does not imply a local real-time interface or dependable offline operation. Conversely, a local Modbus readout may be reliable but demand technical maintenance. Prioritise verified local telemetry for the basic energy balance, and treat cloud production forecasts, remote monitoring and utility price feeds as optional higher-layer services. Do not design critical load limiting around cloud response times.
Step 3: decide whether storage is financially and operationally justified
A home battery can increase self-consumption, provide some backup value where the installation supports it, and allow limited time-of-use arbitrage. It also adds substantial cost, conversion losses, calendar/cycle degradation, installation complexity and possible restrictions on grid charging. Before buying, estimate the amount of surplus that would otherwise have been exported, the value of avoided import, export compensation, likely load timing and the battery’s realistic usable energy rather than headline capacity.
Capacity is not power. A nominal 10 kWh battery cannot necessarily sustain a 10 kW load; the inverter and battery discharge ratings determine power, and reserve/losses determine usable energy. For an illustrative 10 kWh nameplate unit operated within a usable SOC span of 80%, stored energy accessible within that window is 8 kWh before relevant AC conversion losses. At 90% discharge-path efficiency, about 7.2 kWh might reach AC loads under the example assumptions. This is not a specification for any brand.
| Battery decision | What to calculate | Frequent mistake |
|---|---|---|
| Usable energy | Rated capacity × permitted SOC window | Treating 100% of nameplate kWh as deliverable |
| Peak output | Inverter AC rating and battery BMS limits | Confusing kWh with kW |
| Solar shifting value | Avoided import minus forgone export and losses | Assuming self-use is always free |
| Grid arbitrage | Peak avoided cost versus off-peak charge cost/efficiency plus wear | Ignoring charging losses and battery ageing |
| Backup reserve | Protected load energy and surge/start constraints | Assuming any hybrid battery provides EPS power |
| Controls | Supported reserve/schedule API and offline default | Writing guessed Modbus registers |
| Whole-life cost | Installation, annual losses, service and replacement assumptions | Dividing sticker price by capacity only |
Worked solar-versus-export decision
Assume a household has 4 kWh of PV surplus available for either export or battery charging. Export compensation is £0.08/kWh; evening imported energy costs £0.30/kWh; round-trip battery efficiency is assumed to be 85%. Charging 4 kWh stores and later supplies around 3.4 kWh of avoided evening grid electricity. The illustrative avoided purchase value is 3.4 × £0.30 = £1.02. Forgone export is 4 × £0.08 = £0.32. The gross benefit of shifting is £0.70 for the event, before allocating battery degradation, inverter standby consumption and any additional transaction/tariff costs. If electricity import later costs only £0.12/kWh, that same shift’s gross benefit is £0.408 − £0.32 = £0.088. Storage value is highly sensitive to tariff and use pattern.
Battery controls should be exercised only through supported vendor interfaces. Home Assistant’s job may be simply to ask for a higher reserve before bad weather and monitor whether the vendor ESS honours that request. The BMS retains voltage/current/temperature protections, and native system operating policies should define behaviour if Home Assistant goes offline. See the site’s home battery ROI and degradation analysis for the longer economic treatment.
Step 4: choose EV charging with its own supply protection
The EV is frequently the most flexible large electrical load, but a cheap tariff or solar-surplus algorithm is not a reason to compromise safe charging. Choose the EVSE for vehicle compatibility, electrical installation requirements, weather rating, support, approved current balancing, correct phase capability and supported integrations. Then ask whether the charger offers the supervisory controls required for tariff schedules, solar following, a departure deadline and an offline fallback. A phone app that can start/stop a charger is not necessarily an open local API.
For a limited main supply, the approved dynamic load-management arrangement must measure the correct site current and reduce charging safely on its own. Home Assistant dashboards can display load but should never be the only real-time overcurrent defence. Charger vendors support different CTs, meters and communication gateways. Treat these as tested combinations, not interchangeable accessories. For selection, see smart EV chargers with Home Assistant, OCPP and tariff features and compatible dynamic EV load management.
| EV charging function | Required hardware/data | Preferred control level | Failure test |
|---|---|---|---|
| Electrically safe charging | Proper installed EVSE and applicable protective equipment | Native EVSE/protection | Disconnect HA and confirm safe charging behaviour |
| Site supply curtailment | Manufacturer-approved grid meter/CT and control path | Native EVSE/load manager | Remove meter connection and verify specified safe fallback |
| Solar surplus tracking | Trustworthy grid net-power feedback, charger power control | Supported evcc or native charger mode | Change home load while solar continues |
| Dynamic tariff charging | Supplier-specific price data, deadline and available schedule API | One supervisor, EVSE retains safeguards | Remove internet/price feed and inspect fallback |
| Charging records | EVSE measured kWh and timestamp, or validated upstream meter | Local logging | Compare charger sessions with grid/circuit totals |
| Multi-EV allocation | Aggregate load control and charger interoperability | Approved group controller | Two cars request peak current simultaneously |
| Vehicle SOC preference | Supported car API if truly available; optional | Planning only | Car API offline, driver departure deadline remains actionable |
Why solar surplus is a system-level problem
With a battery fitted, the charger and battery can compete for the same PV surplus. An inverter may absorb an extra kilowatt as soon as export approaches zero, leaving the charger seeing no surplus; a charger then stops, causing the battery to charge again. Repeated start/stop loops are poor for reliability and some vehicles. Choose a priority rule—battery first up to a reserve, EV first until its departure minimum, or a documented sharing policy. evcc explicitly provides supported solar and battery priority behaviour and is worth evaluating where the equipment matrix matches. It is not a substitute for an approved load manager; some evcc battery grid-charging behaviour is outside its normal EV load-management accounting, so read its limitations carefully.
For an illustrative 230 V single-phase charger operating at 6 A, the nominal minimum is 1.38 kW before losses and control allowances. A measured 0.8 kW surplus is insufficient for uninterrupted purely solar charging at that setting. A control system must either wait, tolerate a permitted portion of grid supply, use manufacturer-supported phase changes on appropriate equipment, or adopt another supported charging policy. Don’t claim that every EVSE supports continuously variable charging to zero or automatic phase changes.
Step 5: integrate the heat pump without losing its own intelligence
Heat pumps differ from resistive loads. Their efficiency depends on operating temperatures, outdoor conditions, cycling, defrost and hydraulic design. Simply moving all heating to a cheap hour can lower COP, increase comfort deviations or force resistance backup. The normal native heat-pump controller should manage compressor timing, pumps, freeze prevention, defrost and protective logic. Home Assistant may observe demand, electricity, supply/return temperature and supported operating mode, and potentially request gentle time-limited setpoint changes through documented interfaces.
Check the exact model and access method: official manufacturer integrations, compatible Modbus mappings, cloud portals or proprietary gateways have different maintenance and failure profiles. Even two models from the same manufacturer may provide different accessible values. The term Modbus does not promise every temperature or setpoint register is writable; a thermostat’s OpenTherm capability is not a universal heat-pump integration. Our heat pumps for Home Assistant integration guide covers the component decision in detail.
| Heat pump data/control point | What it tells you | Likely limitation | Commissioning test |
|---|---|---|---|
| Compressor running state | Activity and cycling | Device may expose demand rather than compressor status | Compare native interface and meter step changes |
| Electricity input kWh | Actual energy drawn by selected electrical boundary | Auxiliary heater/pumps may be excluded | Compare to appropriately installed circuit meter |
| Thermal output kWh | Heat delivered to water loop | Requires calibrated heat meter or valid manufacturer telemetry | Check flow, ΔT, glycol and total energy |
| Flow and return temperature | Hydraulic operating condition | Probe placement and pairing accuracy dominate small ΔT | Compare at stable operating conditions |
| Outdoor temperature | Weather/load/defrost context | Sensor placement and lag | Compare with reasonable external reference |
| Room and DHW target | User operating request | Write controls may be unsupported or cloud-only | Small approved change, then observe safe return |
| Heat-pump fault/defrost | Diagnostics and seasonal performance | Codes and event semantics vary by manufacturer | Check against service documentation |
Heat pump COP: calculated, not assumed
COP = measured thermal heat output divided by measured electrical input for the same interval and boundary. If a proper heat meter shows 18 kWh delivered across a six-hour window while a matching heat-pump electricity meter shows 5 kWh, the interval COP is 3.6. If the building consumed 5 kWh of total electricity while the heat pump alone supplied 18 kWh, that is not a valid denominator. If delivered heat is inferred only from two poorly mounted surface temperature probes, describe it as a rough estimate, not a certified COP reading.
Heat-pump and hot-water scheduling must respect manufacturer guidance for hygiene, overtemperature and backups. Thermal storage is often useful, but its economic benefit depends on additional heat losses and the COP achieved when heating earlier. In high-mass underfloor systems, gentle preheating may be effective; in lightweight buildings, aggressive preheat can simply overheat rooms and waste energy.
Step 6: build the communications and hosting layer deliberately
A dependable host is only one part of the communications chain. List every network dependency: router, switches, access points, DNS/DHCP, MQTT broker, RS-485 gateway, inverter Wi-Fi module, EVSE LAN bridge, Home Assistant host and storage. A single failed PoE switch might simultaneously remove the inverter gateway, EVSE interface and wall dashboard. Ethernet usually improves predictability for fixed hardware; Wi-Fi remains suitable for well-supported appliances with good coverage and acceptable loss behaviour. Segment interfaces sensibly without breaking device discovery or local routing.
Select Home Assistant Green for a simple always-on local hub, or an efficient SSD-based mini PC when many integrations, extra logging or auxiliary services justify the complexity. A NAS-hosted VM can be economical when it is already reliable, but shared host shutdowns and storage maintenance affect the smart-home controller. A local broker may be worth running on the same HA machine for simplicity; separating it does not automatically improve resilience unless the resulting dependencies are engineered and backed up. Refer to the site’s cloud-free energy monitoring guide when deciding on local interfaces.
| Communication route | Good fit | Reliability questions |
|---|---|---|
| Vendor-supported LAN API | Read-only local solar/charger telemetry | Authentication, rate limits, firmware changes, local DNS |
| Modbus TCP | Inverter, fixed meter and heat-pump registers | Exact device map, IP stability, simultaneous clients, polling rate |
| Modbus RTU / RS-485 | DIN-rail meters and some industrial equipment | Termination, bus addressing, isolation, line routing, qualified wiring |
| MQTT | Gateways, ESPHome devices, local event distribution | Broker uptime, retained stale payloads, state availability |
| OCPP | Supported EVSE charge-point management | Exact protocol/version, provider dependencies, authoritative controller |
| Zigbee/Thread | Selected sensors and small loads | Mesh strength, border routers/coordinators, compatibility |
| Cloud vendor service | Convenient historical/reporting functions | Availability, subscription, internet dependence and API change |
The internet-off test is necessary but insufficient
Unplug the WAN (without disabling local routing), and separately test an access-point outage, a switch outage and Home Assistant restart. If the EV charger relies on its own approved meter path, supply load management should continue. The inverter should remain within its certified settings. The heat pump must maintain protective control. A monitoring gap is tolerable; bypassed protection is not. Test how long the meter data may be stale before Home Assistant labels it unavailable, and whether the last MQTT retained value could appear as a fresh reading after a restart. Never treat unknown or unavailable power as definitely zero in a real load-shedding decision.
Home Assistant entity model: make measurements audit-friendly
Avoid beginning with YAML that turns devices on and off. Start with a documented entity register: actual device, physical measurement location, watts/kilowatts versus cumulative kWh, sign convention, phase grouping, polling interval, integration name, timestamp freshness and who owns the value. Keep the original vendor entity names in notes even if you create convenient template aliases. The Energy dashboard is a useful visual summary but it cannot repair ambiguous source measurements.
| Example entity role | Meaning | Expected type | Do not confuse it with |
|---|---|---|---|
| Grid import energy | Cumulative energy bought from grid | kWh, nondecreasing except documented reset | Net instantaneous grid power |
| Grid export energy | Cumulative energy sold to grid | kWh, nondecreasing except documented reset | PV generation or battery discharge |
| PV generation energy | Electrical production at selected PV measurement boundary | kWh | Inverter DC and AC total added together |
| Battery charge energy | Energy entering storage at known boundary | kWh | State of charge (%) |
| Battery discharge energy | Energy leaving storage at known boundary | kWh | Usable battery capacity (kWh) |
| EV charge energy | Energy at charger/circuit or vehicle, explicitly labelled | kWh | Battery SOC delta multiplied by car capacity |
| Heat-pump electricity | Electricity at selected HP circuit/system boundary | kWh | Thermal heat delivered |
| Heat delivered | Heat meter output over matched hydronic circuit | kWh thermal | Electricity from the meter above |
| Dynamic price | Applicable retail energy rate for a defined interval | currency/kWh | Wholesale price lacking taxes and charges |
Worked whole-day energy reconciliation
Assume PV generation = 24 kWh, grid import = 12 kWh, grid export = 5 kWh, battery charged = 6 kWh, and battery discharged = 4.8 kWh. Assuming that all values refer to compatible AC-side boundaries and neglecting other losses for this simplified example, household AC demand is approximately PV + grid import + battery discharge − grid export − battery charge = 24 + 12 + 4.8 − 5 − 6 = 29.8 kWh. The battery energy difference is not ‘missing’ household load: its round-trip loss, change in stored energy and measurement boundary account for the mismatch between charged and discharged kWh over a chosen day.
A second check is to add subcircuits only as a diagnostic share of that demand. If EV charging is 9 kWh, heat pump 11 kWh and other monitored appliances 4 kWh, the remaining 5.8 kWh should represent unmetered loads plus any mismatched measurement boundaries; it is not an automatic error. Conversely, if subcircuits sum to 36 kWh while inferred whole-home demand is 29.8 kWh, investigate overlapping devices, duplicate phase meters, delayed readings and AC/DC mix-ups.
| Daily example at compatible boundaries | kWh |
|---|---|
| PV AC generation | 24.0 |
| Grid imports | 12.0 |
| Battery AC discharge | 4.8 |
| Grid exports (subtract) | −5.0 |
| Battery AC charge (subtract) | −6.0 |
| Approximate household AC demand | 29.8 |
A safe Home Assistant monitoring-only example
The following is an illustrative template for a Home Assistant installation whose meter exposes sensor.house_grid_power_w, with the documented convention positive = import, negative = export. Those entity IDs are placeholders: change them to your actual sensors. It creates display sensors only, never switches any load or controls a battery. The availability checks help avoid reporting a fictitious zero during a failed meter connection.
template:
- sensor:
- name: "Grid Import Power (Advisory)"
unique_id: grid_import_power_advisory_example
unit_of_measurement: "W"
device_class: power
state_class: measurement
availability: >-
{{ is_number(states('sensor.house_grid_power_w')) }}
state: >-
{{ [states('sensor.house_grid_power_w') | float, 0] | max | round(0) }}
- name: "Grid Export Power (Advisory)"
unique_id: grid_export_power_advisory_example
unit_of_measurement: "W"
device_class: power
state_class: measurement
availability: >-
{{ is_number(states('sensor.house_grid_power_w')) }}
state: >-
{{ [0 - (states('sensor.house_grid_power_w') | float), 0] | max | round(0) }}
Test sign convention by observing a clear import event and a clear export event. The above works only if the meter uses the stated sign convention. Do not copy it for a sensor that reports export as positive or uses separately signed per-phase registers. For energy dashboards, prefer official cumulative import and export kWh registers over integration of a frequently unavailable instantaneous power sensor.
A second monitor-only data-quality helper
This template compares a site-level grid value with a battery state sensor solely to indicate whether basic upstream measurements appear numeric. It does not prove freshness or metrological correctness. For a true staleness watchdog also record the integration’s timestamp or last successful poll if available; a retained MQTT value can remain numeric long after the originating hardware disappears.
template:
- binary_sensor:
- name: "Energy Telemetry Basic Values Present"
unique_id: energy_telemetry_values_present_example
state: >-
{{ is_number(states('sensor.house_grid_power_w'))
and is_number(states('sensor.home_battery_soc')) }}
availability: >-
{{ states('sensor.house_grid_power_w') not in ['unknown', 'unavailable']
and states('sensor.home_battery_soc') not in ['unknown', 'unavailable'] }}
If no battery is fitted, omit the battery condition; do not fabricate an SOC entity. For a no-battery house, separately monitor PV and grid reporting. A data-present sensor should never be used as a permission to relax an electrical current limit.
Step 7: choose the supervisor: manufacturer app, Home Assistant or evcc
Many installations do not need a separate optimiser. If the inverter is managing self-consumption, the EVSE has an adequate solar/tariff mode and the heat pump’s own weather-compensated controller works well, Home Assistant can remain a read-only observability and alerting tool. This is often the strongest low-maintenance choice. A more sophisticated system can justify an explicit supervisor when two or more flexible loads compete, the household has genuine time-varying retail tariffs, or data shows substantial missed savings.
| Supervisor | Strongest role | Things to verify before adopting |
|---|---|---|
| Manufacturer-native inverter app | Battery/PV operating modes and warranty-compatible control | Local versus cloud access; battery/charger coexistence |
| Manufacturer EVSE scheduling | Simple charge timer and supplier tariff windows | Offline schedules, separate load-manager configuration |
| Home Assistant automations | Whole-home visibility, straightforward schedules, notifications | Device-specific writes, missed events, stale data, operator override |
| evcc | EV solar-surplus tracking with supported vehicle/meter/charger ecosystem | Device compatibility, sponsor-token rules, battery priorities, load-management boundaries |
| EMHASS or other optimiser | Cost forecast and multi-load optimisation under explicit constraints | Forecast quality, output validation, fallback and maintenance |
Use the earlier Home Assistant vs evcc vs inverter apps comparison for the platform purchase decision. Whatever the chosen supervisor, record its control scope in writing. The correct outcome of a failure may be stop cost optimisation while devices continue safely in native mode, not force every smart load off.
A simple, auditable priority policy
A reasonable illustrative policy for one house is: (1) preserve safety and supply limits; (2) maintain battery outage reserve; (3) satisfy minimum hot-water and comfort requirements; (4) ensure the EV reaches its driver’s minimum before departure; (5) consume low-cost solar where it exceeds export value; (6) use tariff windows for truly flexible loads; and (7) optimise lesser discretionary appliances only if benefits exceed wear and inconvenience. This is a preference order, not universal. A healthcare device, an occupied home requiring heating or a time-critical vehicle trip changes the priority list.
| Event | Default policy | Home Assistant’s suitable involvement |
|---|---|---|
| Main supply approaching limit | Certified curtailment/load management acts | Notify and display current conditions |
| Battery reaches reserve floor | Native ESS stops permitted discharge | Record and optionally request vendor-supported higher reserve later |
| EV departure 07:00 with insufficient energy | Charger/owner deadline takes precedence over ‘only solar’ preference | Show projected shortfall and raise alert |
| Cold spell near minimum heating comfort | Native heating protects comfort and equipment | Avoid aggressive setbacks and alert if schedule is unrealistic |
| High solar generation at midday | Charge battery/EV/DHW according to chosen owner and economics | Display surplus and request supported discretionary action |
| Price API unavailable | Stop price-driven optimisation; return to safe ordinary scheduling | Signal unavailable, keep last-known data labelled stale |
| Internet down but LAN up | Native equipment continues; local integrations may continue | Monitor locally, postpone cloud-dependent decisions |
| Home Assistant host down | Device-native protections continue | Recover logs on restoration; no unsafe catch-up commands |
Step 8: cost the system, including installation and maintenance
Price comparisons are meaningless without defining what is already fitted. An owner with a supported smart inverter and local grid meter may need little more than an existing Home Assistant machine; another property may require panel changes, approved CTs, an Ethernet gateway and a charger load-management package. Electrical labour is often a large part of installed cost. Country, installation complexity, site supply upgrade, network cabling, VAT and equipment support can move budgets dramatically. The tables below are illustrative planning models in GBP, not vendor quotations, current sale prices or installation offers.
| Illustrative hardware/software line | Entry monitoring project | Solar + EV supervision | PV + battery + EV + heat pump |
|---|---|---|---|
| Energy meter/gateway and integration allowance | £180 | £350 | £500 |
| Home Assistant host/storage | £140 | £220 | £300 |
| Network/UPS/backup allowance | £110 | £220 | £350 |
| EV charger control/integration allowance* | £0 | £650 | £700 |
| PV telemetry/inverter gateway allowance* | £0 | £180 | £200 |
| Battery telemetry/interface allowance* | £0 | £0 | £150 |
| Heat-pump data/approved integration allowance* | £0 | £0 | £200 |
| Installation and commissioning allowance | £200 | £600 | £1,000 |
| Illustrative integration project total | £630 | £2,220 | £3,400 |
These are allowances for integration-related equipment and selected charger hardware where indicated. They do not include the cost of installing a new PV array, purchasing a home battery, buying a heat pump, major electrical supply upgrades or building fabric improvements. Those core capital projects can dominate the full system cost. A property with already-integrated equipment may need far less; a complex three-phase retrofit may need much more.
Five-year ownership: do not stop at the invoice
Add host electricity use, approved software licensing where applicable, cloud subscriptions if chosen, occasional replacement of gateway power supplies, network equipment, software support and data backup. A well-chosen local meter needs comparatively little ongoing cost. A proprietary service that requires recurring access fees may be cheaper to install but more expensive to operate. Compare cost of ownership in the same currency and tax treatment as the household’s actual bill.
| Annual ongoing item | Illustrative low | Illustrative high | How to make it real |
|---|---|---|---|
| Hub + gateway + switch electricity | £10 | £70 | Measure continuous power and multiply by tariff |
| Optional subscription/licensing | £0 | £100 | Check actual provider and plan |
| Storage/backup replacement allowance | £5 | £40 | Budget for SSD, gateway or UPS-battery replacement |
| Routine support/maintenance allowance | £0 | £150 | Include paid support only where truly needed |
| Annual illustrative total | £15 | £360 | Sum the verified site-specific figures |
| Five-year running allowance | £75 | £1,800 | Excludes new PV/EV/battery/heat-pump capital |
These bounds describe different assumptions, not a forecast that one specific household will pay all listed costs. UPS battery life varies with model, heat and duty. For a 12 W always-on incremental control system, annual electricity is approximately 12 × 24 × 365 / 1,000 = 105.1 kWh, or £26.28 at an assumed £0.25/kWh. The economic question is whether the site actually shifts enough useful energy, prevents enough unnecessary imports or creates enough operational value to exceed these costs.
Step 9: evaluate savings from a baseline, not marketing percentages
A system that increases self-consumption by 10 percentage points has not necessarily cut electricity cost by 10%. Export credits, time-of-use prices, battery conversion loss, marginal heat-pump COP and fixed standing charges determine the financial result. Track energy flows and cash effects separately. Compare matched periods adjusted for weather, occupancy, EV travel and changes in tariffs; otherwise a sunny month may be credited to the automation rather than the season.
Illustrative EV shifting: shift 12 kWh of electricity purchased from an expensive interval at £0.30/kWh to a cheaper interval at £0.12/kWh. Ignoring changes in charging efficiency, the gross reduction is 12 × (£0.30 − £0.12) = £2.16 per session. Thirty similar sessions would create £64.80 of gross difference. It is not valid to multiply this by every day of the year unless there really are that many comparable charge sessions, and the car would otherwise have charged at the high rate. If 12 kWh is the energy delivered to the vehicle rather than bought at the wall, account for wall-to-battery losses in both intervals.
Illustrative preheating: a heat pump normally supplies 10 kWh thermal at COP 3.5, using 2.86 kWh electrical. If a price-based preheat schedule delivers the same 10 kWh thermal at COP 2.8, it needs 3.57 kWh electrical. An off-peak electricity price 20% below the previous rate does not always deliver a saving; compare 2.86 × peak rate with 3.57 × off-peak rate, plus any extra building heat loss. Comfort, weather and DHW requirements may matter more than the cheapest hour.
| Optimisation | Gross economic opportunity | What erodes the saving | Proof required |
|---|---|---|---|
| EV shift to cheaper tariff | kWh bought × price difference | Charge losses, missed deadlines, tariff conditions | Session kWh and actual billed prices |
| Use PV instead of export | Avoided import minus export value | Timing limits, inverter efficiency, opportunity cost | Grid import/export against PV production |
| Battery arbitrage | Avoided expensive imports | Round-trip loss, ageing, standby and constraints | Matched charge/discharge energy and costs |
| Heat-pump preheat | Avoided expensive-hour electrical consumption | Lower COP, building thermal loss, comfort deviations | Delivered heat and electricity over matched periods |
| Appliance smart plug | Avoid standby and shift supported operation | Plug power, device wear, manual inconvenience | Metered standby watts and realistic event count |
| Demand alerts | Avoid avoidable simultaneous peaks | No value unless action follows | Measured peak/current and actual load response |
Savings sensitivity matters more than extra sensors
If a control system costs £500 to add and gives a verified net annual benefit of £50, simple payback is 10 years before replacement and discounting. If it produces £100/year, payback is five years. If it gives only £20/year, payback extends to 25 years. Never imply a fixed annual saving merely because Home Assistant can issue a schedule. Run a conservative, base and optimistic case with explicitly stated assumptions. Most buyers should upgrade only after seeing a persistent opportunity in their own meter history.
Step 10: commissioning plan: measure, observe, then authorise bounded control
Commission the system in stages. Electrical installation, protection settings, heat-pump commissioning, battery interfaces and EVSE current settings belong to qualified installers following local rules and manufacturers’ documentation. Software changes should be made only after a baseline is available. Do not commission a charger or inverter by disconnecting protection conductors, probing live switchgear, bypassing BMS interlocks or issuing undocumented Modbus writes.
| Stage | Acceptance test | What counts as failure |
|---|---|---|
| 1. Site survey | Confirm supply, phases, grid approvals, equipment labels and manufacturer manuals | Missing or ambiguous electrical/protection records |
| 2. Meter commissioning | Import/export signs, phase mapping and accumulated kWh agree within stated tolerances | Export shows as import, negative load where impossible |
| 3. Data freshness | Each source has documented reporting frequency and unavailable condition | Stale numeric value displayed as live indefinitely |
| 4. Energy accounting | Dashboard totals reconcile with utility and inverter counters over a sensible interval | Unexplained duplicate energy or large systematic residual |
| 5. Native autonomy | Charger, inverter, battery and heating remain safe with HA disconnected | Protective operation relies on HA automations |
| 6. Network fault tests | WAN-only, AP, switch, DNS, broker and HA failures tested separately | Unclear control state, no safe fallback |
| 7. Observer-only trial | At least one representative heating/solar/EV cycle logged before writes | Schedule changes introduced without baseline |
| 8. Supported bounded commands | One command owner, documented setpoints and manual override tested | Two writers fighting or unsupported mode changes |
| 9. Optimisation trial | Real costs, comfort and departure success compared with baseline | Claimed savings without matched measurement |
| 10. Backup and handover | Restore tested, credentials/diagrams stored safely, rollback understood | Recovery depends on memory or unbacked-up laptop |
A four-week commissioning sequence
Week 1: establish metering, record site diagrams, check utility readings, energy sensors, dashboard direction and time zones. Avoid any advanced price-driven control. Week 2: run representative EV charging, heating and solar cycles; examine phase loads, battery behaviour and PV/grid accounting. Capture network disruptions and identify how long unavailable states remain unreported. Week 3: enable one supported supervisory function (such as a native EV charging schedule) with a manual override, then compare measured results to a rules-free baseline. Week 4: test fallbacks, confirm energy savings net of export, check user comfort and hand over a one-page operations document. A more complex home may require an entire season for credible heat-pump performance analysis.
Failure injection: the tests that uncover expensive surprises
| Injected fault | Expected behaviour | What to observe |
|---|---|---|
| WAN disconnected, LAN intact | Native protection and local device operation remain normal | Remote portals/price feeds fail cleanly |
| Home Assistant stopped | Meter, inverter, EVSE and heat pump remain independently safe | No hazardous latched command or unplanned catch-up |
| MQTT broker restarted | Missing/stale entities identified; no bogus zero-demand assumption | Retained values distinguished from current events |
| Grid meter gateway unplugged (simulation with installer support) | Certified EV load manager follows its specified fault mode | Charger response does not rely on HA |
| PV production disappears during charging | Native charger control adjusts or stops according to policy | Import increases only within permitted site limits |
| Battery reaches protected reserve | ESS honours reserve and BMS limits | Supervisor records outcome, does not force discharge |
| Heat pump enters defrost | Native heating controller retains full authority | Telemetry shows normal protective cycle |
| Router/DHCP restarts | Devices recover without unexpected control changes | IP addresses, polling and history restore |
| Tariff feed contains stale price | Optimisation suspended or falls back to ordinary plan | No unbounded charging triggered by old price |
| Utility reports unexpected negative export price | Economic rule evaluated using actual applicable tariff | User preference and hardware limits still honoured |
Five realistic household architectures
1. Existing flat, no PV, one electricity meter
Start with an accessible supply meter or a supported small number of monitoring plugs and a Home Assistant Green or already-owned suitable controller. Add the Energy dashboard and utility-bill verification. If there is no controllable EV, electric hot-water load or meaningful time-of-use differential, a complex optimiser has little financial value. The correct next purchase may be no purchase at all until monitoring shows a relevant opportunity.
2. Rooftop PV and a single EV
Use the inverter’s compatible local telemetry and an approved bidirectional grid meter. Buy an EVSE that can provide independently safe site load management. Nominate one solar-surplus control owner—charger-native software or a supported evcc setup. Start with grid import/export plus charger-session kWh. Check whether noon surplus regularly exceeds the charger minimum; if it does not, continuous solar-only charging will not work well, regardless of dashboard quality.
3. PV, home battery and two EVs
The battery and vehicles are three competing flexible resources. Keep battery reserve and native ESS settings authoritative, and use an approved charger group controller for aggregate site-current constraints. Set a documented hierarchy such as household battery to 50%, then one EV’s departure minimum, then additional opportunistic EV charging. Expose the priority to household users as a simple switch or selection, but do not let a decorative HA toggle override certified limits. Time-of-use and export calculations should be net of storage losses and support costs.
4. Heat pump and domestic hot water, with or without solar
Protect the manufacturer’s weather compensation, compressor safeguards, frost protection and hot-water hygiene programme. The best initial investment may be a dedicated electrical meter, access to flow/return telemetry and a properly validated heat-output sensor rather than a more complicated controller. Monitor enough weather variation to see whether preheating or a DHW schedule helps. If a heat-pump connection is cloud-only, local integration may be limited and should not be guessed from another model in the brand family.
5. Whole-house new build: PV, battery, two EVs and underfloor heating
Design the communications, electrical metering and native controllers before installing finishes. Reserve wiring routes and space for approved meters, Ethernet gateways, suitable network switches and a UPS. Put all data points and owner/fallback conditions on a single commissioning sheet. Consider a dedicated heat-pump electricity meter, hydraulic heat-output meter and individual EVSE meter if ROI and maintenance analysis matter. Plan backup circuits separately from the normal distribution. Only buy a multi-load optimiser after operating constraints and priorities are fully agreed.
| Household profile | Best starting investment | Later upgrade if evidence supports it | Avoid buying prematurely |
|---|---|---|---|
| Basic grid-only home | Accurate kWh data and dashboard | Limited discretionary-load scheduling | Battery, heavy server, elaborate optimiser |
| Solar without battery | PV/grid telemetry and export economics | Supported hot-water/EV surplus use | Storage based only on ‘free solar’ slogan |
| PV plus one EV | Charger with approved load management | evcc or native solar tracking | Unapproved generic CT substitution |
| PV and battery plus EV | ESS data and explicit priority policy | Coordinated schedule with verified net benefit | Conflicting inverter/charger/HA writers |
| Heat-pump house | Native heat controls and electric/thermal metering | Conservative DHW/preheat optimisation | Hard on/off cycling through a smart plug |
| Full new build | Metering architecture, cables, approved controls, UPS | Whole-home optimisation after baseline | Custom safety-critical PLC-by-dashboard logic |
Buying checklist: ask these questions before paying
For every energy device, record the exact model, revision and firmware. Request current manufacturer installation and integration documentation. Identify what continues to operate without cloud access, what is readable locally, what is actually writable, whether a gateway is required, and whether additional subscriptions apply. Confirm the installation’s electrical compatibility and regional warranty. If the dealer cannot answer which meter is approved for inverter export control or EV supply load management, that is a better reason to pause than an attractive discount is to proceed.
For meters, request import/export cumulative counters and phase-level accuracy where appropriate, not just a graph. For batteries, request a clear BMS/inverter interoperability statement, usable energy window and backup circuit design. For EV chargers, obtain approved load-balancing hardware, offline operating policy and supported control protocol. For heat pumps, ask for local data, flow/return instrumentation and approved setpoint interface, while preserving native protective logic. For the control host, obtain a tested backup and restore procedure and a documented UPS power tree.
| Purchase item | Minimum evidence to request | Reason to reject or pause |
|---|---|---|
| Grid meter | Qualified installer approval, topology and register documentation | No import/export distinction or incompatible CT/phase input |
| PV inverter | Grid-compliant installation, vendor telemetry documentation | Cloud-only control claimed to be real-time LAN access |
| Battery | BMS pairing, permitted reserve control, warranty and EPS topology | Undocumented register writes or impossible backup expectations |
| EV charger | Certified fitting, supported dynamic load manager and actual phase capacity | Marketing ‘smart’ but no verified current control/fallback |
| Heat pump | Native control documentation and monitoring access | Requirement to defeat safeties or power-cycle the compressor |
| HA host | Supported deployment, storage and backup procedure | Single removable memory card with no tested restore |
| Network/UPS | Measured power chain and physical topology | UPS supplies host but none of its essential data gateways |
| Optimiser | Supported device list and explicit control ownership | Several competing writers or claims of guaranteed savings |
Common integration mistakes and how to diagnose them
The energy dashboard shows impossible consumption. Check whether inverter DC production and AC production were added together; whether a battery’s charge and discharge counters are both counted as household usage; or whether an EV charger sits under an upstream monitored circuit. Validate against separate import/export readings rather than editing the displayed graph until it looks right.
EV charging keeps starting and stopping under solar surplus. Inspect minimum charge current, three-phase configuration, the grid meter sign and location, charger/battery priority, polling delay and switching hysteresis. Where an inverter’s battery rapidly absorbs surplus, a charger may not see export. Do not cure oscillation by overriding the supply limit or disabling manufacturer protections.
A battery unexpectedly discharges into the vehicle. Review native battery reserve and any evcc/inverter charger priority settings. Confirm whether a supposed ‘solar-only’ setting means genuinely zero grid draw, or permits battery support or a configurable solar share. The documented evcc battery priority and support functions are particularly relevant.
Heat-pump electrical consumption looks higher after optimisation. Measure delivered heat, not merely daily kWh. Check whether aggressive setpoint boosts reduce COP, whether hot-water heating invokes an immersion element, and whether extra preheating increases building losses. Compare days of similar weather and occupancy.
The dashboard freezes after an internet outage. Separate WAN dependency from LAN failure. Confirm whether the integration is local, whether the vendor device is still accessible, whether DNS changed, whether the MQTT broker is up and whether a retained last-known value is being displayed as live. Restore monitoring before allowing cost-driven changes.
Daily import differs from the utility bill. Confirm the meter’s physical boundary, time zone and supplier settlement intervals. Compare import with import and export with export; do not net away import/export within a sampling interval. Review tariff tax, export credits and standing charges separately from energy data. A display can be internally consistent and still disagree with the billed meter because of timing, phase aggregation or calibration.
Frequently asked questions
1. Do I need Home Assistant if my inverter and EV charger have apps?
Not necessarily. If those native systems meet your needs and keep reliable records, Home Assistant may offer only convenience. It earns its place when you need trustworthy cross-brand reporting, local alerting or coordinated schedules that the native apps do not provide.
2. Is a cloud-free system automatically more reliable?
No. Local protocols reduce internet dependence but still require well-powered gateways, networking, updates and backups. Reliability depends on the entire chain and how equipment behaves when any component fails.
3. Can Home Assistant perform main-supply load balancing for my EV?
It can report and request charging changes, but it should not be the sole safety-critical limiting system. Use an installer-commissioned, manufacturer-approved EVSE/load-management arrangement for supply protection.
4. Which is the most important energy meter?
The meter at the grid connection normally provides the best reference for household import/export and solar-surplus decisions. It must be the correct meter for the physical supply and any manufacturer-native control requirements.
5. Do I need both grid and PV meters?
To distinguish production from grid exchange, yes: use independent or manufacturer-derived measurements for both roles. An inverter may report grid data from its approved external meter, so two physical instruments are not always necessary.
6. Can I add battery charge and discharge energy to total household consumption?
No. Those are energy storage flows, not extra consumption to add indiscriminately. Use a consistent balance at compatible boundaries and account for losses and stored-energy changes.
7. Can a 10 kWh battery run a 10 kW load for one hour?
Not necessarily. The inverter and BMS must permit 10 kW output, and the usable energy window and conversion losses may limit runtime. kWh and kW describe different things.
8. Does Modbus mean the inverter can be fully controlled?
No. Modbus exposes whichever data points the vendor publishes for the particular model and firmware. Many devices are partly or entirely read-only, and unsupported writes can undermine reliability or warranty conditions.
9. Should I choose OCPP for an EV charger?
Choose OCPP only if the exact charger, OCPP version and chosen controller support the functions you need. OCPP support does not by itself guarantee local solar tracking, installer-approved site load control or vehicle SOC access.
10. Does EV ‘solar-only’ charging always avoid grid electricity?
No. The result depends on charger minimum current, meter position, control delay, battery interaction and the system’s definition of solar share. Some setups intentionally blend a small amount of grid power.
11. Do I need a battery to use my own solar power?
No. Daytime loads, hot-water heating and suitable EV charging can consume PV directly. Storage is mainly useful for shifting energy or providing supported backup, and should be justified economically and technically.
12. Can my heat pump be treated as a smart plug load?
No. A heat pump relies on its own compressor, defrost, pump and temperature protection. Use approved control interfaces and preserve the manufacturer’s internal logic.
13. What is the simplest way to start saving money?
Verify the tariff and measurement first, then shift a genuinely flexible load using native scheduling. Confirm the saving using the actual meter history rather than assuming an automation produces savings just because it runs.
14. Does a higher home battery SOC mean lower household cost?
Not necessarily. Charging early can forgo valuable export or inexpensive later solar; holding unnecessary reserve may reduce self-consumption. Optimise against actual risk preferences, tariffs, conversion efficiency and native constraints.
15. What happens if Home Assistant crashes overnight?
Properly designed native inverter, BMS, EVSE and heating controllers continue to enforce their protections. Optional price optimisation and central dashboards may stop until recovery. A documented fallback and backup are more important than instantaneous remote restart.
16. Should I run Grafana or InfluxDB for this system?
Only when you need analytical history and time-series detail beyond Home Assistant Recorder and its long-term statistics. Grafana is a visualisation tool, not a substitute for a database; InfluxDB is separate telemetry storage, not a replacement for Recorder.
17. How do I check that savings claims are genuine?
Use actual import/export and load energy over comparable time windows, subtract export opportunity cost, conversion losses and extra equipment running costs, and compare to a credible baseline. Include comfort and vehicle readiness rather than judging money alone.
18. Can an ESP32 replace commercial metering and safety hardware?
An ESP32 is excellent for a supported low-voltage observation, telemetry or interface project, but it should not substitute for certified utility metering, grid protection, an approved EVSE current limiter, battery safety or heat-pump protective controls. Refer to the site’s specialised hardware tutorials for supported projects and isolation requirements.
19. Is three-phase home energy optimisation much harder?
It is more demanding to validate because phase mapping, current limits, single-/three-phase loads and vendor metering aggregation all matter. A well-engineered three-phase installation can work very well, but a nominal whole-house kW total does not prove every phase remains within its current rating.
20. What should I buy first if I eventually want PV, battery, EV charging and a heat pump?
Begin with the whole-building electrical and network design, adequate distribution-board provisions and reliable bidirectional metering. Choose inverter and charger ecosystems with documented compatible gateways and safe native controls. Only then pick a supervisor and optional battery optimisation.
Final recommendation: architecture first, optimisation second
A good complete energy system has one coherent grid boundary, a trustworthy record of solar and battery flows, an EVSE with its own approved load management, a heat pump with intact native protection, and a modestly sized local monitoring host. It uses supported data interfaces, not speculative register writes; it has one ordinary writer per control point; and it degrades safely during internet, LAN or Home Assistant outages. It can tell you what happened yesterday and why a schedule saved—or cost—money.
For the buying sequence, begin with an accurate meter and verified local data. Add the Home Assistant Energy dashboard and reconcile it against the supplier bill. Bring solar and battery readings into the same clearly defined physical boundary. Choose the EVSE and heat-pump integrations for the exact installed models, not promises of generic compatibility. Finally, apply one bounded automation at a time with manual override, a measured baseline and a rollback plan. An installation that reliably avoids one unnecessary charging period is more valuable than a complicated optimiser nobody can safely maintain.
Official technical documentation and further reading
- Home Assistant — home energy management: official Energy dashboard concepts and required entities.
- Home Assistant — integrating your electricity grid: import/export measurements and grid source configuration.
- Home Assistant — integrating individual devices: monitored devices and upstream relationships.
- Home Assistant — Fronius integration: supported local Solar API, optional Modbus and device limitations.
- Home Assistant — Modbus integration: supported device interfaces, register configuration and installation context.
- evcc — solar surplus charging: control behaviour, minimum surplus and battery interactions.
- evcc — home battery: priority controls, supported grid charging and key limitations.
- evcc — PV, battery and grid metering: role assignment and supported devices.
- Home Assistant — Utility Meter: period-based energy accounting and tariff structures.
- Home Assistant — Recorder: storage, retention and recorded statistics.
