private@homelab: ~/latest
local-first guides · privacy-aware · no noisy tracking
private@homelab:~$ cat guides/article.md
· ·
7–10 minutes
read

eWeLink Privacy: What Data Does the App Actually Collect?

A plain-English breakdown of what eWeLink's own privacy policy discloses about device data, permissions, third-party SDKs, and where the data goes.

If you own Sonoff hardware, the eWeLink app is doing more than switching relays. It’s the account layer, the firmware updater, and by its own admission, a fairly wide data collector. So what data does the eWeLink app collect? The answer is in eWeLink’s own privacy policy, which is considerably more forthcoming than the app-store summary, but written for legal compliance rather than for someone standing in front of a purchase decision.

I’ve already pulled apart what Tuya/Smart Life and Xiaomi Home disclose about their own apps. eWeLink hasn’t had that treatment, so this piece does it from the policy at ewelink.cc, and only that one. The separate reseller storefront at ewelinkstore.com publishes its own unrelated policy for its own business, and that document does not govern the app on your phone.

Everything below is a synthesis of what eWeLink/Coolkit itself discloses, organized around the questions a Sonoff buyer actually asks before installing. No device was paired and no traffic was captured for this piece.

Note · context

This article covers eWeLink/Coolkit’s app privacy policy at ewelink.cc only. If you landed on a different eWeLink-branded storefront’s policy, that’s a separate document from a separate company.

Why Sonoff buyers keep asking what eWeLink collects

Sonoff devices are cheap, plentiful, and mostly require the eWeLink app for setup even if you plan to run them locally afterward. That creates a specific worry: the switch itself is dumb hardware, but the account you’re forced to create to configure it isn’t.

Search results for this question are thin. The app’s own policy is comprehensive but dense. The Play Store Data safety page is a bare checklist with no context. Neither explains what the disclosed categories actually mean or where the data physically goes.

What eWeLink’s privacy policy discloses about device and account data

eWeLink’s policy lists several categories of data tied to your device and account. Read together, they cover the device itself, the phone the app runs on, and your account activity.

Category What’s included Disclosed purpose
Device details Device name, device ID, online status, firmware version Device management and support
Account and technical data Profile data, MAC address, IP address, OS version, app version, list of other apps installed on your phone Account services, compatibility, diagnostics
Activity and diagnostics Activity logs, crash reports Stability and debugging
Location (feature-gated) Real-time geolocation, only when using features like sunrise/sunset automation triggers Automation triggers tied to your location

The installed-app list is the line I keep coming back to. It means the app, or an SDK bundled inside it, can see what other software is on your phone, not just what eWeLink itself is doing. The policy doesn’t argue that a light-switch app needs that visibility. It discloses that it collects it and moves on.

The location data point is narrower than it sounds. It’s not constant background tracking; it’s tied specifically to features that need a location, like calculating sunrise and sunset for automation triggers. If you never use that kind of automation, this category shouldn’t apply to you, though the policy doesn’t spell out whether the permission request itself is scoped that tightly.

The permissions layer: camera, microphone, location

Beyond the data categories above, the policy’s permissions section covers camera and microphone access. These are used for QR-code device pairing, video recording, voice commands, and two-way calling on eWeLink’s camera-capable products.

Note · compatibility

Worth knowing: camera and microphone permissions only apply to eWeLink’s camera-capable devices. A basic Sonoff switch or plug has no camera or mic for these permissions to invoke in the first place.

QR-code pairing is the one permission most Sonoff buyers actually hit, since scanning a device’s QR code during setup uses the camera. The video, voice, and two-way calling permissions only matter if you own an eWeLink-connected camera or intercom-style device.

The third-party SDK detail the app-store summary skips

This is the part that doesn’t show up in the Data safety disclosure or in generic China-IoT commentary. eWeLink’s own policy names two bundled third-party SDKs: Umeng and Bugly.

Umeng collects device identifiers: IMEI, MAC address, Android ID, OPENUDID and GUID, IDFA on iOS, and SIM card IMSI data. Bugly is operated by Shenzhen Tencent Computer System Co., and it is the route by which the installed-software list reaches Tencent’s servers. eWeLink’s stated reason is crash reporting. Because the app runs as multiple processes, the policy says it reserves the right to collect the installed-software list in the background so it can capture logs when the app crashes.

Both SDKs are widely used across the Chinese app ecosystem, and their presence here isn’t unique to eWeLink. What is worth noticing is that the rationale is written down at all. Most apps bundling the same SDKs don’t explain themselves this plainly.

