If you run Sonoff gear in Home Assistant, there are now two mainstream ways to bring it in: the community SonoffLAN integration, and the new official eWeLink Smart Home add-on. The add-on was announced in January 2026 to replace the legacy official add-on. Most local-first readers want to know which one keeps working if the cloud goes away, and which one lets them keep an account out of the loop.
The short answer from the published material: SonoffLAN can run LAN-only once its device keys are fetched, and devices in DIY mode need no account at all. Its maintainer still recommends a mode that uses the cloud and the LAN together. The official add-on keeps your eWeLink account in the loop, is bound to that account’s device list, and has no published setting that turns its cloud fallback off. Neither option is cloud-free on day one. They differ in what happens afterwards.
This is research, not a bench test. No Sonoff hardware was used. Everything below is as of 2026-10-08, from the vendor’s forum posts and setup guide, the Home Assistant Community announcement, and SonoffLAN’s README, releases and issue tracker.
Search summaries often say the official add-on only supports switches and sockets. That describes the legacy V1.3.x add-on from 2022-2023. The new add-on’s May 2026 update says it syncs 70+ device types. Older threads may be describing either one, so check which before you trust them.
What the new official add-on is
The add-on comes from CoolKit, the company behind eWeLink, not from SONOFF itself (we cover how the two companies relate separately). It replaces the legacy eWeLink add-on, which gets no further updates. According to the vendor’s announcement, it syncs eWeLink Wi-Fi and Zigbee devices into Home Assistant over MQTT, including switches, plugs, lights, power monitoring and sensors. Control, automation and configuration then live in Home Assistant. A guided migration keeps existing devices, entities and automations. By default, the legacy and new add-ons can’t run side by side.
The 1.1.0 update, posted 2026-05-13, gives the 70+ device-type figure and adds better state reporting for RF Bridge devices. That count is as of 1.1.0. Later releases may change it, and that forum thread is where updates appear.
On networking, the vendor says LAN is prioritised and the cloud is the fallback for devices that support both paths, or that aren’t reachable on the LAN. So “official” doesn’t mean “cloud-only”. It doesn’t mean “cloud-free” either. Neither the announcement, the 1.1.0 update nor the setup guide describes a setting that disables the fallback.
What SonoffLAN is
SonoffLAN is a custom integration by AlexxIT, installed through HACS or manually, for devices running original eWeLink firmware. Its README describes three modes. Auto uses the LAN and the cloud together. Local uses the LAN only and needs no internet, but it relies on stored device keys. Cloud is cloud.
The README recommends auto and advises against local-only, for two separate reasons. First, the local protocol isn’t always stable, and devices can drop off or stop answering local requests. Second, some POW and TH models couldn’t update their sensors without the cloud. That second reason is the pre-fix state of the power-sensor issue covered below. Our DIY mode guide carries the same warning. Running local-only for privacy is a legitimate choice, but it goes against the maintainer’s default.
An eWeLink account is needed for cloud mode, and for the first fetch of device keys and the device list. Standard eWeLink LAN mode is encrypted with per-device keys that only the account can supply. After that one fetch, local mode runs on the cached keys. Devices in DIY mode use an unencrypted local protocol, and for those the integration needs no credentials at all. Local discovery runs over mDNS. If your Sonoff devices sit on a separate IoT VLAN from Home Assistant, you’ll need an mDNS reflector, as our power-sensor article explains.
Side by side
| Criterion | Official eWeLink Smart Home add-on | SonoffLAN |
|---|---|---|
| Account | eWeLink login needed to pull the device list (vendor post) | Needed for cloud mode and the first key fetch. Not needed for DIY-mode devices (README) |
| Credentials held | eWeLink login plus a long-lived Home Assistant access token (setup guide) | eWeLink login in auto or cloud mode, cached device keys in local mode. Runs inside Home Assistant, so no separate HA token |
| LAN and cloud | LAN prioritised, cloud as fallback. No published setting to turn the fallback off | Auto (recommended), local or cloud. Your choice, with the maintainer advising against local-only |
| Install | Home Assistant add-on store (HA OS or Supervised). The repository README documents a manual Docker route | HACS custom repository or manual copy |
| Power sensors | Not documented either way | Over LAN since v3.11.0. Cloud path blocked by eWeLink |
| Coverage and upkeep | 70+ device types as of 1.1.0, vendor-maintained, replaces the legacy add-on | Community-maintained, original eWeLink firmware or DIY mode |
For a local-first reader, the LAN and cloud row matters most. SonoffLAN treats the cloud as a setting. You can pin it to local, at the cost of the stability caveat above, or run auto and know that the cloud is in use. The add-on treats it as a priority order. You get LAN where it works and cloud where it doesn’t, and the published material offers no switch between the two.
The account, the token and the device list
Both options need an eWeLink account at setup. The difference is how long that dependency lasts.
The add-on needs the login to pull your device list. The vendor notes that switching to a different eWeLink account makes previously synced devices unavailable. Our reading of that note is that the account is an ongoing part of the integration, not a one-time setup step. That’s different from SonoffLAN in local mode, where the account is only needed for the first key fetch. The vendor post also says devices created inside Home Assistant no longer sync back to the eWeLink cloud under the new add-on.
The add-on talks to Home Assistant through its REST and WebSocket APIs, using a long-lived access token. eWeLink’s setup guide has you create the token in your Home Assistant profile, add the CoolKit-Technologies/ha-addon repository in the add-on store, and paste the token into the add-on’s Configuration tab before its first start. The guide assumes Home Assistant OS or a Supervised install. Other installs need the home_assistant_url setting changed, or the Docker route from the repository README.
A long-lived Home Assistant token carries the permissions of the user who creates it, and on most single-user installs that user is an administrator. The add-on setup asks you to hand one to a vendor-supplied add-on that also holds your eWeLink login. Nothing in the sources suggests the vendor misuses either. It is still a larger trust surface than an integration that runs inside Home Assistant and needs no token. Give the token a name you’ll recognise, and revoke it if you remove the add-on.
The tradeoff is about where you place trust: with the company whose cloud you’re trying to rely on less, or with a public repository run largely by one developer. Neither is automatically safer.
The power-sensor block
This is where cloud dependence has already caused real breakage. SonoffLAN’s README warns that from 2026, power, current and voltage sensors on almost all eWeLink power devices no longer update in real time through the cloud. The same applies to temperature and humidity on the THR316D and THR320D. Issue #1755 on the SonoffLAN tracker, now closed, summarises a manufacturer response. That response says calls from the integration to eWeLink’s power-data endpoints put load on the cloud, and eWeLink blocked frequent third-party requests as a result.
The fix shipped on the SonoffLAN side in v3.11.0, released 2026-03-19. Those sensors now update over the local protocol. The cloud path stays blocked, so for these readings the LAN is now the only path, not just the preferred one. Our power-sensor article covers the symptoms, the version check and the VLAN precondition.
For the official add-on, none of the published material says whether its power readings go over LAN or cloud. A user thread on eWeLink’s forum from March 2026 reports that the block also hit eWeLink’s own Docker-based plugin. That thread has no staff reply, so treat it as a report, not a finding. If you rely on power monitoring through the add-on, check that the readings actually update before you trust them.
Who should pick which
Choose SonoffLAN if:
- You want the option to run LAN-only after the one-time key fetch, and you accept the maintainer’s stability caveat for local mode.
- Your devices are in DIY mode and you want no account in the loop.
- You use power-monitoring devices. On v3.11.0 or later, their readings arrive over LAN.
Choose the official add-on if:
- You want the vendor’s own integration, with its 70+ device-type coverage.
- You’re migrating off the legacy add-on and want your entities and automations carried over.
- You run Home Assistant OS or a Supervised install, and you’re fine keeping an eWeLink account and a Home Assistant token in place.
Our read is that SonoffLAN is the better fit for a privacy-first reader, because cloud involvement is a setting you control rather than a priority order you accept. The counterweights are real: it depends largely on one maintainer, who also warns that local-only is less stable. If you value vendor support and a guided migration more than that control, the add-on is a reasonable choice.
The no-account options are DIY mode and OpenEdge, covered in our DIY mode guide and OpenEdge explainer. For the wider account picture, see what eWeLink collects and what stays free on eWeLink’s plans.
FAQ
Is the official eWeLink add-on for Home Assistant local or cloud? Both. The vendor says LAN is prioritised and the cloud is the fallback. The add-on needs your eWeLink account to pull the device list, and no published setting turns the fallback off.
Do I need an eWeLink account to use SonoffLAN? For cloud mode and the first fetch of device keys, yes. For devices in DIY mode, no. Even so, the maintainer recommends auto mode, which uses the cloud alongside the LAN.
Should I switch from SonoffLAN to the official add-on? Only if you want vendor maintenance and don’t mind the account and token. Of the two, SonoffLAN is the only one with a mode you can pin to local.
Does the eWeLink add-on work without internet? The vendor’s material doesn’t say. LAN priority suggests locally reachable devices may keep responding, but nothing published confirms it. If offline operation matters, block internet access and test before relying on it.
Why did my Sonoff power readings stop updating in Home Assistant? Most likely because of the 2026 cloud-side block described above. On SonoffLAN, update to v3.11.0 or later and make sure the device is reachable on your LAN.
What the research verified
Verified from vendor and project sources: the add-on’s MQTT sync, LAN-first fallback, account requirement and token setup; SonoffLAN’s three modes, its auto recommendation and DIY mode’s no-credential path; and the power block with its v3.11.0 fix. Not established: any LAN-only setting in the add-on, its offline behaviour, or whether its power readings are affected by the block.
What stays local: SonoffLAN in local mode after the key fetch, and DIY mode throughout. What still depends on a vendor: the add-on’s account binding and cloud fallback, and any cloud-delivered readings.
Sub-devices behind a Sonoff Zigbee bridge are a separate case. An eWeLink forum reply says the original Zigbee Bridge has no LAN mode (limited hardware), so both options reach its sub-devices through the cloud. Zigbee Bridge Pro sub-devices under SonoffLAN weren’t established. For Zigbee with no eWeLink in the path, use your own coordinator under Zigbee2MQTT or ZHA; we cover reflashing the original bridge for Zigbee2MQTT.
After setup, check which path each entity is actually using, and revoke any token you no longer need. Whether the add-on will ever get a LAN-only switch is unclear. Its update thread on the eWeLink forum is the place to watch.