Quick Summary (TL;DR)
Home energy monitoring can continue through an internet outage—but only when the sensors, communications, processing and storage stay within the home. A locally accessible meter does not guarantee local operation if its gateway still requires cloud authentication; a Home Assistant dashboard does not guarantee it will show fresh values if the MQTT broker has stopped; and retained MQTT messages can display a perfectly plausible reading from yesterday unless availability and freshness are engineered deliberately.
For most households, start with a locally accessible electricity meterAliExpress price, a reliable home network, Home Assistant running on a suitable host, and its normal Recorder database. Use the official local integration if it already works well. Add a local MQTT broker only where it solves a genuine integration problem or lets several publishers and consumers exchange measurements. Use Ethernet for fixed gateways where practical, and design dashboards to distinguish live measurements from stale values.
The critical rule is to keep safety functions, protective load limits and essential heating controls independent of a general-purpose automation server. Home Assistant may supervise schedules and report energy, but a network outage must not disable an inverter’s protection, electrical installation safeguards, approved EV load management or a heat pump’s safety systems. Test the loss of broadband, DNS, the Wi-Fi access point, the router, the broker, the Home Assistant host and electrical power separately. The resulting test record is more valuable than a marketing claim that a device supports “local control”.
This guide is a whole-system reliability and purchase decision for UK and European homes with solar PV, batteries, EV chargers and smart meters. For meter-by-meter comparisons see Whole-Home Energy Monitoring Without Cloud: Hardware and Integration Options. For the separate question of how a charger behaves offline, see EV Charger Connectivity: Wi-Fi vs Ethernet vs Cellular and Offline Behaviour.
What does “without internet” actually mean?
An internet outage is the loss of connectivity from the home network to external services. Your electrical meter may continue measuring, your Ethernet switch may keep forwarding frames, your NASAliExpress price may stay accessible and Home Assistant may remain fully usable on a local IP address. But that depends on DNS, address assignment, routing and authentication choices made before the outage. “Cloud-free” needs to be verified as a property of the complete data path, not merely the product box.
A local network failure is different. If the router also provides the Wi-Fi access point, DHCP server, DNS resolver and internal switching, unplugging that box may disconnect all wireless devices even when the internet was never necessary. A dedicated switch can keep wired hosts connected; a separate Wi-Fi access point can maintain radio coverage; and a local resolver can make hostnames work. However, a local DNS resolver does not help when the device is designed to authenticate or stream through a vendor’s servers.
A power cut is different again. Your battery-backed inverter or utility meter may continue recording energy while the Home Assistant host, network switch or broker loses power. A backup power supplyAliExpress price can keep an appropriately selected monitoring system running, but it never makes a non-backed-up meter, Wi-Fi device or mains-dependent sensor continue operating. Decide whether your goal is to retain historical totals, see the system during a blackout, or keep a supervisory control function running: those are three different requirements.
| Failure | What may survive | What commonly fails | Practical design response |
|---|---|---|---|
| Broadband or ISP outage | LAN, local IP access, Ethernet, local MQTT | Vendor cloud API, internet tariff feed, remote app | Keep meter and broker local; show unavailable external prices |
| DNS failure | Known IP connections and existing sessions | Name-based APIs, broker hostnames, external authentication | Provide reliable local DNS and documented fallback addresses |
| Router failure | Some switched Ethernet links | DHCP, routed VLANs, Wi-Fi if router-integrated | Separate reliable switching/AP or test the all-in-one router |
| Wi-Fi access-point failure | Wired gateways and Home Assistant | Wireless meters, ESP32 nodes, Wi-Fi plugs | Use Ethernet where possible and avoid sole Wi-Fi safety paths |
| MQTT broker failure | Direct local APIs, autonomous vendor controllers | MQTT subscriptions and command delivery | Check availability; automatic reconnection; broker backup |
| Home Assistant host failure | Standalone meters, inverter/charger protections | Dashboards, automations, Recorder writes | Manufacturer-native protection; recover HA from backup |
| Local power cut | Devices with independent power or UPS | Unprotected servers and switches | Size backup power for measured demand and desired runtime |
| Vendor service termination | Documented local protocols | Cloud-only products and app-only onboarding | Prioritise devices with proven ongoing local operation |
Map every dependency before buying hardware
Draw a simple directed chain for each important measurement: sensor → gateway → local transport → integration → Home Assistant state → Recorder → dashboard. Mark every arrow as Ethernet, Wi-Fi, RS-485, MQTT, HTTP, WebSocket, Modbus TCP or vendor cloud. Mark which node needs an IP address, valid credentials, an accurate clock and access to a vendor endpoint. You may discover that the so-called local meter is read through a cloud application that subsequently writes an MQTT state, meaning a perfectly local broker does not remove the cloud dependency.
The data path from a grid meter is not always the control path. An EV charger might expose power and session energy through its local API, while its approved dynamic load balancing uses a separate wired meter and its own fail-safe logic. That separation is desirable: observability can be flexible, whereas protective curtailment must remain the responsibility of the correctly installed and certified equipment. Similar distinctions apply to battery BMS protections and heat-pump high-temperature limits.
Prefer to document every device in an inventory that records the actual model and firmware, local protocol, source of truth for cumulative energy, time base, polling frequency, IP/DNS dependency, behaviour when offline, firmware update path and recovery owner. A laminated note of which box hosts Mosquitto is less glamorous than a wall dashboard but more useful when something fails at midnight.
| Layer | Typical device | Dependency to verify | Evidence of true local operation |
|---|---|---|---|
| Physical measurement | DIN-rail meter or inverter CT | Meter power, CT direction, phase mapping | Local register/pulse count changes with internet unplugged |
| Field connection | RS-485/Modbus RTU | Bus termination, polarity, serial settings | Stable reads from locally connected master |
| LAN gateway | Ethernet Modbus bridge or ESP32 | Gateway power, IP address, local access | Reachable on LAN without vendor DNS |
| Message delivery | Mosquitto broker | Broker host, accounts, QoS, retain policy | Publish/subscribe succeeds without WAN |
| Integration | Home Assistant Shelly/Modbus/MQTT | Credentials, add-on or network connectivity | Fresh timestamped state visible via local IP |
| History | Recorder / SSD | Database health, disk free space, power | New samples persist and restore after restart |
| Supervision | Dashboard and notifications | Local browser, mobile LAN access | Staleness alarm when publisher stopped |
| External optimisation | Tariff or cloud forecast | Internet/API service availability | Falls back to documented safe schedule |
MQTT, direct local APIs and Modbus: which is best offline?
Three architectures dominate self-hosted domestic monitoring. An official Home Assistant integration may talk directly to a network device over HTTP, WebSocket or a proprietary but local protocol. MQTT uses a central broker and topics to decouple telemetry sources from consumers. Modbus reads numeric registers from a meter or inverter over serial RS-485 or TCP. None is automatically better: each moves the failure point.
MQTT is attractive when multiple gateways need to publish into one system or when you want to subscribe without polling. But the broker is now infrastructure. Direct local APIs reduce components when the official integration is mature, at the cost of tying Home Assistant to a vendor implementation. Modbus can be stable and predictable where a manufacturer publishes a complete register map, but addressing, scaling, signed values, byte order and model-specific variations are frequent integration traps. Modbus TCP is not an internet service merely because it uses TCP; it can operate entirely on a LAN.
Do not confuse transport with data quality. A locally delivered but incorrectly scaled energy register remains wrong. A beautifully designed MQTT topic hierarchy does not repair a reversed CT. Equally, HTTP polling does not inherently produce inaccurate data. Choose based on verified device support, refresh rate, recoverability, electrical isolation and the number of components you actually need.
| Criterion | MQTT + local broker | Direct local API | Modbus RTU/TCP |
|---|---|---|---|
| Extra infrastructure | Broker and its credentials | Usually none beyond HA and LAN | Serial adapter or compatible TCP gateway |
| Best fit | Mixed publishers and reusable telemetry | Vendor with supported native integration | Meters/inverters with documented registers |
| Communication model | Publish/subscribe | Push or poll, device-dependent | Typically request/response polling |
| Discovery | HA MQTT discovery or YAML | Integration-specific auto-discovery | Usually manual register configuration |
| Failure mode | Broker unreachable, topic stale | API inaccessible or incompatible firmware | Timeout, address/register or bus fault |
| Freshness checks | LWT, availability, expire_after | Integration availability and observed timestamps | Timeout and timestamp of last successful poll |
| Cloud requirement | None if every publisher local | None if vendor's documented API truly local | None for truly local bus and gateway |
| Typical security | Broker users, ACLs, TLS if needed | Device authentication and LAN ACLs | Network isolation; limited built-in authentication |
Buy hardware based on the complete offline system
The purchasing order should be reversed from the usual affiliate catalogue approach. First check the meter location, number of phases, existing inverter/EV interfaces and whether an authorised installer must open the consumer unit. Then decide what you need to retain during an outage. Only after that should you select the host, broker and display hardware. Buying a high-end smart plug for a meter cabinet is not equivalent to installing a correctly rated, certified distribution-board meter.
For permanently installed grid meters, a wired interface such as Ethernet or properly engineered RS-485 usually avoids Wi-Fi coverage limitations and password changes. A compact SSD-based mini PC is an attractive Home Assistant host for high-rate monitoring; a supported Home Assistant appliance is often simpler to maintain. Neither is universally superior. Consider cooling, power draw, accessible backups, SSD wear, quiet operation, replacement supply and what happens after a sudden power loss. If the house already has a suitable NASAliExpress price, using an existing virtual machine may reduce equipment cost but can introduce maintenance coupling with NASAliExpress price reboots.
An external MQTT broker need not be a second server. Mosquitto can run as a Home Assistant app on supported installations or on another appropriately managed machine. Co-locating simplifies deployment but means the broker disappears when the host is down. Separating it allows devices to keep publishing during a Home Assistant restart, but adds another node to power, patch and back up. Choose deliberately rather than assuming more boxes equal more resilience.
| Buying choice | What to confirm | When it is sensible | What not to assume |
|---|---|---|---|
| Ethernet-capable electricity meter | Exact model protocol, rated CTs, installation compliance | Permanent whole-home three-phase monitoring | That all Ethernet meters expose compatible registers |
| DIN-rail Modbus meter | Local register map, addressing, scaling, isolation | Dedicated circuit or import/export energy totals | That reading registers is safe for untrained installers |
| RS-485-to-Ethernet gateway | RTU-to-TCP mode, unit IDs, isolation, power | Meter is far from HA host; robust wired backbone | That transparent RTU-over-TCP equals Modbus TCP |
| Shelly Pro class device | Generation, channel limits, local RPC, CT compatibility | Supported local hardware with suitable enclosure | That every older/newer model has identical features |
| ESP32 gateway | Power supply, industrial interface, watchdog, security | Low-voltage sensors or supported isolated protocols | That bare ESP32 GPIO can connect to mains circuits |
| Home Assistant appliance | CPU/RAM/storage and supported install type | Simple always-on monitoring | That it replaces protective controls |
| SSD-based mini PC | Idle watts, UPS, BIOS restart, backup plan | Many sensors, historical data and add-ons | That a powerful CPU improves metering accuracy |
| UPS | Actual watts, battery age, shutdown behaviour | Keep network and host alive through brief cuts | That its published VA rating is runtime |
Reference architecture: one independent safety plane, one observability plane
A robust household system separates the equipment that keeps the installation safe from the tools that analyse it. The protective plane includes the electrical installation’s existing protections, approved charge-control hardware, battery management and any manufacturer-controlled heat source safeties. It may exchange data with Home Assistant, but it does not ask Home Assistant for permission to perform a mandatory protective action.
The observability plane takes measurements from a grid meter, inverter, charger and optional circuit submeter. A supported integration consumes them over Ethernet or a local broker. Home Assistant calculates totals and trends, Recorder saves history, and a dashboard highlights import/export, battery power, PV generation, EV energy and connectivity. If the observability plane fails, the electrical installation must continue operating within its certified constraints. This is why a house with a large EV load should not use an arbitrary Home Assistant automation as the sole method of preventing the incoming supply from being overloaded.
If a supervisory schedule sends requests to a heater, battery or EV charger, write down which controller has the final authority, what manufacturer bounds apply, how conflicting schedules are handled and what happens when no valid request arrives. A ‘last command wins’ design can produce surprises after a network reconnection. Prefer vendor-documented supervisory controls with an explicit timeout or safe fallback.
| Function | Independent equipment | Home Assistant role | On HA/broker failure |
|---|---|---|---|
| EV electrical protection | Approved EVSE protections and manufacturer load-management system | Observe current, cost and permitted schedule | EVSE enforces installed electrical limits |
| Battery protection | BMS and certified inverter | Read SoC and supported supervisory modes | Manufacturer default reserves and protections |
| Heat pump safety | Heat pump controller and safety sensors | Monitor temperature, schedule if supported | Local controller continues safe operation |
| Boiler safety | Boiler controls and certified installation | Monitor demand and cycling | Boiler safeguards unaffected |
| Grid meter accuracy | Calibrated meter / utility revenue meter | Display local readings and derived totals | Meter retains independent measurement |
| Energy dashboard | HA + Recorder | Historical graphs and alerts | Dashboard may be offline without affecting safety |
A local MQTT broker: what it solves and what it does not
In a local MQTT design a meter, gateway or ESPHome node publishes measurement updates to a broker at a private LAN address. Home Assistant subscribes to the broker. With suitable credentials, ACLs and a correctly configured device, no packet needs to reach the public internet for normal telemetry. Home Assistant recommends its locally hosted Mosquitto broker for a straightforward setup. A public broker is usually the wrong choice for private household measurements and control topics.
Treat the broker hostname, broker user account and topic tree as part of your infrastructure, not incidental configuration. Configure a local address or resolvable local hostname, an account dedicated to that gateway, permissions limited to the required topics and sensible payload formats. Security controls can be more involved than the YAML shown below; a password should be stored as a Home Assistant secret, not pasted into a public article, dashboard or support log.
Retained messages and availability topics serve different purposes. A retained last-known energy counter can help restore a dashboard after restart, but a retained instantaneous-power reading may look fresh while the meter is offline. A retained ‘online’ flag without a properly configured Last Will message can be equally misleading. Subscribe to a device’s availability topic, have the publisher signal offline on unexpected disconnect, and establish a freshness limit for critical telemetry. A Last Will usually detects broken broker connections, but a device that remains connected while its physical measurement sensor fails needs its own internal health check.
Home Assistant MQTT example: energy counter with a freshness limit
This example illustrates a read-only MQTT energy entity. It assumes a locally configured publisher sends a numeric cumulative kWh total to house/grid/import_kwh, sends online/offline availability messages to house/grid/availability, and updates approximately once per minute. Replace topics and refresh intervals with the actual publisher specification. Configure the MQTT broker itself through Settings → Devices & services; this fragment belongs in configuration.yaml and does not configure Mosquitto.
mqtt:
sensor:
- name: "Grid import energy local"
unique_id: grid_import_energy_local_2026
state_topic: "house/grid/import_kwh"
availability_topic: "house/grid/availability"
payload_available: "online"
payload_not_available: "offline"
device_class: energy
state_class: total_increasing
unit_of_measurement: "kWh"
expire_after: 180
qos: 1Here the explicit expire_after: 180 means the entity will become unavailable if no value arrives within the configured interval, even if the broker retains an old numeric state. That is a conservative example for a 60-second publisher, not a universal constant: a battery-powered sensor publishing only on change could legitimately go silent much longer. state_class: total_increasing is suitable only when the publisher provides a genuine cumulative meter that behaves as an increasing total with documented resets; do not apply it to instantaneous watts or a signed net-power signal.
In the publisher, set the Last Will status to offline and publish online when connected. Consider retaining availability and discovery information where supported, but decide carefully whether to retain the numeric reading. After a broker restart, retained payloads are presented as the most recently published values, not proof of present communication. The freshness limit is therefore essential even with retained state. For low-level debug access, use the broker’s own client tools and logs rather than disabling authentication across the LAN.
Direct local APIs: fewer components can mean better availability
When an officially supported integration already communicates directly with a device, adding MQTT may merely insert a new failure point. The Home Assistant Shelly integration, for example, communicates with suitable devices directly and does not need a Shelly cloud connection for normal operation. Its underlying transport differs between generations, and its documentation explains how some local push connections work. Always check your exact model and firmware rather than assuming the behaviour of a related product.
A local API is often preferable for a single supported meter that only needs to feed Home Assistant. It reduces operational responsibilities: no broker authentication, no retained message clean-up and no second topic namespace. The trade-off is that the integration may depend on the manufacturer’s particular API revision, discovery mechanism or device connection limits. Record the last known working firmware and integration versions; do not auto-update a critical gateway on the morning of an energy audit.
‘Local’ can also mean local only during steady-state operation. Some products can be controlled locally after onboarding yet still require a vendor account, app or network connection for initial setup, certificate renewal, firmware maintenance or authentication. An honest offline test includes a complete power cycle and reconnection while the WAN remains disconnected; reading yesterday’s cached value is not sufficient proof.
Modbus: predictable but exact registers and units matter
Modbus RTU over RS-485 is useful for wired meters where a published register map exists. Modbus TCP can simplify a house-wide connection when the meter or gateway has Ethernet. Home Assistant documents tcp, serial and rtuovertcp connection types. Those terms are not interchangeable: a transparent serial bridge that passes RTU frames through a TCP socket is not necessarily a native Modbus TCP server.
A register address from a PDF is not automatically the number to place in every integration. Some manuals use one-based register numbering or ‘3xxxx/4xxxx’ conventional notation; some libraries expect a zero-based offset. Signed versus unsigned integers, 16-bit versus 32-bit words, word order and decimal scaling can produce persuasive but wrong power readings. Test against the manufacturer’s display over multiple load conditions and power directions. If a meter reports negative net power for export, do not turn that into a cumulative import energy counter by clipping instantaneous values unless you explicitly understand the accuracy implications.
Polling more often than a device can serve may cause timeouts, rising latency and overlapping traffic. Start with the manufacturer’s recommended interval, then measure actual response times. For a simple energy dashboard, fresh data every few seconds can be more than adequate; sub-second polling is often unnecessary. The HA Modbus integration documents timeouts and optional delays. Respect shared-bus ownership and any limits on concurrent Modbus TCP sessions, especially where an inverter already has a manufacturer control gateway.
Example Modbus TCP connection skeleton
This skeleton defines a local Modbus hub only. It deliberately omits sensor registers because using fictional addresses would produce misleading measurements. Add sensors only from the exact installed meter’s official register map, after verifying unit ID, address base, function, scaling and register type. Network access should be restricted to trusted controllers.
modbus:
- name: energy_meter_local
type: tcp
host: 192.168.10.40
port: 502
timeout: 5Meter sources of truth: instantaneous power is not cumulative energy
One recurring failure in home energy systems is treating a dashboard estimate as if it were a revenue-grade meter. Instantaneous power is measured in watts or kilowatts; cumulative energy is measured in Wh or kWh. The integral of power over time approximates energy, but timing gaps and telemetry loss introduce error. If the device exposes a reliable cumulative import counter, prefer that counter over repeated integration of instantaneous watts. If it exposes separate import and export totals, preserve both directions rather than combining them into one signed number.
Most Home Assistant Energy Dashboard inputs are cumulative energy sensors that use the correct device class, state class and unit. A negative net-power trace can be useful in a chart while remaining unsuitable as the Energy Dashboard’s cumulative import source. The utility bill provides an independent reconciliation point but may use different boundaries: import/export register reading periods, CT locations, supply metering arrangement and daylight-saving changes all matter.
During a communication outage, a utility meter may keep accumulating internally. Once its cumulative counter is reachable again, a new reading includes energy used while Home Assistant was disconnected. However, that does not recreate accurate minute-by-minute or hourly allocation across the gap. Recorder and long-term statistics may attribute a difference to the time data resumes; tariff analyses for missing intervals need an explicit uncertainty or interval-level reconciliation, not invented allocation.
| Signal | Unit | What it means | Correct offline recovery |
|---|---|---|---|
| Grid power | W/kW | Instantaneous import or export rate | Unavailable while stale; do not carry forward in graphs |
| Grid import total | kWh | Cumulative imported electricity | Read authoritative current total after reconnect |
| Grid export total | kWh | Cumulative exported electricity | Read separate authoritative total |
| PV energy total | kWh | Inverter cumulative generation | Verify inverter reset/restart semantics |
| Battery power | W/kW | Instantaneous charge/discharge | Observe sign convention; stale is not zero |
| Battery charged total | kWh | Charge throughput depending on metering boundary | Inspect counter and retention on restart |
| EV session energy | kWh | Charge delivered in a session | Do not silently sum resettable session counter as lifetime |
| Electricity price | currency/kWh | Price valid for specific contract and interval | Mark unavailable if feed is stale; retain safe schedule |
Retained state, Last Will and the “stale but plausible” problem
A particularly dangerous dashboard is one that stays neat and numerically stable while its sensors have stopped. A retained MQTT state can be replayed minutes or months after it was measured. The broker is doing exactly what it was asked to do: retain the last message. That says nothing about the freshness of the physical quantity. For instantaneous power, stale values can mislead a user into believing solar PV still produces 3 kW while clouds have passed or the inverter has shut down.
Use availability and freshness together. Availability says whether the publisher considers its connection healthy; freshness says whether a measurement has arrived recently enough to matter. The MQTT integration supports availability topics and Last Will, and the MQTT sensor supports an expiry interval. For Modbus or a direct local API, a failed poll or local API timeout should likewise be reflected as unavailable instead of ‘0 W’. Zero means you measured zero; unavailable means you cannot presently measure.
There are nuances. A cumulative kWh total is allowed to remain unchanged when a house draws no energy; lack of numeric change is not evidence of failure. Conversely, a device that continually republishes the same stale counter can satisfy a message-based expiry rule while its internal sensing has failed. Where hardware permits, publish an independent update timestamp, device uptime or measurement-quality status. For meaningful alerts, distinguish ‘transport connected’, ‘data recently received’ and ‘underlying meter sample updated’.
| Data state | Dashboard interpretation | Possible cause | Preferred response |
|---|---|---|---|
| 0 W, fresh | Known zero power at measurement time | Night-time PV or truly idle load | Display zero with current timestamp |
| Last 3 kW, 2 hours old | Unknown current power | Publisher disconnected; retained MQTT | Display unavailable, not 3 kW |
| Import total unchanged, heartbeat fresh | Potentially normal | No measured import or static test load | Check independent sample timestamp |
| No Last Will, old online retained | False healthy status | Publisher never configured LWT | Fix publisher and availability policy |
| Meter total jumps on reconnection | Missed intermediate samples | Outage while local meter kept counting | Keep total; flag interval allocation unknown |
| Meter total resets to zero | Counter reset or firmware change | Restart or session counter used | Check state_class semantics before integrating |
| New unknown entity after restart | Discovery/unique ID problem | Unretained config or renamed topic | Stabilise unique IDs and birth/discovery |
ESPHome, MQTT and native API: deliberate failure behaviour
An ESP32-based gateway can be useful when reading a supported low-voltage sensor or an isolated meter interface. ESPHome exposes a native API and optional MQTT client, but mixing them casually can create unexpected resets. ESPHome documentation notes that if MQTT is enabled without a functioning native API client, leaving api: enabled with its default reboot timeout may cause a device to restart after approximately 15 minutes because no API client connected. If you intend MQTT-only operation, follow the documentation: remove the unused native API configuration or deliberately change the documented reboot behaviour.
That issue is not proof MQTT is less reliable; it is a configuration interaction. Similarly, setting reboot_timeout: 0s suppresses that particular recovery restart, which could be desirable for a gateway that must function without HA but also removes a watchdog mechanism. Decide based on how the node measures independently and how it recovers from genuinely wedged network states. Use physical watchdogs or firmware fail-safe mechanisms appropriate to the application, not an arbitrary timer copied from a forum.
Avoid connecting bare ESP32 ADC pins, GPIO or hobby relay boards directly to mains, CT secondaries, inverter terminals or meter communication ports. Use properly rated, isolated interfaces and follow manufacturer documentation; work inside mains distribution equipment must be completed by competent authorised personnel. This guide describes software architecture and monitoring only, not modifications to electrical protective equipment.
Local network design: switching, IP addresses, Wi-Fi and DNS
A home network is usually treated as invisible plumbing until it fails. A robust monitoring design has a clear inventory of fixed IP assignments or DHCP reservations, a dependable local DNS resolver, an explicit clock source and named ports that need to communicate across any VLAN boundaries. Reserve an address for Home Assistant and for fixed Modbus gateways, or use a stable local hostname that remains resolvable when the ISP DNS fails.
Separating trusted infrastructure and less trusted IoT devices into VLANs can improve security, but communication still needs to pass in the correct direction. MQTT clients must reach the broker; direct local discovery may need multicast or broadcast across a boundary; and some vendor devices open WebSocket sessions back to the HA host. A static address or firewall rule alone does not guarantee discovery. Test both automatic discovery and sustained data flow after power cycles. A network that works only until a device renews its lease is not resilient.
Ethernet is a strong default for stationary infrastructure, but it is not magical: an unmanaged switch can fail, a PoE budget can be exceeded, and a faulty cable can repeatedly negotiate new links. Wi-Fi can be perfectly adequate for non-critical monitoring with good signal and roaming design. When choosing between a cheaper Wi-Fi gateway and a wired model, ask whether the additional cabling saves more support time than it costs, especially when a metal meter cabinet attenuates signals.
| Dependency | Low-maintenance implementation | Specific failure to simulate | What to document |
|---|---|---|---|
| IP addressing | DHCP reservations or planned fixed IPs | Router power cycle and address renewal | Address plan and management access |
| DNS | LAN-resolvable local hostnames | ISP DNS inaccessible | Resolver ownership and fallback |
| Time | Reliable device time and HA clock | Restart without internet NTP | Clock recovery and timezone |
| Switching | Reliable switch for wired meters/host | Router-to-switch link unplugged | Which links stay up |
| Wi-Fi | Adequate coverage and stable AP | AP restart while broadband remains | Reconnect delay and data gaps |
| IoT segmentation | Minimum required firewall rules | Reconnect after VLAN policy change | Allowed direction, ports and discovery |
| Remote access | VPN or supported secured remote service | WAN unplug and local login | Local admin access independent of cloud |
| Credentials | Unique device/broker accounts | Credential or certificate renewal | Secure documented recovery process |
Power resilience: size the UPS for measured watts, not a marketing VA figure
A small UPS can make a genuine difference when the fault is a brief power interruption: it may keep the Home Assistant host, core switch, Wi-Fi access point, broker and Ethernet gateway available. But it does not protect a sensor or inverter that has lost its own supply. Before buying a UPS, measure the combined real load in watts and define the minimum runtime you require. UPS runtime curves, age and operating temperature matter more than the nominal volt-ampere label alone.
For example, a 12 W mini PC, 6 W network switch and 8 W router draw 26 W in total. Over a one-hour outage that is 26 Wh of delivered electrical energy before conversion and battery losses. If we assume 70% end-to-end usable efficiency and reserve, a nominal battery requirement is approximately 26 / 0.70 = 37 Wh for that hour. This is a simplified sizing illustration, not a UPS selection specification; real capacity depends on the UPS architecture and discharge-rate performance. Check the manufacturer’s runtime chart at the actual load, and allow for battery ageing.
Consider graceful shutdown, automatic BIOS power-on, USB monitoring, router restart sequencing and whether a device’s firmware performs filesystem writes. A powered but isolated router is only helpful if it can serve the local LAN after the WAN drops. For homes where outage monitoring is valuable, test the battery backup with the broadband cable physically removed as well as a power interruption.
| Host/network load (illustrative) | Load | Outage target | Delivered energy | Nominal store at 70% usable |
|---|---|---|---|---|
| Small HA host + router + switch | 26 W | 1 hour | 26 Wh | 37 Wh |
| Same equipment | 26 W | 2 hours | 52 Wh | 74 Wh |
| Mini PC + NAS + network | 70 W | 1 hour | 70 Wh | 100 Wh |
| Larger always-on cabinet | 110 W | 2 hours | 220 Wh | 314 Wh |
Energy data after reconnection: recover totals, not fictional intervals
What matters most after an interruption is the difference between a device’s physical internal accumulator and the samples Home Assistant happened to receive. A genuine accumulating import meter can bridge an outage without losing the aggregate quantity. If the previous reading was 14,210.4 kWh and the next valid reading is 14,212.0 kWh, the meter has observed an additional 1.6 kWh. You cannot tell from those two readings whether it happened early or late during the gap, how much occurred in an expensive tariff period, or how much coincided with solar production.
If a meter restarts and its local counter resets, the recovery is different. A total_increasing sensor may represent a real reset under documented conditions, but a random API glitch reporting zero is not evidence of a legitimate reset. Before applying an offset or adjusting historical data, compare the device display and stored state, export diagnostic records, and determine whether the register means session energy, lifetime energy or daily energy. A badly handled reset can create phantom consumption or erase real energy.
The Home Assistant Recorder persists state changes and supports short- and long-term statistics for qualifying sensors. The default Recorder database needs available storage and a reliable shutdown; the official documentation recommends suitable storage instead of relying on heavy writes to low-end flash media. If history is mission-critical, define a tested backup process and restore drill. No amount of MQTT retention substitutes for a backup of Home Assistant configuration, dashboards, entity registry and recorder data.
| Outage scenario | What you can recover | What remains uncertain | Recommended reconciliation |
|---|---|---|---|
| WAN unavailable, LAN and HA active | Full local samples | Vendor cloud-only channels | Cross-check local meter against later bill |
| Broker down, meter accumulating | Net change in cumulative kWh | Sub-minute profile during interruption | Annotate unavailable window |
| HA host offline, meter accumulating | Latest cumulative totals on return | Tariff allocation across outage | Compare register endpoints and supplier interval data |
| Meter without retained counter | Possibly nothing from missed period | Actual energy used | Use independent revenue meter where available |
| Device time lost | Totals if trustworthy | Original timestamps | Restore clock, flag history uncertainty |
| Database corruption | Backup and live current readings | Unbacked-up historical intervals | Restore tested backup, verify statistics |
| Vendor cloud service down | Local readings if exposed | Cloud analytics and remote control | Prefer manufacturer-documented local data source |
Freshness dashboard: one visible check before trusting the data
The simplest operational improvement is to show whether the most important energy reading is available. A raw total imported kilowatt-hour value may look reassuring while its source is disconnected. Display a separate connectivity state and, where possible, last successful meter sample timestamp. Use the Home Assistant developer tools to check the actual entity state while deliberately disconnecting the publisher. Make sure the dashboard says “unavailable” rather than carrying forward yesterday’s watts.
The following example creates a diagnostic binary sensor based on the MQTT import-energy sensor above. It is a transport freshness proxy: it inherits the MQTT entity’s availability and expiry semantics, not the physical measurement’s independent health. An external diagnostic based on published hardware timestamps would be even better where available. The template is intentionally read-only and is not used to command a load.
template:
- binary_sensor:
- name: "Grid import telemetry healthy"
unique_id: grid_import_telemetry_healthy_2026
state: >-
{{ has_value('sensor.grid_import_energy_local') }}
device_class: connectivityhas_value() is a Home Assistant template helper that checks whether the referenced entity has a valid state rather than unknown/unavailable. Confirm the final entity ID in Developer Tools, as Home Assistant may generate a different ID when an entity with the same name already exists. This sensor intentionally answers a narrow question: “Do we currently have a non-unavailable MQTT import-energy state?” It does not claim that the reading has metrology-grade validity.
For automated notices, start with notifications that require several minutes of continuous unavailability. Alarm immediately only if that matches an actual operational requirement. Do not send persistent alarms for an intentionally sleeping battery node or intentionally stopped system. A dashboard used for financial tracking should make missing data visible; a controller used for protective curtailment must not rely on this template in lieu of its approved hardware.
Worked scenario 1: grid meter, PV inverter and Home Assistant all local
Consider a three-phase house with a local grid import/export meter, a PV inverter providing local telemetry, and Home Assistant on an SSD-based host. The grid meter feeds a wired gateway, the inverter exposes its supported local API, and HA records three sources: grid import/export totals, PV cumulative generation and—if fitted—battery charge/discharge totals. An ISP outage should not affect these measurements if each integration is genuinely local.
Suppose a six-hour WAN interruption begins at noon. The house consumes 9.0 kWh, PV generates 12.0 kWh, 5.0 kWh is exported and the battery ends 2.0 kWh more charged than it started (ignoring small conversion losses for this illustration). Those numbers must be checked against a consistent topology; they are not blindly additive. If every source reports fresh local totals, the Energy Dashboard can continue showing consumption and production while price and weather-forecast feeds may be unavailable.
A second test removes the Ethernet cable from the meter gateway. The inverter continues delivering readings, but the grid meter should become unavailable after its timeout. No automation should now assume ‘zero grid import’. On reconnection, the meter’s cumulative kWh registers bridge the gap, but the high-resolution grid trace remains incomplete. Document this clearly in a measurement quality note rather than drawing a smooth interpolated trace and labelling it measured.
Worked scenario 2: MQTT relay server restarts during the night
Now assume three ESP32 telemetry nodes publish low-voltage measurement data via MQTT every 30 seconds. The local broker restarts for a security update. MQTT clients will normally attempt to reconnect subject to their library and firmware configuration; they may then republish discovery and current state. Home Assistant may momentarily show unavailable entities. A resilient setup lets the broker restart, re-establishes authenticated client sessions and brings values back without needing someone to unplug devices.
If each publisher retains only its last instantaneous value, the first screen after restart may show numbers measured before the interruption. The correct acceptance test is not merely “the tiles reappeared” but “the update timestamp advanced and matched the live physical condition”. Switch a known low-risk test load and verify that the reading responds. If the sensor has an internal cumulative counter, compare pre- and post-restart totals to determine whether it counted the whole interval.
Recovery time depends on reconnection backoff, the broker’s persistence settings, Wi-Fi association time and the publisher’s retry logic. Do not promise a universal ten-second restart. Record the observed delay and verify that automation does not emit its previous queued command after the network returns. For monitoring-only publishers, re-delivery of the latest state is generally safe; for command topics, old retained commands can have undesirable consequences.
Worked scenario 3: router fails but wired switching remains online
Suppose a house has a standalone Ethernet switch, a mini PC, local meter and Ethernet inverter gateway. The all-in-one broadband router is unplugged. Depending on the network design, already established devices with valid addresses on the same subnet may still communicate through the switch, but no new DHCP leases are issued and the configured DNS server may disappear. A tablet connected to the router’s built-in Wi-Fi will lose the dashboard even though Home Assistant and the meter continue exchanging packets through the wired network.
The lesson is that “internet-independent” does not mean “router-independent”. If router survival matters, provide a reliable separate Wi-Fi access point and local address/DNS services—or define router failure as an acceptable monitoring outage. Avoid speculative complexity such as building redundant routers for a simple energy display unless you actually have the technical expertise to maintain and test them.
As a purchase decision, spending a little more on the correct wired gateway and basic UPS may be more valuable than a large graphical dashboard. But that statement depends on the failure you care about. A family that needs only monthly bill checks may sensibly accept a few hours of missing fine-grained traces, while a remote off-grid installation could justify extensive local infrastructure.
Worked scenario 4: offline EV charging without unsafe dependencies
An EV charger may retain local electrical protections, basic charging and perhaps an internal charging schedule during an outage while cloud-based monitoring and smartphone control disappear. Confirm those behaviours for the exact charger model and firmware. If the installation depends on dynamic load management, the approved meter and controller arrangement should be tested under the manufacturer’s documented loss-of-measurement conditions by the responsible installer, not replaced by a Home Assistant template or a general CT.
A Home Assistant dashboard can show grid current and charging energy while the LAN is healthy. During a broker outage, those states must become unknown rather than display the last-known current as live. Similarly, an automation that sends a cheap-tariff charging instruction should fail to a pre-agreed safe schedule if the tariff feed is unavailable; it must not blindly reuse yesterday’s price list. The hardware must still observe cable, RCD, phase and supply limits independently.
When internet returns, the charger may upload the accumulated session data to its vendor app. Compare that reported session energy with the local meter and understand whether one measures output delivered to the vehicle and the other measures input from the grid, including losses. Do not force the two values to match by editing Home Assistant totals without investigating boundaries.
Total cost: where resilience spending is justified
A genuinely offline-capable system can be inexpensive when the meter you already own has an official local integration. The incremental cost might simply be an Ethernet connection and a reliable always-on Home Assistant host. At the other end, professional distribution-board metering, isolation, gateways, UPS and installation can exceed the price of the monitoring server itself. This is why a buying guide should separate equipment, labour, software, electricity, replacement parts and support effort.
The illustrative comparison below is not a current retailer price list. It is a five-year decision model using round-number assumptions so you can substitute quotes. Example A reuses a local meter and existing HA host; example B adds a dedicated gateway, network UPS and SSD host; example C is a more involved three-phase retrofit requiring professional metering and networking. Some products already include the required CTs; others need model-specific CT accessories. Installation, electrical testing and compliance costs vary widely by property and country.
The best value is not always the lowest initial cost. If a cloud-only product stops working when the internet fails or vendor support ends, its apparent saving may disappear. Conversely, spending hundreds of pounds on redundant brokers to preserve data for a dashboard viewed once a month is difficult to justify. Start with the outage consequences, measure the baseline and buy the lowest-complexity setup that meets a written requirement.
| Five-year scenario (illustrative) | Existing host + local meter | Dedicated local monitoring | More involved wired retrofit |
|---|---|---|---|
| Meter/gateway incremental equipment | £0 | £120 | £350 |
| HA host / SSD investment | £0 | £180 | £250 |
| Networking/UPS | £0 | £120 | £250 |
| Professional installation/testing | £0 | £180 | £500 |
| Power and replacement allowance | £90 | £150 | £220 |
| Indicative five-year total | £90 | £750 | £1,670 |
| Appropriate use | Existing reliable local system | Small/medium house with higher availability goal | Three-phase house with formal metering and uptime requirements |
What performance should you actually measure?
Reliable monitoring is not synonymous with a fast dashboard. Define a small set of objective service metrics before changing the system: proportion of a day with fresh telemetry; maximum gap in successful cumulative meter samples; time to recover after an intentional broker restart; difference between accumulated consumption and the revenue meter; number of false stale alarms; and time needed to restore a working backup. Measurements prevent the common mistake of confusing a graph that looks smooth with a robust installation.
For example, with 1,440 expected one-minute samples in a day, receiving 1,425 valid timely samples is 98.96% sample completeness. This does not prove 98.96% energy accuracy. If the 15 missing samples coincide with an EV charging at 7 kW, a power-only integration that assumes zero for the gap can miss roughly 7 kW × 0.25 h = 1.75 kWh. A cumulative energy register, if truly maintained during the outage, can recover the aggregate energy but not exactly which of the missing minutes contained it.
A realistic objective for a hobby energy dashboard might prioritise correct daily totals and automated recovery rather than sub-second completeness. An energy audit or load-profile study may need stricter timestamp quality and a written uncertainty budget. Choose metrics based on the purpose—not on what happens to be easy to plot.
| Metric | How to calculate | Why it matters | False comfort to avoid |
|---|---|---|---|
| Sample completeness | Valid, timely samples / expected samples | Find communication gaps | Confusing completeness with meter accuracy |
| Recovery time | Time from restored path to verified live sample | Prove automatic reconnection | Counting retained replay as recovery |
| Energy reconciliation error | Absolute HA-total vs reference meter difference | Check total measurement integrity | Comparing unlike metering boundaries |
| Stale-state detection delay | Loss of source to unavailable state | Prevent misleading dashboards | Using fixed power value as proof alive |
| DB recovery time | Restore start to usable history and automations | Test recoverability | Having untested local-only backups |
| Offline autonomy | Minutes/hours system works as specified without WAN | Match availability requirements | Testing only the broadband icon |
| UPS runtime | Measured run until controlled shutdown | Validate power resilience | Using only a printed VA rating |
Installation and commissioning checklist
Commissioning should proceed from physical measurement towards visualisation, not in reverse. First inspect the electrical work performed by the responsible professional; confirm meter type, CT orientation, neutral/phase relationships and permitted protection devices. Document the hardware identity, site plan, network addressing and control ownership. A working Dashboard tile does not certify the electrical installation.
Next verify local transport without public internet. Unplug the WAN link while leaving the LAN operating, then switch a known, safe test load and observe whether a current power value changes appropriately. Compare cumulative meter totals at the beginning and end of a known interval. Restart the gateway, the broker and Home Assistant independently. Record recovery time and ensure no stale state is interpreted as zero. Do the same with a Wi-Fi access point or router only where your architecture aims to tolerate that particular failure.
Finally, test the human-facing behaviour: dashboard stale-state label, backup completion, administrative login over the local network, failure notifications, firmware update rollback plan, accessible configuration, and safe fallback for each supported scheduling feature. Keep one short commissioning record with date, version numbers, energy-counter screenshots and the measured differences against a trusted reference meter.
- Inventory actual meter, inverter, charger, host, gateway, broker and network hardware models and firmware.
- Confirm certified installation, rated CTs and manufacturer-supported physical interfaces.
- Record every cloud, DNS, DHCP, time-sync and broker dependency.
- Test local data with the WAN physically disconnected, including after a full device reboot.
- Verify both instantaneous W and cumulative kWh, with separate import/export totals.
- Check MQTT Last Will, discovery, retained-state strategy and stale-reading expiry.
- Unplug the meter or gateway and prove the dashboard shows unavailable, not zero.
- Restart broker, Home Assistant, router and Wi-Fi individually; record recovery times.
- Compare start/end meter energy totals and investigate any false reset.
- Confirm any load control is manufacturer-supported and safeguards continue independently.
- Test a backup restore and document host/storage/UPS replacement steps.
- Set a calendar reminder to repeat offline and restore tests after major infrastructure changes.
Troubleshooting: common offline monitoring failures
| Symptom | Likely cause | First diagnostic step | Safe resolution |
|---|---|---|---|
| Dashboard works online, blank offline | Cloud source or authentication | Block WAN, query actual local device address | Use supported local integration or accept cloud limitation |
| Meters visible after reboot, data frozen | Retained MQTT stale state | Check last publisher timestamp and availability | Configure expiry/Last Will and publisher health |
| MQTT devices missing after HA restart | Discovery payload not replayed | Inspect broker retained discovery and HA birth | Publish on birth or retain valid discovery |
| ESPHome MQTT node reboots repeatedly | Unused native API watchdog | Check ESPHome API reboot_timeout and logs | Follow official MQTT-only configuration |
| Modbus value wildly inaccurate | Wrong register/scale/signedness | Compare exact model register map | Correct mapping; no blind offset |
| Modbus gateway intermittent | Serial settings, wiring or multiple clients | Inspect timeouts, polling frequency | Correct bus configuration with competent technician |
| HA shows 0 W during device outage | Template defaulting unavailable to zero | Unplug sensor while viewing raw state | Preserve unknown/unavailable state |
| Daily kWh jumps on reconnection | Long gap in cumulative total updates | Compare meter display and history window | Keep real aggregate, flag interval uncertainty |
| No local hostname resolution | DNS service depends on router/WAN | Access device by known LAN IP | Plan local DNS/addressing |
| Power cut loses history | Unbacked-up recorder database | Inspect storage and backup logs | UPS and tested restore process |
| Charger schedule changes unexpectedly | Multiple schedule controllers | Audit vendor, HA, car schedules | Choose a single supervisory owner |
| App cannot connect after ISP fault | Remote-only app path | Try trusted LAN browser to HA host | Use documented local access; retain secure remote service separately |
Frequently asked questions
Will Home Assistant keep working without an internet connection?
Yes, its local interface, Recorder and locally integrated devices can continue while the Home Assistant host and LAN remain available. Cloud integrations, external tariff feeds, remote access and any vendor authentication that requires internet may stop. Test individual integrations rather than assuming all behave alike.
Does MQTT need internet?
No. MQTT can run with a broker and publishers/subscribers entirely on a local network. If you point clients to a public broker or cloud-to-MQTT bridge, the data path is no longer internet-independent.
Is MQTT more reliable than a local API?
Not automatically. MQTT adds a broker as a dependency but can decouple many publishers. A mature direct local integration is often simpler for one device. Reliability depends on the whole deployment, not the protocol name.
Should I run Mosquitto on Home Assistant or separately?
On the Home Assistant host is simpler. Separately hosted MQTT may keep collecting from publishers during a HA restart if the publishers and broker remain powered, but costs more maintenance and infrastructure. Pick based on the failure you must survive.
Are retained MQTT values safe to use for live power?
Only with a clear freshness and availability policy. Retained messages are the last published values, not proof of present measurement. Avoid using old retained commands for control and never mistake a retained 3 kW value for an actual current reading.
Why does an ESPHome MQTT device reboot about every 15 minutes?
A configuration that leaves the native API enabled without a client can trigger its documented default reboot timeout. Follow ESPHome guidance for MQTT-only use, and consider the implications of disabling that watchdog rather than copying a setting without review.
Can I use Modbus TCP without any cloud service?
Yes, where the meter or gateway supports a genuinely local Modbus TCP server. You need the exact register map, correct network addressing, a supported client and secure network design. A transparent RTU-over-TCP bridge may require different settings.
Can I use a CT clamp and ESP32 instead of a certified meter?
A correctly designed and isolated sensor can be useful for non-critical monitoring, but hobby circuitry is not a substitute for utility metering or electrical protections. Do not connect bare ESP32 pins to mains or work in a distribution board without competent authorised personnel.
Will Home Assistant lose electricity used while it was offline?
A physical meter with a persistent cumulative kWh counter usually keeps accumulating even if Home Assistant cannot read it; the next reading can recover the aggregate difference. Minute-by-minute consumption during the outage cannot be reconstructed from endpoints alone.
Why does my Energy Dashboard show incorrect consumption after reconnecting?
Possible causes include meter resets, stale counters, wrong state class, import/export direction confusion or a long data gap. Compare the physical meter and HA statistics before changing data; do not replace an unavailable reading with zero.
Is a UPS necessary for offline monitoring?
Only if the system must remain available during power interruptions. A UPS does not help with a mains-powered meter that has stopped measuring. Calculate runtime from real watts and verified UPS curves, allowing for battery ageing.
Do I need Ethernet everywhere?
No. Ethernet is a good default for stationary infrastructure and metal cabinets; reliable Wi-Fi is suitable for many non-critical sensors. More important is knowing exactly which failure each device tolerates.
Will local operation continue if the router breaks?
Maybe. Existing wired devices on the same switched subnet can often communicate without the router, while DHCP, DNS, Wi-Fi and inter-VLAN routing may fail. Test your specific topology.
Can I run an EV charger load-management system through Home Assistant?
Home Assistant can monitor and send supported supervisory requests, but must not replace the charger’s approved electrical protections or installer-commissioned dynamic load-management equipment. Verify the manufacturer’s offline behaviour and fail-safe logic.
What is the right offline behaviour for electricity prices?
Treat missing or stale prices as unavailable and follow a known, bounded fallback schedule. Do not assume that yesterday’s cheap interval or a zero price still applies.
Does Grafana improve offline reliability?
Grafana is a visualisation service. It can help analyse measurements, but it adds no physical metering accuracy and is another application to power and maintain. Home Assistant’s built-in dashboards are sufficient for many users.
What should I buy first for a cloud-free energy system?
Start by verifying the existing meter or inverter’s local interface, then the stability of your LAN, Home Assistant host and backups. Purchase additional MQTT gateways, UPS or Ethernet equipment only after identifying a specific missing capability.
How often should I test recovery?
After major network, firmware or Home Assistant updates, and periodically according to how important the data is. A documented WAN-disconnect, broker-restart and backup-restore test gives much better assurance than relying on a product label.
Official technical references and further reading
- Home Assistant: MQTT integration, Last Will, discovery and availability
- Home Assistant: MQTT sensor, expiry and energy state
- Home Assistant: Modbus integration
- Home Assistant: Shelly integration
- Home Assistant: Recorder storage and failure handling
- Home Assistant: Long-term statistics
- Home Assistant: Backup integration
- ESPHome: MQTT client configuration
- ESPHome: Native API component
- ESP32.co.uk: Verifying Home Assistant energy data against a utility bill
- ESP32.co.uk: Local energy monitoring options
Final verdict: buy for recoverability, not just cloud-free branding
For most houses the best offline setup is surprisingly simple: a supported local energy meter, a stable wired or well-engineered wireless LAN, a modest always-on Home Assistant host, Recorder on reliable storage and a tested backup. Choose the official local API when it does the job. Add MQTT where publisher flexibility genuinely helps, or Modbus where the meter exposes a documented interface. Avoid unnecessary middleware, unsupported register hacks and integrations that transform missing telemetry into false zeros.
If energy monitoring matters during failures, spend first on the component that removes your actual single point of failure: perhaps an Ethernet gateway in a metal meter cabinet, a UPS for the switch, a second copy of your Home Assistant backup or a documented local access method. Confirm that the system restarts and shows fresh, trustworthy values after the outage. No dashboard, whether it uses Home Assistant cards or Grafana, can compensate for a measuring device that was offline and never accumulated the missing energy.
Finally, keep the boundary between observability and electrical safety explicit. The automation server can estimate, alert, schedule within published limits and help compare bills. It should never be the only component preventing an EV charger, battery or heating system from breaching its certified operating conditions. That separation is what makes a local smart-energy system both useful and resilient.
