If your Sonoff power-monitoring plug or switch — an S31, a POWR3-family switch, an S40 — still turns on and off from Home Assistant but the power, current, and voltage readings have stopped moving, you are looking at a cloud-side change rather than a broken setup. Sonoff power monitoring is not updating for a large number of SonoffLAN users because eWeLink’s cloud stopped delivering those particular sensor values to third-party integrations during 2026. It isn’t a bug in the integration and it isn’t something you configured wrong. The fix exists, it shipped in March, and it runs entirely over your local network — provided the device is genuinely reachable there, which is the part that catches out anyone running an IoT VLAN.
The symptom: numbers frozen, switching fine
The pattern reported by SonoffLAN users is specific. Relay control keeps working normally — the device turns on and off from Home Assistant exactly as before. What stops is the sensor values: power, current, and voltage sit at whatever number they last showed, sometimes for days, with no error logged anywhere in Home Assistant to flag it. That silence is what makes it easy to miss. Nothing crashes, nothing shows red, the dashboard just quietly stops being accurate — and any energy dashboard statistics or utility-meter helpers built on those entities stop being accurate with it.
Relay control is unaffected. If switching stopped working too, that is a different problem. And it isn’t only power devices: SonoffLAN’s documentation records the same limitation for the temperature and humidity sensors on the THR316D and THR320D, and ties it explicitly back to the power-device warning. If you own a TH model with a frozen temperature graph, the rest of this applies to you as well.
What actually happened: eWeLink’s 2026 cloud block
During 2026, eWeLink’s cloud stopped propagating power, current, and voltage sensor updates to third-party integrations connecting over the cloud path — SonoffLAN in particular. The warning now sitting at the top of the project’s README puts the scope broadly: sensors for almost all eWeLink power devices no longer update in real time.
The stated mechanism is load, and it has two halves worth separating. These sensor updates had never been carried by the local protocol, so every reading a third-party integration wanted had to come from the cloud. SonoffLAN’s polling for real-time power data then placed enough demand on eWeLink’s infrastructure that eWeLink blocked those specific calls at the server side. The manufacturer said as much in its response in the project’s issue tracker.
On timing: the README dates the change only to 2026 and does not name a month. The user reports and the fix both land in March, so that is the practical window, but eWeLink has not published a precise date and we are not going to invent one.
This is a cloud-side decision, not a defect in SonoffLAN and not a misconfiguration on your end. Devices kept working for on/off control the entire time.
The cloud path for power, current, and voltage sensors remains blocked on eWeLink’s server side. A cloud-only SonoffLAN setup will keep showing stale values for these sensors indefinitely, regardless of which integration version you run. The only working path is local.
The fix: SonoffLAN v3.11.0 and local-protocol updates
SonoffLAN’s maintainer shipped the fix in v3.11.0, released 2026-03-19: support for updating the power, current, and voltage sensors over the local (LAN) protocol instead of the cloud, on the back of a rewrite of the integration’s local device-update logic. The cloud path for those sensors stays blocked — nothing changed there, and nothing in a third-party integration release was ever going to change it. What changed is that the local protocol now carries data it previously couldn’t, which is why local reachability went from a performance preference to a hard requirement.
Why “local” fixed what “cloud” broke
This is the shape of problem this site covers repeatedly: a vendor cloud dependency degrades, and the setups least affected are the ones that weren’t leaning on it. We made the same observation about Mijia app outages. What makes this case sharper is that going local wasn’t a hardening choice — after the block, it is the only path that carries the data at all.
Checking your own setup
Three things determine whether you’re getting live power data today:
- SonoffLAN version — you need v3.11.0 or later. Anything older has no local-protocol sensor path and will keep showing frozen values.
- Integration mode — SonoffLAN’s README recommends
mode: auto(local and cloud together) overmode: localonly, and it gives two different reasons that are worth keeping apart. One is general: the local protocol isn’t always stable and devices can drop off. The other is this exact issue — the README’s note that some POW and TH models can’t update their sensors without a cloud connection describes the pre-fix state of the same subsystem v3.11.0 addressed, and we quoted that caveat in our Sonoff DIY Mode guide. Auto is still the right setting, but not because the cloud will deliver these three sensors; it won’t. Auto keeps the cloud available for everything else while the local path carries the sensors. - Local reachability — Home Assistant has to be able to discover the device on the network, and this is the requirement most likely to fail silently.
SonoffLAN finds devices over mDNS/zeroconf, and mDNS does not cross subnet or VLAN boundaries — a router will not forward it without an mDNS reflector or proxy (Avahi on an OPNsense or pfSense box, the gateway mDNS proxy in UniFi, or the equivalent on your gear). If Home Assistant sits on your main network and the Sonoff device sits on an IoT VLAN, the local path this fix depends on will not come up by itself. SonoffLAN issue #1427 is a standing request for a manual add-by-IP route precisely because of this, and reports there say direct IP configuration is ignored. Enable a reflector for the IoT VLAN, or expect these sensors to stay frozen.
Each device SonoffLAN manages also exposes a diagnostic “connection” sensor, disabled by default, reporting whether that device is currently reachable locally or via the cloud. Enable it before troubleshooting anything else — it answers the local-versus-cloud question directly instead of leaving you to infer it from whether the power numbers look current.
| Setting | What it should be | Why |
|---|---|---|
| SonoffLAN version | ≥ 3.11.0 | First version with local-protocol power/current/voltage updates |
| Integration mode | auto |
Project-recommended; local-only carries a separate stability caveat |
| Cloud-only setup, any version | Not sufficient | Cloud path for these sensors stays blocked by eWeLink regardless of version |
| HA and device on separate VLANs | Needs an mDNS reflector | Local discovery is mDNS; it does not cross subnets unaided |
| Connection sensor | Enable it (disabled by default) | Confirms per-device local vs. cloud reachability directly |
Which devices this affects
Power-monitoring Sonoff models in general circulation include the S31 (not the S31 Lite, which has no energy monitoring), the POWR3 family (POWR3, POWR316D, POWR320D), and the S40. Treat that as illustrative rather than complete — the README’s own framing is “almost all eWeLink power devices,” and the authoritative per-device list of what supports the local protocol is the project’s own DEVICES.md, not any third-party summary, including this one.
The THR316D and THR320D belong on the list too. They aren’t power-monitoring devices, but the README records the same local-only limitation for their temperature and humidity sensors and points back to the same warning, so a TH owner watching a flat temperature graph is looking at the same root cause.
Worth separating clearly: these are not the same device set as ITEAD’s official DIY Mode hardware (BASICR3, RFR3, MINI, D1, MINIR3, SPM-Main), covered separately in our DIY Mode guide. Different families, different local-access mechanisms — don’t carry guidance across.
None of this touches Tuya-platform devices either. eWeLink and Tuya’s Smart Life are different companies’ platforms despite the similar-looking hardware, and a Tuya-based plug is unaffected by this block. If the cloud dependency itself is what you’re reconsidering, we’ve looked separately at what the eWeLink app collects.
Frequently asked questions
Why did my Sonoff S31/POW power monitoring stop updating in Home Assistant? Because eWeLink’s cloud began blocking power, current, and voltage sensor updates for third-party integrations such as SonoffLAN during 2026, citing polling load on its infrastructure.
Is this a SonoffLAN bug or an eWeLink change? An eWeLink cloud-side change. SonoffLAN’s maintainer responded with a fix — local-protocol sensor updates — but the underlying block is on eWeLink’s server, not in the integration’s code.
Do I need to reflash my Sonoff device to fix power monitoring? No. The fix is updating SonoffLAN to v3.11.0 or later and making sure the device is discoverable on your local network. No reflash or device firmware change is involved.
Does this affect switching the device on/off, or just the sensor readings? Just the sensor readings — power, current, and voltage on power devices, and temperature and humidity on the THR316D and THR320D. Relay and switch control were unaffected throughout.
What SonoffLAN version fixes power sensor updates? v3.11.0, released 2026-03-19, and any later version.
Will this work if my Sonoff device is on a separate IoT VLAN? Not on its own. SonoffLAN discovers devices over mDNS, which does not cross VLANs without a reflector or proxy configured on your router or firewall. Enable one for the IoT VLAN, or the local sensor path won’t come up.
What we verified, and what stays local
This article is research-synthesis from the SonoffLAN project’s own README, the issue thread carrying eWeLink’s response, and the v3.11.0 release notes. No claim here depends on hardware this site owns, and nothing is presented as hands-on tested — there is no Sonoff power-monitoring plug on our bench.
Verified against those sources: the scope of the block (power, current, and voltage sensors, with relay control unaffected), the README’s broader “almost all eWeLink power devices” framing, the same limitation documented for THR316D and THR320D temperature and humidity, the stated cause (a cloud-side block on polling load, per the manufacturer’s in-thread response), the fix and its release (v3.11.0, 2026-03-19, local-protocol updates), the README’s auto-over-local recommendation and both of the reasons behind it, and the per-device connection diagnostic sensor.
Sourced but weaker, and flagged as such: the mDNS behaviour across VLANs is a well-established property of mDNS itself, but SonoffLAN issue #1427 is a user report and a standing feature request, not a maintainer statement — we cite it as evidence that the gap is real and unclosed in the integration, not as documentation of intended behaviour. The exact start date of the block is not published. Issue #1755 was closed as a duplicate at time of research, which reflects how the tracker was organised rather than the block being resolved; the fix is documented in the release notes, not in that thread’s closure.
What stays local once you’re on v3.11.0 or later in auto mode with the device discoverable on your network: power, current, and voltage readings, updating independently of eWeLink’s cloud. What doesn’t: the cloud path for those same sensors, which stays blocked no matter which version you run.