Warning

Two bundled SDKs collect more than the app’s switching function requires. Umeng collects hardware and SIM identifiers, and Bugly sends your phone’s installed-software list to Tencent’s crash-reporting servers. Both are disclosed in the policy text rather than in the app-store Data safety summary, so it’s easy to install the app without ever encountering them.

Honestly, bundling analytics SDKs that collect device identifiers and an installed-software inventory is a heavier ask than most people expect from an app whose only job, from the user’s side, is turning a relay on and off.

Where eWeLink data goes: data centers, retention, and sharing

The policy states that eWeLink’s primary data centers are in Beijing and Singapore, with data potentially transferred to other overseas facilities the company operates. Transmission is described as SSL-encrypted.

Retention isn’t a fixed number of days or months. The policy ties it to how long the data is needed for the service, or to legal requirements, citing tax and accounting law as one example of the latter. Some data could therefore persist well past the point you stop actively using the app, depending on which basis applies.

On sharing, the policy names four categories of third parties: hosting and business-service providers, payment processors, affiliates and subsidiaries, and law enforcement acting under legal process. None of that is unusual for a cloud-connected consumer app. It’s the same rough sharing pattern I’ve documented for Tuya and Xiaomi.

Note · context

This analysis reflects the policy as published at the time of writing, August 2026. Secondary sources disagree about when the document was last revised, so if a specific clause matters to your decision, read it at the source rather than relying on a second-hand date. Privacy policies change without announcement.

What local/LAN mode does and doesn’t change

eWeLink devices support a local, LAN-only control mode, covered in more depth in Sonoff DIY Mode: local control without the eWeLink cloud. Running a device that way reduces your reliance on the cloud path this article covers, since day-to-day control no longer needs to leave your network.

It doesn’t eliminate the collection described above. Initial setup, firmware updates, remote access from outside your LAN, and any automation that depends on eWeLink’s servers still route through the same account and app described here. Local mode changes how much you depend on that path for ongoing control. It doesn’t opt you out of the account-level data collection tied to owning and registering the device in the first place.

The same tradeoff shows up across Chinese-origin smart home platforms. I’ve documented similar cloud-versus-local gaps for Tuya/Smart Life and Xiaomi Home, and on the mitigation side, what actually breaks when you block Tuya devices from the internet.

FAQ

What data does the eWeLink app collect?
Device details (name, ID, online status, firmware version), account and technical data (profile, MAC address, IP address, OS and app version, installed-app list), activity logs and crash reports, and, for certain automation features, real-time location.

Does eWeLink send data to Chinese servers?
Its policy names Beijing as one of its primary data center locations, alongside Singapore, with possible transfer to other overseas facilities it operates. Separately, the bundled Bugly SDK sends crash-related data, including the installed-software list, to servers operated by Tencent.

Is eWeLink safe to use for Sonoff devices?
The policy discloses a fairly wide set of categories, in line with what comparable Chinese-origin smart home apps disclose. Whether that’s acceptable depends on your own threshold, not on a hidden or undisclosed practice. The bundled third-party SDKs are the detail worth weighing that most comparisons skip.

Can I use Sonoff devices without the eWeLink cloud?
Some models support a local DIY/LAN mode that keeps day-to-day control off eWeLink’s servers. Setup, firmware updates, and remote access still depend on the app and account.

What third-party SDKs does eWeLink use?
The policy names Umeng, which collects device and SIM identifiers, and Bugly, operated by Shenzhen Tencent Computer System Co., which uploads the installed-software list to Tencent’s servers for crash analytics.

What this piece verified

This article is a synthesis of eWeLink/Coolkit’s own published privacy policy at ewelink.cc. Every data category, permission, SDK name, data center location, and sharing category above comes from that document, with the SDK operator and identifier details cross-checked against the SDK vendors’ own published disclosures. No eWeLink account was created and no Sonoff device was paired to write this piece.

What stays local is whatever you route through DIY/LAN mode for day-to-day control, per the linked mode-specific guide. What still depends on eWeLink’s own infrastructure is initial setup, firmware delivery, and anything routed through their account and cloud, which is what the data categories above actually apply to.

What a policy read can’t tell you is how closely the app’s real network behaviour matches the document. A privacy policy describes what a company reserves the right to do, which is a ceiling, not a measurement. Closing that gap takes a packet capture on a live install, and that’s the obvious next piece for anyone who wants to hold eWeLink to its own disclosure.

local-firstHome Assistantno-cloud