Quick Summary (TL;DR)
Choose Home Assistant when you need broad integration and visibility across many brands; choose evcc when coordinated EV charging is the central problem; and retain the inverter manufacturer’s own controls for safety-critical battery and inverter operation. These systems can work together. None should be assumed to replace a grid-compliant inverter controller, charger protection functions or installer-commissioned export limits.
For a home with rooftop solar, a battery, an EV and a hot-water cylinder, the best architecture is often inverter app for commissioning and warranty settings + evcc or charger-native logic for EV charging + Home Assistant for monitoring and non-critical household automations. Simpler homes may need only one or two of these layers. The right choice depends on available local interfaces, supported hardware, electricity tariffs and what continues to operate if the internet or Home Assistant fails.
What each system actually does
Home Assistant is a general-purpose smart-home platform with integrations, dashboards, automations and an Energy dashboard. It can collect power and energy data, apply tariffs, schedule appliances and coordinate devices that expose supported controls. It is not, by itself, a certified power-management device or a guarantee of local connectivity.
evcc is specialist energy-management software focused on optimising charging for electric vehicles and related flexible loads. It uses configured site meters, tariffs, chargers and vehicle integrations to decide when and how much to charge. Supported features, integrations and any licensing or sponsorship requirements depend on the current release and device; check the official documentation before buying hardware.
Inverter apps are the monitoring and configuration interfaces supplied with solar inverters and hybrid battery systems. They may provide export limitation, battery reserve, operating modes, time-of-use charging and vendor-specific energy flows. Their local and cloud interfaces vary by model, region, firmware and installer permissions.
| Decision | Home Assistant | evcc | Inverter app |
|---|---|---|---|
| Primary purpose | Whole-home visibility and automation | EV charging and energy-aware load control | Solar and battery operation |
| Multi-brand reach | Broad, integration dependent | Broad for supported charging/meter devices | Usually vendor ecosystem |
| Typical local operation | Often possible, device dependent | Often possible, integration dependent | Varies widely |
| Battery safety and BMS | Observe and request supported modes only | Observe and coordinate supported controls | Manufacturer-approved controls remain authoritative |
| EV charging | Automations and charger integrations | Dedicated charging optimisation | Sometimes basic charging features |
| Internet outage | Local integrations can continue | Local integrations can continue | Cloud app may be unavailable; inverter normally continues |
| Setup burden | Medium to high | Medium; hardware compatibility critical | Usually easiest for supported equipment |
Choose by the job, not the brand
One inverter, no EV, no smart loads
Start with the manufacturer’s monitoring and scheduling functions. Confirm whether its data can be read locally, whether export limitation is configured independently of the cloud and whether you need additional monitoring at all. A separate server adds power consumption, maintenance and failure modes. If the app already meets your reporting and battery-reserve needs, a second platform may add little value.
Solar PV and one smart EV charger
A charger with a supported meter and proven solar-surplus mode may be the lowest-maintenance option. evcc becomes attractive when tariff optimisation, multiple cars, charger selection or mixed-vendor equipment complicate the problem. Home Assistant can supply a dashboard and occupancy or departure information, but do not make a generic automation the only protection against exceeding the service limit.
Solar, home battery and two EVs
Separate power safety from optimisation. Let approved equipment enforce the supply limit and inverter constraints. Use evcc if its specific chargers, cars, meter and battery integrations support the intended prioritisation. Use Home Assistant for cross-system visibility and less urgent loads. Test that a second vehicle plugging in cannot defeat the charge-current allocation.
Heat pump, hot-water cylinder and flexible appliances
Home Assistant often has the broader device and scheduling coverage. Use supported heat-pump interfaces and the manufacturer’s temperature and hygiene controls. A hot-water immersion diverter should have its own certified power control and thermostatic safety arrangements. evcc may also manage selected flexible loads, but verify the current feature set rather than assuming every appliance is supported.
Off-grid or backup-oriented household
Prioritise the inverter’s approved reserve, islanding, generator and battery-protection functions. Treat third-party optimisation as advisory and fail-safe. Home Assistant cannot substitute for anti-islanding protection, battery-management logic or transfer-switch interlocks. Document what happens when the automation host reboots during an outage.
Architecture: where to put the decision-making
A robust system has four layers. The electrical protection layer contains breakers, RCDs where required, charger protections, certified export limits, battery BMS and inverter controls. The equipment-control layer contains native charger load balancing and approved battery/heat-pump control. The optimisation layer chooses charge windows, targets and load priorities. The visibility layer records measurements and explains the outcome. Place safety constraints below software optimisation so a failed script cannot defeat them.
| Layer | Responsible equipment | Failure behaviour to require |
|---|---|---|
| Electrical limits | Approved charger, inverter and protective equipment | Remain enforced without home server |
| Battery operation | BMS and inverter controller | Maintain reserve and protective limits |
| EV optimisation | evcc or supported charger-native controller | Defined current and schedule fallback |
| Household scheduling | Home Assistant or vendor controls | Manual operation remains available |
| Reporting | Home Assistant Energy dashboard and meter history | Missing data is labelled, not fabricated |
Avoid two independent systems writing the same EV charging current, inverter battery mode or hot-water schedule. A controller conflict can produce repeated starts and stops, unexpected imports and misleading savings. Assign one clear owner to each writable control. Read-only monitoring can be shared more freely.
Metering is the foundation
Before choosing software, identify the physical measurements available at the grid connection, solar inverter, battery and EV charger. For surplus charging, the important signal is normally net grid import/export measured at the appropriate point, with correct sign and phase handling. An inverter’s PV-generation figure is not a substitute for net export: the house and battery may consume the solar output first.
A three-phase household needs particular care. Some equipment responds to the sum of phase powers, while electrical supply and charger constraints can apply to individual phases. Check whether the chosen meter and charging system handle asymmetric phase loading, minimum current and phase switching correctly. Never assume a meter with a Modbus port is compatible merely because the software supports Modbus in general.
| Measurement | Why it matters | Common trap |
|---|---|---|
| Grid import/export power (W) | Controls surplus and import caps | Wrong CT orientation or sign |
| Grid imported/exported energy (kWh) | Billing reconciliation | Treating instantaneous power as energy |
| PV generation (W/kWh) | Production and self-consumption | Confusing generation with available surplus |
| Battery power and SoC | Charging priority and reserve | Different positive/negative sign conventions |
| EV charge power and state | Departure readiness | Vehicle sleep or delayed API updates |
| Tariff price and validity | Optimisation cost | Wrong time zone, units or stale feed |
Use the Home Assistant Energy dashboard entity guide to avoid double counting. Verify imported energy against the utility meter over a representative period, especially if sensors reset or integrations report cumulative counters inconsistently.
Local APIs, cloud services and offline resilience
“Works with Home Assistant” is not synonymous with “works locally”. Some integrations call a vendor cloud, require an account, poll slowly or expose only monitoring. A product may offer a local protocol but reserve commissioning or write permissions for an installer. Confirm the exact hardware revision, firmware, regional variant, gateway and supported commands before committing to a platform.
| Interface | Strength | Caution |
|---|---|---|
| Modbus TCP/RTU | Often useful for inverter and meter telemetry | Register map and writable registers are model-specific |
| MQTT | Efficient local messaging where supported | Topic semantics and retained commands need careful handling |
| Local HTTP/API | Good integration without cloud | Authentication and update compatibility vary |
| OCPP | Standardised charger-management protocol in supported equipment | Version and supported profiles matter |
| Vendor cloud API | Convenient access without local gateway | Internet, account, quotas and service changes |
| Matter/Thread/Zigbee | Local control for selected smart-home devices | Not a universal solar inverter or EV interface |
For a resilient design, test with the internet disconnected, then with Home Assistant stopped, then with the evcc host stopped. Record whether charging continues safely, whether the battery keeps its reserve and whether manual operation is possible. A dashboard that becomes unavailable is an inconvenience; a charger that exceeds an electrical limit is unacceptable.
Home Assistant: strengths and limitations
Home Assistant excels when a single screen must combine solar generation, household consumption, battery state, heat-pump telemetry, tariff prices and room conditions. Its automation engine can coordinate equipment with different APIs. The Energy dashboard is designed for historical accounting, not a sub-second protective control loop. A general automation that polls every minute may be too slow for some dynamic electrical constraints.
The cost is complexity. Entity availability, recorder retention, API changes, automation restarts and template unit errors can all affect outcomes. Treat missing values as unknown rather than zero. Use explicit hysteresis and minimum run times for flexible loads. Keep vendor control modes documented so a Home Assistant automation cannot fight a native schedule.
Example: read-only site health checks
Create a dashboard showing grid power, PV output, battery SoC, charger status, electricity price, last update time and controller availability. Add alerts for stale meter values and sustained unexpected imports. Begin with observation for at least a week before allowing any automated write commands. That baseline exposes incorrect sign conventions and normal household variability.
evcc: where a dedicated charging controller helps
A dedicated EV optimiser can evaluate available surplus, charging targets, tariffs and charger capabilities together. This is especially valuable when a vehicle has a departure deadline, solar production changes rapidly or several cars compete for limited current. The benefit depends on supported devices and reliable meter feedback; an unsupported charger can reduce the system to crude on/off switching or no control at all.
Before selecting evcc, verify your charger model, firmware, vehicle integration, site meter, battery integration and whether the desired features are available under the current project’s sponsorship or licensing arrangements. Do not rely on an old comparison article for pricing or feature eligibility. The official evcc documentation and project website are the appropriate starting points.
Worked surplus example
Suppose solar generation is 5.2 kW, house demand excluding the EV is 1.4 kW and the battery is charging at 1.0 kW. Available surplus is approximately 5.2 − 1.4 − 1.0 = 2.8 kW, before conversion losses and metering delays. On a nominal 230 V single-phase circuit this corresponds to about 12.2 A. An EVSE generally has a minimum permitted charging current and the charger/vehicle combination may not follow a request instantly. A controller must apply its supported minimum, current step, phase configuration and hysteresis rather than blindly writing 12.2 A.
If a kettle adds 2 kW of household demand, surplus drops to around 0.8 kW. A solar-only policy may pause charging, while a minimum-current or tariff-assisted policy may import some grid power. Neither outcome is universally “correct”: it depends on the user’s objective and equipment limits. Electrical overload protection must remain independent of this economic choice.
Inverter apps: useful native controls, limited portability
The inverter’s own interface is often best for installer-commissioned parameters, backup reserve, approved battery operating modes and firmware maintenance. Some manufacturers offer well-documented local telemetry; others require cloud portals or optional data loggers. Even within one brand, supported functions differ by inverter family, battery type and regional grid code.
Avoid setting export limits or changing battery-protection parameters through unofficial write registers. A third-party controller may request a supported battery mode, but the inverter and BMS must retain authority over safe operation. If warranty support matters, document any integration and confirm whether the manufacturer supports it.
Total cost: a realistic five-year comparison
Software licences are only one line item. Include a reliable always-on host, supported meters, network equipment, installer labour, gateway replacements, subscriptions and your time maintaining integrations. A cloud-free setup may reduce subscriptions but increase setup and support effort. Conversely, a vendor app can be low cost until a second brand or new EV requires a separate ecosystem.
| Cost item | Home Assistant route | evcc route | Inverter-app route |
|---|---|---|---|
| Software | Core platform available without licence fee; add-ons vary | Check current sponsorship/licensing for features | Often included; premium services may vary |
| Host | Existing HA host or dedicated device | Supported host/container/compatible platform | Usually vendor logger and phone/browser |
| Meters/gateways | Depends on device integrations | Compatible grid/charger meters often crucial | May be bundled or proprietary |
| Setup effort | Cross-device configuration and testing | Site topology and charger setup | Often lowest within one brand |
| Ongoing maintenance | Automations, integrations and backups | Integration updates and charger changes | Vendor firmware and cloud account |
| Expansion | Strong across many categories | Strong for supported charging ecosystem | May be limited outside brand |
Illustrative planning example, not a price quotation: if a separate host and networking consume 8 W continuously, annual electricity use is 0.008 kW × 8,760 h = 70.1 kWh. At £0.25/kWh that is about £17.52 per year, or £87.60 over five years before tariff changes. A host already running Home Assistant may have little incremental electricity cost; buying another dedicated machine could be unnecessary. Use local electricity rates and measured power to build your own comparison.
How to avoid duplicate control and double counting
Decide which controller owns each setpoint. For example, an approved inverter controller owns battery reserve, evcc owns EV charging targets, and Home Assistant owns discretionary appliance scheduling. Configure the other platforms to observe those states without issuing competing commands. If the inverter has its own timed battery charging and Home Assistant sends a different battery schedule, choose one source of truth.
Keep a diagram of each meter location and sign convention. Grid import, PV production and battery charge/discharge must reconcile physically. If the inverter app reports “self-consumption” differently from Home Assistant, inspect definitions before declaring one inaccurate. Some figures are instantaneous; others are daily totals or estimates with different sampling intervals.
Practical deployment plan
Step 1 — Audit existing hardware
List inverter, battery, charger, vehicle, meter and heat-pump model numbers, firmware and network interfaces. Identify whether data is local, cloud-only or not exposed. Check the installation manuals and region-specific support lists.
Step 2 — Map energy flows
Draw the grid meter, PV, battery, EV charger and flexible loads. Verify where CT clamps or meters sit and whether three-phase aggregation is required. Compare live values with physical loads and the utility meter.
Step 3 — Pick one charging authority
Choose the charger’s native control or evcc for EV optimisation. Use Home Assistant to supervise or supply high-level requests only when the integration explicitly supports that arrangement.
Step 4 — Add Home Assistant monitoring
Import supported entities, set units correctly, configure long-term statistics and build a dashboard. Record several days of baseline data before adding automations.
Step 5 — Configure failure behaviour
Disconnect cloud access, stop the automation host, interrupt meter data and simulate device restart under controlled conditions. Confirm safe charging and documented battery behaviour.
Step 6 — Measure results
Track imported kWh, exported kWh, EV delivered energy, missed departure targets, comfort and maintenance incidents. Compare like-for-like periods; weather and driving habits can overwhelm apparent software savings.
Common problems and how to diagnose them
| Symptom | Likely causes | First check |
|---|---|---|
| Solar charging imports from grid | Meter lag, minimum current, battery priority | Grid meter placement and current limits |
| Battery drains to charge the EV | Controller cannot distinguish battery discharge | Battery policy and meter availability |
| Charging starts and stops repeatedly | No hysteresis or competing schedules | Single control owner and minimum dwell time |
| HA and inverter totals disagree | Different sign, boundaries or sampling | Raw meter registers and accounting period |
| Cloud outage breaks automation | Cloud-only integration | Local API support and native fallback |
| Three-phase load exceeds expectation | Wrong phase assumptions | Installer verification of phase measurement |
| Prices produce odd schedules | Time-zone or p/kWh versus £/kWh error | Timestamp and currency units |
| Control fails after firmware update | API or permissions changed | Release notes and read-only health checks |
Deep-dive buying guide: what “energy management” really means
The three options are often compared as if they were interchangeable products, but they operate at different layers. A dashboard records what occurred; a controller selects a desired outcome; a compliant inverter, EVSE or energy-management device enforces what it is allowed to do. A Home Assistant automation cannot become the property’s electrical protection merely because it can read a smart meter. Likewise, an attractive inverter app does not necessarily control a third-party EV charger. evcc is a powerful charging optimiser, not a blanket guarantee that every solar inverter, vehicle, heat pump and battery can be commanded in every operating mode.
The purchase decision starts by documenting the existing assets and identifying an unmet need. Is the problem poor visibility, unnecessary battery discharge to an EV, expensive overnight charging, limited supply current, or the inability to coordinate devices from different manufacturers? Each problem has a different least-complex solution. One well-configured charger-native solar mode can outperform a fragile collection of five integrations if the household has only a single car and a simple electricity tariff. Conversely, separate PV, battery, EV and hot-water systems can justify an overarching monitoring and scheduling layer once their native operating modes and safe fallbacks are understood.
| Requirement | First platform to evaluate | What makes it a poor fit | What must remain independent |
|---|---|---|---|
| Whole-house power dashboard and historical kWh | Home Assistant Energy plus sound metering | Cloud-only values too slow or inaccurate | Utility billing and certified meter records |
| One EV solar surplus charging | Charger native system or evcc | No controllable charger or grid meter | EVSE electrical protections |
| Two EVs sharing available current | Approved charger load sharing; evcc for scheduling | Charging points cannot report/control reliable current | Commissioned circuit and site limits |
| Battery reserve and grid-code export restriction | Approved inverter/BMS platform | Third-party write API not approved | BMS, export limiting and anti-islanding |
| Heat pump with weather compensation | Heat pump native controller | Setpoint chasing harms COP/comfort | Compressor and hydraulic protection |
| Tariff-aware shiftable loads | Home Assistant or evcc for supported loads | Supplier pricing or appliance control unavailable | Appliance thermal and electrical safety |
| Mixed-brand report for household decisions | Home Assistant | Incorrect entity semantics create double counting | Device operating systems |
Buying rule: request an integration matrix before ordering new hardware. List each exact model, firmware, local endpoint, available measurements, writable setpoints, update interval and fallback behaviour. A product with an advertised API may still offer only daily cloud energy totals; that is unsuitable for responsive solar surplus control. Similarly, a device’s advertised Modbus support says nothing about whether the specific battery charge-mode register is exposed, writable or allowed by the manufacturer.
Decision scorecard: rank reliability and control fit before features
A neutral decision process makes assumptions visible. The following weights are illustrative, not independent test results. Give the largest share to compatibility and safety, then to offline behaviour, usable energy data, day-to-day convenience and lifetime cost. Owners with an electric car used for long daily commutes may increase the importance of departure deadlines. Owners without an EV should reduce the weight given to charging functions; there is little reason to deploy dedicated EV software just because it supports an impressive list of inverters.
| Criterion | Example weighting | Proof to request |
|---|---|---|
| Exact hardware and firmware compatibility | 25% | Published device template, integration entities or written manufacturer answer |
| Failure behaviour and safe control boundaries | 20% | Documented loss-of-comms behaviour and site commissioning record |
| Local operation and network requirements | 15% | Demonstration without WAN; required ports and account details |
| Measurement quality and physical topology | 15% | Raw import/export plus PV/battery/charger measurements with clear units |
| Operating features that solve this household problem | 15% | One-week trial with real vehicle and tariff |
| Five-year ownership and support | 10% | Itemised host, licence, meter, support and maintenance costs |
Do not award an automatic high local-control score just because a software project is self-hosted. If it depends on a cloud vehicle API for battery state of charge, that specific feature remains cloud dependent. A charger can be controlled locally while its associated car is queried remotely. Home Assistant may collect local inverter telemetry but use a cloud-based solar forecast. A vendor app may have local commissioning but cloud-only remote history. Describe locality per data source and function, not as a marketing label for the whole installation.
Energy-flow accounting: reconcile the site before introducing automation
Consider a home with rooftop PV, a battery, an EV charger and ordinary loads. Start with a consistent instantaneous power sign convention: PV output, grid import, battery discharge and inverter outputs are positive when supplying the household; grid export and battery charging are recorded as outgoing flows. One possible balance, ignoring minor conversion losses and measurement lag, is PV + grid import + battery discharge = household loads + EV charging + battery charging + grid export. If the system reports an implausible balance, do not use it to compute “free solar for the car” until you have resolved meter location and signs.
The word household needs a boundary too. Some inverters report “load” including the EV charger, some report non-EV consumption, and some vendor dashboards calculate a residual rather than measure a circuit directly. A separate EV meter can be useful for billing and attribution, but adding EV kWh to a whole-house import total again is double counting. With hybrid inverters, AC-coupled storage and battery losses can also make short-interval meter reconciliation imperfect. Inspect an hour of raw timestamped power and later verify daily accumulated energy against the utility record.
| Illustrative sunny minute | PV power | Other loads | EV charger | Battery | Grid at boundary |
|---|---|---|---|---|---|
| Surplus before EV starts | 5.0 kW | 1.2 kW | 0 | Charging 1.0 kW | Export 2.8 kW |
| EV begins at 1.4 kW | 5.0 kW | 1.2 kW | 1.4 kW | Charging 1.0 kW | Export 1.4 kW |
| EV ramps to 3.4 kW | 5.0 kW | 1.2 kW | 3.4 kW | Charging 1.0 kW | Import 0.6 kW |
| Battery stops charging | 5.0 kW | 1.2 kW | 3.4 kW | Idle | Export 0.4 kW |
| Cloud lowers PV to 3.0 kW | 3.0 kW | 1.2 kW | 3.4 kW | Idle | Import 1.6 kW |
These are arithmetic examples, not measured performance from a named device. At a 230 V nominal single-phase supply, an EVSE minimum of 6 A corresponds to about 1.38 kW before power-factor and actual-voltage considerations. Three phases at approximately 230 V phase-to-neutral and 6 A each require roughly 4.14 kW of active charging power under balanced conditions. A charger may support 1P/3P switching, but the car, charger hardware, wiring and switching strategy must all permit it. Do not infer that every “three-phase-compatible” charger can change phases dynamically.
Grid meter location matters more than another clever algorithm
The site connection meter or correctly installed bidirectional CT arrangement should see the whole property. A CT installed only around the PV inverter output cannot measure export after household loads. A CT around an EV charger measures that load, not available surplus. On a three-phase site, verify phase assignment, current direction and the device’s aggregation method; check individual-phase supply constraints even if the energy bill is calculated from a net sum. A qualified installer should commission mains metering and any protective load-management equipment.
Meter polling is another engineering constraint. An inverter cloud portal updated every five minutes can be adequate for trends but unsuitable for following second-by-second cloud changes. A fast local meter can still become stale when Wi-Fi drops. The correct response is not to treat the missing reading as zero import, zero export or unlimited spare capacity. Suspend discretionary optimisation, fall back to supported charger operation, or keep the last safely bounded target only where the manufacturer explicitly approves that approach.
Controller ownership: define the command hierarchy in writing
An increasingly common problem is competing optimisation loops. The car has a departure timer, the EVSE has a solar mode, evcc tries to adjust charging current, Home Assistant turns the charger on and off, and the inverter changes battery behaviour using its own time-of-use schedule. Each component may be locally correct while the combination oscillates. Separating functions reduces contention: the EVSE enforces configured protective limits; one nominated higher-level charging optimiser issues routine current and schedule commands; Home Assistant reads the resulting status and orchestrates unrelated discretionary loads.
| Function | Recommended authority | Secondary platform role | Common collision |
|---|---|---|---|
| Overcurrent, leakage and protective stop | Approved EVSE and electrical installation | Monitor status only | Software tries to bypass unavailable charger |
| Grid-export compliance and anti-islanding | Installer-approved inverter/limiter | Read export and alert | Automation writes undocumented export registers |
| Battery reserve and internal protections | Inverter/BMS supported control | Slow preference only if officially allowed | EV software discharges battery below household reserve |
| EV target current and surplus algorithm | Exactly one: charger-native or evcc | Show state; pass non-conflicting preferences | HA sends current while evcc also adjusts it |
| Vehicle departure/energy requirement | Chosen charging optimiser or native car schedule | Provide informational inputs | Different timers veto each other |
| Water-heater or appliance schedule | Equipment-approved controller; HA where suitable | Energy and comfort display | Hot-water hygiene cycle delayed by cheap-price logic |
| Whole-home analytics | Home Assistant or equivalent | Publish read-only metrics | Double-count charge energy from two meters |
Write down which controller is the final writer for each setpoint, who owns the system clock, what a manual override does, and how long a command is expected to remain in force. For EV charging, decide whether “Fast” is a deliberate temporary override with a defined end or a permanent mode change. For batteries, distinguish a permitted reserve preference from firmware settings that could breach warranty or grid compliance. Avoid attempts to build an external, high-frequency battery control loop on a general-purpose smart-home server unless the inverter vendor documents that operating mode and the safety case has been reviewed.
What evcc adds—and what it does not guarantee
The official evcc documentation describes local operation, solar surplus charging, dynamic tariffs, departure planning and a broad collection of supported chargers, vehicles, meters and battery systems. Its solar charging feature normally relies on the measured power flow at the grid connection. That is an important distinction: maximising charger current from inverter generation alone could discharge the home battery or import electricity when the household switches on an oven. evcc also offers integrations through its REST and MQTT interfaces, and can read selected Home Assistant entities.
However, supported monitoring does not necessarily mean supported control. A hybrid inverter may supply PV output, site import and battery state of charge to evcc while refusing third-party battery-mode changes. Vehicle state of charge may require a vendor cloud, credentials, or infrequent polling. A charger with nominal OCPP capability may not expose all desired current steps or may rely on proprietary firmware. Review the feature badges and integration caveats for the precise model, not the brand header.
| Feature to verify | What to test on a real installation | Why documentation alone is insufficient |
|---|---|---|
| Charger start/stop | Three start/stop cycles with vehicle connected | Car sleep behaviour and EVSE firmware can differ |
| Continuous current regulation | Minimum, mid-range and rated current; phase readings | Advertised control may only allow coarse increments |
| Automatic phase switching | Approved single/three-phase transition with supported car | Hardware-specific and not universal |
| Grid meter response | Switch a known household load and observe sign/latency | Cloud or gateway data may arrive late |
| Battery awareness | Watch whether EV demand drains reserved battery energy | Reading SoC does not equal enforceable battery policy |
| Departure target | Set a deadline with insufficient solar and confirm grid top-up | A surplus-only mode may not meet the required charge |
| Tariff integration | Compare actual bill-inclusive import prices by timestamp | Wholesale forecasts differ from retailer charges |
| Loss of connectivity | Disable WAN, then local server/broker in controlled tests | Different features fail at different layers |
evcc sponsorship and licensing: evaluate the exact feature, not a remembered price
The project is open source, but some device integrations and components require a sponsor token. The project’s licence notes state that sponsor-required components have additional conditions and that a token is required per evcc instance using those components. Device documentation uses a heart symbol to mark sponsor integrations. There is no defensible fixed “evcc costs £X for everyone” assumption: whether a proposed installation needs a token depends on supported devices, the features selected and the terms in force when it is deployed. Check the sponsor-token documentation and current sponsor portal before purchasing an EVSE on the strength of an old guide.
Also distinguish EV charging optimisation from electrical load management. The evcc load-management documentation currently labels its feature experimental and lists restrictions, including behaviour with battery grid charging and rebalance limitations. That is not a substitute for every installation’s hardware-approved circuit management. A charger’s certified protections, locally commissioned limits, RCD arrangements and mandatory wiring practices take precedence. The practical choice may be to use the charger’s approved load-limiting system for hard constraints and evcc for slower discretionary optimisation, but conflicting controls must be reviewed and tested because the evcc documentation itself warns about multiple load controllers.
Home Assistant excels at visibility but needs a deliberately modest control role
Home Assistant’s Energy dashboard can combine grid import/export, PV yield, storage and individual devices, and its automation engine can consider presence, weather, tariffs and room conditions. It is often the best cross-vendor observability layer. Yet the Energy dashboard expects properly modelled accumulated energy sensors; instantaneous kW values cannot be substituted for increasing kWh totals. A template adding PV production and battery discharge must not double count if the source inverter already provides a derived whole-home consumption total.
Home Assistant also has integration-specific differences that matter to a purchaser. The official Fronius integration uses a local Solar API for supported models and documents configuration prerequisites. The official SolarEdge integration uses an API key and site ID for its cloud-based site sensors, so it should not be mistaken for a generic local SunSpec integration. The Victron GX integration uses MQTT with supported GX equipment and exposes a range of monitoring and control entities whose availability depends on the actual system. These are examples of differing interfaces, not a blanket endorsement of a particular inverter.
For forecasts, Forecast.Solar can provide estimated production; it does not measure production and its free access has update and array-plane limits. A planned action should therefore combine forecast information with a fresh physical meter reading and accept that a passing cloud may invalidate the prediction. Start with read-only alerts, then build slow, reversible scheduling only after a week or more of sound telemetry. Keep minimum runtimes, manual override and hard plant limits with the supported native controllers.
Example: read-only monitoring of a stale grid-power sensor
The following Home Assistant automation is an illustrative monitoring template, not charger control. Replace the entity ID and the mobile-notification action with the actual entities available on your installation. It notices when the net-grid power sensor has been unavailable for five minutes. It does not set a charger current, change an inverter register or override site limits. It requires a configured persistent-notification service, available on standard Home Assistant installations.
automation:
- alias: "Energy meterAliExpress price missing - diagnostic alert"
id: energy_meter_missing_alert
mode: single
triggers:
- trigger: state
entity_id: sensor.site_grid_power
to: "unavailable"
for: "00:05:00"
- trigger: state
entity_id: sensor.site_grid_power
to: "unknown"
for: "00:05:00"
actions:
- action: persistent_notification.create
data:
title: "Energy meterAliExpress price data unavailable"
message: >-
Site grid power has not been available for five minutes.
Inspect the meter or network. Do not assume surplus
energy is available from an unavailable measurement.This will not detect a value frozen at a plausible number for a long time; that requires a device timestamp, sequence counter or other explicit freshness indicator. A stable legitimate zero-power reading should not automatically be treated as a fault. Any decision to disable discretionary loads in response to missing telemetry needs to be implemented at the relevant approved controller with a known loss-of-comms behaviour, not by a guessed dashboard sensor.
Example: monitor the difference between generation and site import
A simple analytical sensor can compute an estimated instantaneous non-PV contribution, but it is not a billing record or a safety input. The example below calculates net site export as the negative part of a signed meter where positive means import and negative means export. This only works if the supplied meter and its entity actually follow that convention. Check a known load and midday export first. It is intentionally read-only, and unavailable measurements remain unavailable.
template:
- sensor:
- name: "Site grid export power example"
unique_id: site_grid_export_power_example
unit_of_measurement: "W"
device_class: power
state_class: measurement
availability: >-
{{ is_number(states('sensor.site_grid_power')) }}
state: >-
{% set grid_w = states('sensor.site_grid_power') | float %}
{{ ([0, -grid_w] | max) | round(0) }}Before displaying this as “solar surplus”, consider whether the house battery is discharging. Net export can be produced by PV, a battery, another generator or some combination. It is also a snapshot: if the car starts drawing 1.4 kW, the grid reading changes and the controller must re-evaluate the physical balance. A read-only Home Assistant template is a good place to explore data semantics without risking control conflicts.
Inverter-native apps: where vendor-specific strengths genuinely matter
An inverter manufacturer’s controls typically remain the authoritative place for grid-connection profiles, battery integration, backup reserve, operating permissions, firmware updates, fault codes and warranty-related service. Those functions are tightly coupled to power electronics and the BMS. Their app may be entirely sufficient for a home with PV and storage but no flexible high-power loads. It can also remain the necessary service interface when Home Assistant and evcc are installed above it.
The drawback is portability. A vendor can support its own battery and EV charger beautifully but expose little about a competing EVSE or heat pump. Cloud dashboards can introduce outages, delayed samples, API quotas and account dependencies. Conversely, an inverter with reliable local telemetry may make adding Home Assistant inexpensive, because the hardware already exposes the measurements needed for an independent dashboard. Ask for the full device generation and local interface support, not merely the brand name.
| Ecosystem example | Potential native advantage | Home Assistant path (verify model) | Procurement caution |
|---|---|---|---|
| Fronius inverter with compatible meter | Strong inverter and site diagnostics | Official Solar API integration on supported devices | Local API and data fields vary by model and configuration |
| Victron GX-based system | Integrated local supervisory interfaces | Official Victron GX MQTT integration | Control availability depends on GX and firmware; external ESS control is specialist |
| SolarEdge installation | Module/site diagnostics in vendor platform | Official site API integration; other local methods are distinct | Official site sensors require API access and account permissions |
| Manufacturer-matched solar + battery + EV | One commissioning and support chain | Often partial monitoring through official or community integration | Third-party charging limits and batteries may not be supported |
| Mixed-brand retrofit | No single vendor may control everything | Home Assistant for visibility plus evcc where compatible | Multiple vendor clouds increase dependencies |
External battery control deserves particular caution. Victron, for example, documents specific ESS external-control modes with ongoing command and feedback requirements; these are not simply an invitation to write arbitrary Modbus registers from a hobby automation. Unsupported write access can disrupt reserve management, warranty conditions or regulatory settings. If you genuinely need an external battery-optimisation loop, require documented manufacturer operating modes, an experienced system integrator, robust feedback, a watchdog and a defined handover when the controller stops.
Tariff arithmetic: “use solar” and “save money” are not synonyms
A home energy controller should optimise the household’s actual marginal cost, not a slogan. At a sunny moment, consuming an extra 1 kWh from rooftop PV may avoid 1 kWh of grid import, but it may also forgo export income and reduce battery charging. If later household energy costs more, charging the EV from PV now can be cheaper or more expensive than exporting it and importing later, depending on tariff, battery efficiency, and the car’s deadline. Software needs the appropriate import price, export compensation, and operating limits to compare options meaningfully.
| Illustrative alternative for one useful EV kWh | Assumed price or value | Simplified interpretation |
|---|---|---|
| Use otherwise-exported solar now | Lost export payment: £0.08/kWh | Economic cost about 8p per kWh consumed |
| Export solar, charge overnight at 12p/kWh | Export 8p, import 12p | Net cash cost about 4p per shifted kWh before losses/fees |
| Charge EV at expensive peak import rate | Import 32p/kWh | Potentially much costlier than daylight solar |
| Use stored battery energy instead of grid | Later avoided import varies | Battery cycling has efficiency loss and opportunity cost |
| Charge car before departure regardless of cost | Readiness is a constraint, not a price | Optimum must still finish within deadline |
The illustrative 8p/12p comparison is deliberately simple and excludes charger efficiency, tax, standing charges, battery losses and tariff terms. The important result is that a solar-first strategy is not automatically a cost-minimising strategy. If solar export is worth 15p/kWh and overnight import is 9p/kWh, exporting 1 kWh and later importing approximately the same amount can be attractive, provided metered import/export rules and losses support the calculation. Conversely, where export compensation is zero or constrained, self-consumption becomes more valuable. Do not assume wholesale spot prices equal the bill-inclusive import rate.
Worked EV charging example: minimum current, energy target and departure
Suppose a car needs 18 kWh of additional battery energy by 07:30. At an assumed 90% overall AC-to-battery efficiency, the wallbox must deliver approximately 20 kWh. A single-phase charger drawing roughly 3.7 kW needs about 5.4 hours of actual active charging. If there are only four suitably sunny hours left and the car is connected now, a purely solar-surplus strategy cannot guarantee completion. The controller needs an explicit plan to import during a cheap period, charge faster where hardware allows, or inform the driver that the target is unattainable.
In a second example, four hours at 1.4 kW might transfer only 5.6 kWh from the supply, and less into the battery after losses. A dashboard showing “car is charging on sunshine” can therefore coexist with a missed departure target. Useful automation must measure both energy delivered and time remaining. Vehicle state of charge is helpful when accurate, but not every car provides a trustworthy real-time API; charger energy meters and an assumed efficiency can provide a rough fallback with clearly indicated uncertainty.
Battery versus EV priority: a worked constraint
Consider 4 kW of PV, 1 kW of ordinary load, and a battery charging at 2 kW. The nominal grid export is 1 kW. An EV requiring at least 1.4 kW cannot operate on strictly zero-import solar surplus at that instant unless the battery charging rate is reduced or the controller tolerates some grid energy. That reduction may be sensible when the car leaves in an hour; it may be foolish if the battery must sustain critical loads overnight. The best priority is situational and should respect manufacturer-approved battery reserve and charge rules.
A controller able to observe battery SoC is not necessarily able to enforce battery policy. Nor is requesting a particular battery mode the same as verifying that the inverter obeyed it. Log actual charge/discharge after every important mode change. A system that repeatedly drains the battery into the car and recharges it from the grid later can lose energy to extra conversions, even if its solar percentage looks impressive.
Installation costs: compare complete operating architectures over five years
For a British household, the economically useful comparison is often the incremental cost of adding the next controller to equipment already owned. A Home Assistant server used for lighting and heating does not need to be purchased again. A hybrid inverter may already include a usable grid meter. Conversely, buying a cheap controller that requires a £200 compatible meter and paid electrician time can cost more than a supported charger with native solar features. The figures below are illustrative planning scenarios, not live retailer quotations or promises of savings. Use them to create an installer and equipment shopping list, then replace each line with a firm price.
| 5-year incremental item | A: Keep inverter + charger native | B: Add Home Assistant (existing host) | C: Add evcc to compatible system |
|---|---|---|---|
| Extra host hardware | £0 | £0 (already owned) | £90 |
| Extra compatible meter/gateway | £0 | £120 | £160 |
| Installation/configuration labour | £0 | £120 | £180 |
| Connectivity/backups/maintenance allowance | £0 | £80 | £100 |
| Feature sponsorship/licence assumption | £0 | £0 | £0–£200 scenario range; verify |
| Five-year incremental total | £0 | £320 | £530–£730 |
Scenario B assumes that a working Home Assistant host is already in place and adds modest metering and setup. Scenario C assumes a separate always-on host or appliance, an additional compatible meter and a deliberately hypothetical allowance for features that may require sponsorship; it does not state current evcc subscription pricing. An installation that already has the necessary site meter and host may cost substantially less. A site needing a new three-phase meter, enclosure and professional work can cost much more. The manufacturer’s app route is not truly free if a new proprietary gateway or paid vendor service is required; the £0 figure applies only when the needed functions already exist.
A transparent break-even calculation
If a new controller has an incremental five-year cost of £600, it needs to improve household outcomes by approximately £120 per year just to recover those costs over five years, ignoring finance, discounting and replacement risk. At a 20p/kWh effective cost difference between the expensive charging slot avoided and the cheaper slot used, that represents roughly 600 kWh/year shifted—but actual savings will differ because EV charging losses, solar export payments and battery interactions matter. At a mere 5p/kWh effective gain, the same £120/year requires 2,400 kWh shifted annually. A household that drives little will struggle to justify elaborate optimisation on EV charging savings alone.
Conversely, better scheduling can be worth more than simple energy savings when it prevents missed charging deadlines, provides manual visibility or makes an awkward installation usable. State that value explicitly rather than burying it in unsupported “up to 40% savings” language. To evaluate financial performance, compare with a baseline representing what the household would otherwise have done using the same weather, energy demand and tariff—not with a deliberately wasteful all-peak charging scenario unless that was the real starting point.
Case study 1: modest solar array, one EV, no battery
A homeowner has 4 kWp rooftop PV, an existing single-phase smart wallbox and a fixed electricity tariff. They are home most afternoons and can leave the car connected. The inverter app already shows production but not net grid exchange. The best first expenditure may be a supported site CT or meter so the charger’s native solar-surplus feature can see real export, assuming the particular charger supports that accessory and the installation is suitable. Buying a mini PCAliExpress price, configuring evcc, and then recreating the same charging mode may not improve the result.
Home Assistant becomes valuable if the owner also wants gas, water, temperature and appliance dashboards, or if the charger’s history is poor. If charging regularly misses departure requirements, a more capable optimisation layer might be justified. Test the existing wallbox’s delayed charging and charging-current interface first; if it performs adequately offline, keeping it as the single control owner saves integration work. Check whether the daily reported “solar EV charging” excludes any grid power imported below the meter’s update interval.
Case study 2: hybrid inverter, battery and two electric cars
Now consider a 7 kWp PV installation, 10 kWh of nominal battery capacity, two EVs with different departure deadlines and a three-phase connection. One vehicle is at home during the day, while the other returns late. The household needs accurate three-phase site metering, charger and vehicle compatibility checks, and a policy for battery reserves. This is the setting where dedicated charging optimisation can deliver meaningful convenience, although approved charger-native load management must still meet the electrical requirements.
The energy-management question is not “Which vehicle gets the most sun?” but “Which energy targets and deadlines can we meet while respecting site current, phase constraints and storage priorities?” For example, car A may need only 6 kWh by 18:00 and car B 20 kWh by 07:00. Shifting A to sunny hours and B to cheap overnight hours is plausible if the cars and EVSEs are controllable and the off-peak interval offers sufficient charging capacity. The inverter continues to protect the battery and grid connection. Home Assistant reports actual delivered energy and alert conditions; evcc or the supported EVSE scheduler owns the charging decisions.
Do not assume evcc automatically optimises all battery flows: its battery-control features are device dependent and may require specific external-control support. Likewise, do not assume an experimental software load-balancing feature meets installer-mandated requirements. Test simultaneous charging with other large household loads under professional supervision and ensure each circuit’s protective limit remains effective when the optimisation host is unplugged.
Case study 3: no EV, but a heat pump and immersion heater
A homeowner with a heat pump, hot-water cylinder and rooftop PV may have very little use for an EV-specialist platform. Their value comes from understanding the heat pump’s daily electricity input, water-heating energy, time-of-use prices, minimum temperature and hygiene requirements. Home Assistant can combine monitoring data and cautiously schedule approved discretionary loads. The heat pump’s native controller should retain weather compensation, compressor protection and domestic-hot-water safety. If the cylinder has a manufacturer-approved immersion diversion product, its power electronics and electrical protection should remain independent of the dashboard.
A flawed automation that repeatedly forces a heat pump to chase cheap slots using high flow temperatures may increase electricity consumption by reducing COP or creating cycling. A simple monitored schedule with good meter accounting is often preferable. For deeper planning, evaluate an optimiser such as EMHASS only after collecting reliable historical consumption, price and weather data; more sophisticated maths cannot repair inaccurate meters or a heat-pump interface that refuses needed commands.
Case study 4: inverter ecosystem already offers excellent native control
A fully integrated solar, battery and compatible charger ecosystem may provide adequate surplus charging, backup priorities, battery schedules and export limits through one vendor. Its app may also offer reliable support from the original installer. A third-party controller has to show an incremental benefit: independent household analytics, additional brands, better charging departure logic, more accurate tariff handling or data privacy. If none of those problems exists, staying with native features is a rational design choice, not a failure to embrace home automation.
Before choosing a vendor-only solution, ask what happens when the internet is lost, the account is transferred, the manufacturer discontinues a model or the homeowner changes EV brand. Request documentation on data export and local interfaces. Avoid a hardware purchase based solely on an attractive demonstration screenshot: test whether the app records actual grid import/export energy, whether it retains data across network outages, and whether monitoring works without an ongoing service fee.
Networking, security and service continuity
A local installation still has a network attack surface. Modbus TCP often has little intrinsic authentication; an unauthenticated write-capable interface should not be exposed beyond the trusted industrial or home automation segment. MQTT should use appropriately configured credentials and, where supported, transport security. A self-hosted dashboard should not be placed directly on the public internet. Prefer a supported encrypted remote-access service or properly maintained VPN and segregate critical plant interfaces from guest Wi-Fi and untrusted IoT devices. Apply vendor firmware updates deliberately, with a documented rollback plan where available.
| Failure or attack scenario | Symptom the owner sees | Preferred design response |
|---|---|---|
| Cloud vehicle API unavailable | No SoC updates, charging still possible | Use supported local EVSE energy and explicit departure fallback |
| HA host restarts during tariff slot | Missing automation trigger or late start | Native charger readiness plan where necessary; alarm on missed target |
| evcc host or MQTT broker fails | No optimisation/current updates | Manufacturer-defined EVSE fallback and safe current limits |
| Inverter LAN link unavailable | PV/battery telemetry stale | Native BMS and inverter continue safe autonomous operation |
| Internet outage | Forecast, remote portal or dynamic prices stale | Documented local controls and tariff/default schedule |
| Grid meter freezes | Misleading permanent “surplus” | Freshness checks and stop speculative optimisation |
| Conflicting automation writes | Charge starts and stops unexpectedly | One command owner; disable duplicate schedules |
| Incorrect credentials or open Modbus | Unauthorised access to setpoints | Network isolation and limited write permissions |
Define downtime behaviour before the integration goes live. One household may prefer the EVSE to stop discretionary charging when the controller fails; another may want a fixed low-rate charging schedule so the car is usable next morning. The safe and appropriate option depends on the charger, installation approval, expected commute and native controls. A robust system records its current mode clearly and makes manual charging possible without asking the homeowner to debug an MQTT topic at midnight.
A two-week acceptance test that turns features into evidence
A real-world pilot can disprove an incompatible product faster than hours of browsing. Use the first few days for read-only logging, with deliberate checks of every metering direction and power unit. Observe a cloudy day, a sunny day, normal overnight loads and a manual high-load event. Compare two or three representative charging sessions to charger records and the utility meter. Only then enable a supported optimiser in one-control-owner mode. Record software versions and screenshots of the configuration before testing any failure scenarios.
| Test | Pass condition | Who should witness or approve |
|---|---|---|
| Site measurement boundary | Grid import/export agrees in sign and reasonable magnitude with known loads | Owner and qualified meter installer |
| Energy accounting for 24 hours | No unexplained double counting; kWh counters monotonic or documented resets | Owner or commissioning technician |
| EV minimum current | Charger respects manufacturer minimum and pauses appropriately | Approved charger installer as relevant |
| Battery reserve policy | Battery never violates configured native lower reserve due to automation | Inverter installer where write control involved |
| Dynamic tariff timing | Scheduled slots match retailer periods including timezone/DST | Owner with billing data |
| Loss of internet | Core safety and essential charging remain in defined safe mode | Owner and installer as appropriate |
| Loss of software host | No uncontrolled charging-current or grid-limit behaviour | Qualified installer where electrical limits involved |
| Manual override | Override is visible and has documented end state | Household user |
| Data retention | Charts and energy counters survive ordinary restarts | Owner |
| Five-year cost evidence | Hardware, subscriptions, maintenance and savings assumptions traceable | Owner |
For numerical evaluation, use three KPIs that cannot easily be manipulated by a flashy dashboard: import cost per delivered EV kWh using measured wallbox energy and aligned tariffs; missed departure targets; and unwanted grid import during solar-only mode subject to a documented tolerance and measurement latency. A site with a battery should also track unexpected battery discharge during charging. Do not use “percentage solar” as the single outcome: two platforms may define that percentage differently, and a high percentage can conceal reduced battery reserve or unnecessarily long charge times.
What to buy, in order, and what to defer
The purchase list is deliberately ordered by physical necessity, not by affiliate potential. A precise, compatible meter and a controllable EVSE usually matter more than another hub. If you already have a supported inverter meter, do not automatically add a duplicate CT set; determine whether the values can be read by the new optimiser and whether the sampling interval is adequate. On the other hand, if the inverter hides site export behind a five-minute cloud portal, a supported local meter may be justified for real-time charging control.
| Buy now when missing | Only if requirement proves it is needed | Often defer until the pilot |
|---|---|---|
| Qualified installation and verified site metering | Dedicated local HA or evcc host | Additional dashboard display |
| Manufacturer-approved EVSE and load protections | Compatible charger gateway/OCPP option | Expensive high-frequency cloud data plan |
| Reliable local network at plant room | Battery write-control interface with documented support | Custom batteries/inverter register experimentation |
| Clear tariff and export-compensation data | Home Assistant server for multi-system visibility | Forecast-optimisation solver |
| Documented safe manual charging mode | Sponsorship/licence for required evcc components | Second energy monitor with identical data |
For related buying and configuration decisions, see our Home Assistant grid, solar and battery entity guide, EV charger meter and dynamic load-balancing comparison, and solar surplus EV charging integration guide. Their control and metering lessons complement this strategic software comparison. They do not make a generic smart-home server a replacement for approved electrical load management.
Frequently asked questions
Is evcc a replacement for Home Assistant?
Not generally. evcc specialises in charging and energy optimisation; Home Assistant covers a much broader smart-home environment. They can coexist if control ownership is clear.
Can I use Home Assistant without evcc?
Yes. Many installations use charger-native solar charging or Home Assistant automations. Dedicated EV optimisation may be preferable for complex tariffs or multiple chargers.
Do inverter apps work without internet?
The inverter normally continues its essential operating functions, but app access and some optional controls may depend on the cloud. Check the exact model and configuration.
Does evcc support every EV charger?
No. Confirm the exact device and required features in current compatibility documentation. A general protocol label is not sufficient.
Will Home Assistant prevent electrical overload?
Do not rely on it for protective load limitation. Use approved charger load management and electrical protection installed and commissioned correctly.
Can I prioritise charging the battery over the EV?
Often, if the relevant meter and battery states are available and the selected control supports that policy. Verify it with real-world tests.
Is solar surplus charging always cheapest?
Not necessarily. A very cheap overnight tariff may beat the opportunity cost of exporting solar, depending on import/export prices and battery losses.
What if I have a three-phase home?
Choose meters and chargers that explicitly support the phase arrangement and relevant limits. Confirm phase switching behaviour where offered.
Do I need a dedicated mini PC?
Not if a reliable existing Home Assistant host can run the required software and has sufficient resources. Assess reliability and backup needs.
Can evcc and Home Assistant both control the same charger?
Technically possible in some setups but generally a poor default. Use one owner for current and schedule commands to avoid conflicts.
Does a Modbus connection guarantee battery control?
No. Register availability and write permissions vary by model, firmware and region. Some interfaces are read-only.
How do I prove the system saves money?
Compare measured imports, exports and charging costs against a credible baseline while accounting for weather, tariffs and usage differences.
Final recommendation
For most mixed-brand smart homes, use Home Assistant as the visibility and household-automation layer; add evcc when EV charging needs dedicated optimisation; and leave certified inverter and charger safety functions with their native controllers. Buy compatible meters and reliable integrations before paying for another hub. The best energy-management system is the simplest one that meets your real requirements and continues behaving safely when a server, network or cloud service is unavailable.
Further reading and official documentation
See Home Assistant Energy management, the official integration directory, evcc documentation, and the evcc project. For an ESP32AliExpress price-based monitoring project, read our grid, solar and battery entity guide, solar surplus flexible-load guide and OpenTherm gateway guide. Manufacturer installation manuals remain authoritative for electrical safety, compatibility and warranty conditions.