If a SONOFF power-monitoring device still switches in Home Assistant while its power, current or voltage readings stay frozen, check the connection route. SonoffLAN documents an eWeLink cloud restriction on those updates during 2026 and added a local update path in v3.11.0. That is a known explanation for the reported symptom, not a diagnosis of every frozen reading.
Local reachability, exact device/firmware support and the kind of sensor all matter. This guide explains the documented fix and shows how to verify the path, including a separate IoT VLAN. It uses project releases and code, with no new device or network test.
The symptom: numbers frozen, switching fine
The reported pattern is relay control continuing while measurement values stop advancing. Switching successfully does not prove every sensor attribute has a working update route. Check whether the readings are truly stale under a changing load, rather than a stable load that correctly produces similar values.
Also check when the value was updated, whether the device is online and whether other properties are fresh. An unavailable entity, failed local request, disabled sensor or reporting filter can produce a similar dashboard result. Do not assume a cloud restriction merely because a graph is flat.
SonoffLAN’s current README separately says THR316D/THR320D temperature and humidity updates require a local connection. That makes local diagnosis relevant to those models too. It does not establish that every TH function or every switching operation was unaffected.
What actually happened: the documented cloud restriction
The SonoffLAN README says power, current and voltage updates were blocked on the cloud path beginning in 2026 because they placed a heavy load on eWeLink. Treat that as the maintainer’s documented limitation of this integration path, rather than a promise about all eWeLink APIs and third-party applications.
Issue #1755, opened 5 March 2026, contains an email response reproduced by a participant. It attributes the restriction to excessive polling of real-time power interfaces by SonoffLAN. The quoted message is useful corroborating context, but this article cannot independently authenticate the sender or turn it into a wider company policy.
The precise start date is not established. March reports and release work provide a documented timeline; they do not establish an exact date for the server-side change. A closed duplicate issue also does not prove that the restriction has been lifted.
The project currently warns that these real-time cloud updates are unsupported. Future service behavior can change. Check the installed integration and current project notes instead of treating a restriction as permanent for every device and future version.
The fix: SonoffLAN v3.11.0 and local-protocol updates
SonoffLAN v3.11.0, released 19 March 2026, explicitly added local updates for power, current and voltage and rewrote local device-update handling. The release also notes that the cloud restriction remained. This is an integration-side recovery path for supported devices, not a firmware change that gives every device a new local protocol.
The current released version checked here is v3.13.1. Its release also enables local ping for devices configured with a YAML host address. That is relevant to older cross-VLAN reports that assumed manual IP configuration could never work.
Update through HACS or the project’s documented manual method, then restart Home Assistant as required for the installed integration. Review intervening release notes and preserve the working configuration first. A version number alone does not establish that your exact device can supply every reading locally.
Why “local” fixed what “cloud” broke
The supported route sends measurement requests and responses between Home Assistant and the device over the LAN. It avoids the restricted cloud update call. The released local-update logic chooses refresh commands by device type and retries local availability; it is not one universal command for all SONOFF hardware.
A similar dependency distinction appears in our Mijia outage article: a local command route can keep a function available when a cloud route fails. That does not make every part of an installation account-free. SonoffLAN normally retrieves the device list and encryption keys through an eWeLink account and caches them; auto mode can still contact the cloud.
Checking your own setup
- Identify the measurement. Separate instantaneous
power,currentandvoltagefrom accumulated or historicalenergy. The latter has model-specific local and cloud paths. - Check version and device support. v3.11.0 is the documented local-update change. Use a compatible current release and compare the exact model, UIID and firmware with the project list.
- Inspect connection state. Enable the device’s diagnostic connection sensor if it is disabled. The released code uses
local,cloud,duplexornone. Duplex means both routes are available, not that every sensor used both or that all values are fresh. - Check integration mode. The README recommends
auto, which uses local when available and keeps cloud functions available. Its local-stability and device-specific caveats still deserve attention; do not assume the release removes every POW/TH cloud dependency. - Observe a controlled update. Check logs and values while changing a safe, ordinary load or comparing the device’s available display/app reading. For a supported force update, the README documents
homeassistant.update_entityon a device’s non-sensor entity, such as its switch. A cloud-only connection does not become local by requesting another update.
If measurements arrive locally but the displayed state stays unchanged, inspect the device’s configured reporting filters and HA entity/history behavior. The source route, incoming data and dashboard publication are separate checks.
mDNS normally operates on the local link; routers do not simply forward its multicast discovery between VLANs. A reflector/proxy can provide discovery, but routed local control and return traffic also need working firewall rules. Discovery alone does not prove a device’s HTTP requests can succeed.
The older manual-address issue #1427 is not a current prohibition on setting an IP. In v3.13.1, the released registry initializes local checks for a configured host. For an already configured device with the correct identity/key, the documented YAML option can supply its address:
sonoff:
devices:
'1000xxxxxx':
host: 192.168.30.25
Replace the example key with the exact device ID and the address with the actual device address. Merge into an existing sonoff: block, validate configuration and restart Home Assistant. This supplies an address; it does not manufacture an encryption key or add an unsupported device protocol.
The released local client normally sends HTTP to the device on TCP 8081, unless an explicit host port is provided. Allow the required HA-to-device request and stateful return traffic, using the actual model/port. For multicast discovery/events, configure only the necessary reflected services and check the result. Start with a same-LAN test if you need to separate integration support from VLAN rules; a failed routed test is not proof that every device needs a reflector.
| Check | Expected evidence | Limit |
|---|---|---|
| Integration version | v3.11.0 introduced local power/current/voltage updates | Exact model/firmware must support the path |
| Auto mode | Local preferred when available; cloud retained for other functions | It is not a zero-cloud mode |
| Connection sensor | Local or duplex when a local route is available | Availability does not prove each reading refreshed |
| Separate VLANs | Discovery or explicit host, plus routed request/return traffic | A reflector alone does not fix all local connectivity |
| Historical energy | The exact model’s supported energy route and update cadence | Do not assume instantaneous-power recovery makes every total local |
Which devices this affects
Check the exact product rather than treating the SONOFF name as a support guarantee. The project’s DEVICES.md currently lists local entries for POWR3, S40TPB and POWR320D, with their own UIIDs and tested firmware. It also lists a similarly named CK-BL602-SWP1-01 variant as lacking the local protocol. Similar-looking hardware can therefore need a different conclusion.
POWR316D and POWR320D are POW Elite variants, rather than simply alternative names for POWR3. For an S31 or another power plug, verify the exact identity and local support instead of assuming every unit inherits a listed model’s path. S31 Lite lacks the S31’s energy-monitoring function, so a missing power entity on the Lite is a separate model-capability question.
The README explicitly applies a local temperature/humidity warning to THR316D and THR320D. It also describes other TH functions, such as thermostat control, with their own connection requirements. Read the device-specific section before expecting all of them to become local.
Real-time power and historical energy need separate checks. The README documents local energy-period sensors for supported models and cloud-loaded historical totals for others. The released code also has model-specific energy handling, including a POWR3 local request. Use the actual entity and model route, not a blanket rule that every energy value is cloud or local. A Home Assistant power-to-energy helper can integrate a valid local power reading, but it cannot fill missing measurements or guarantee meter-grade totals.
Official DIY Mode is another model-specific interface, covered in our DIY Mode guide; support in SonoffLAN is not proof of official DIY support. Tuya/Smart Life is a separate platform, so this particular eWeLink restriction is not evidence for diagnosing a Tuya plug. Our eWeLink data review covers the broader account-services question.
Frequently asked questions
Why did S31/POW readings stop while switching works? The documented cloud restriction is one explanation. Check the actual connection, supported model, firmware and fresh incoming measurements before assigning that cause.
Is this a SonoffLAN bug or an eWeLink change? The project documents a cloud-side restriction and a local workaround. Other frozen readings can still be a device, integration, network or display problem.
Must I reflash the device? The documented workaround updates SonoffLAN and uses supported stock-firmware LAN access. That route does not require reflashing, but unsupported firmware/models cannot be fixed merely by changing the integration version.
Was relay control unaffected? That is the symptom reported in this case, not a guarantee that every relay or other cloud function is always unaffected.
Which version introduced the local fix? v3.11.0, released 19 March 2026. Check current compatible releases and their model-specific notes; v3.13.1 also changes configured-host local checks.
Can a separate VLAN work? It can with the needed discovery or configured-host route and allowed local request/return traffic. Test the exact device; a reflector is one discovery tool, not a complete guarantee.
What we verified, and what stays local
The documented restriction, v3.11.0 change, v3.13.1 configured-host behavior, connection sensor and model/energy distinctions were checked against project releases, README and released source. The quoted manufacturer response remains a participant’s reproduced email, not independently authenticated correspondence. No power plug or VLAN configuration was tested for this article.
A successful local measurement path avoids the restricted real-time cloud call. Account setup, auto-mode cloud activity, historical energy and other device functions remain separate. Verify a new reading and its route before relying on it for an energy dashboard or automation.