Sonoff’s Basic R3, Mini, RF R3, and D1 are Wi-Fi devices built around the eWeLink app and eWeLink’s cloud. But ITEAD, the company behind Sonoff, also documents an official DIY Mode: a local HTTP REST API that supported devices can expose on the LAN instead of talking to eWeLink’s servers. It’s not a firmware replacement. It’s a mode that ships in the stock firmware.
That distinction matters because it puts DIY Mode in a different category from the Tasmota and ESPHome reflash routes that most local-control writing about Sonoff assumes. Nothing gets erased or replaced. The device just starts answering local requests instead of, or alongside, the cloud.
This piece works from ITEAD’s own DIY Mode protocol documentation, a Home Assistant Community thread on the feature, and the SonoffLAN project that’s grown up around it, not from hands-on testing. Blocking Tuya devices from the internet covers the parallel question on the Tuya side, if that’s the platform you’re comparing against.
DIY Mode is not a blanket Sonoff feature. It’s documented for a specific device list, above a specific firmware version. Check your exact model and firmware against both before assuming your Sonoff plug or switch can do this.
What DIY Mode actually is
Per ITEAD’s own protocol documentation, DIY Mode switches a supported device from eWeLink cloud control to a local, unencrypted HTTP REST API. Once enabled, commands and status queries go directly to the device on the LAN. Nothing about the device’s firmware changes, and no third-party tool is required. This is an official, vendor-supported local-control path, which is a different trust posture than a community reflash even though the end result, control without the cloud, looks similar from the outside.
Which Sonoff devices support it, and which don’t
ITEAD’s DIY Mode documentation names a specific set of devices that expose the local REST API. It is not every Sonoff Wi-Fi product, and it is broader than the four devices most write-ups list.
| Model | Type | DIY Mode status |
|---|---|---|
| BASICR3 | Wi-Fi relay module | Named in DIY Mode 2.0 spec |
| RFR3 | Wi-Fi relay module (RF variant) | Named in DIY Mode 2.0 spec |
| MINI / MINIR2 | Compact Wi-Fi relay module | Named in DIY Mode 2.0 spec |
| MINIR3 | Compact Wi-Fi relay module | Listed in the DIY Mode API docs |
| D1 | Wi-Fi dimmer | Named in DIY Mode 2.0 spec |
| SPM-Main | Stackable power meter | Listed in the DIY Mode API docs; ITEAD has also published a separate HTTP API for the SPM line |
The SPM entry is worth noting because the DIY Mode question and the “Sonoff published an HTTP API for SPM” announcement are frequently treated as two unrelated stories. They aren’t: SPM-Main sits in the same documented device set.
Sonoff’s naming is close enough to be dangerous here. MINI, MINIR2 and MINIR3 all appear in the DIY Mode documentation, but a later revision in the same product line does not automatically inherit support. Match the exact model number printed on the device, not the product family name, and check the current official list rather than a sibling product’s behaviour.
How discovery and the local API work
A device in DIY Mode advertises itself on the LAN via mDNS/DNS-SD, under the _ewelink._tcp service type, per ITEAD’s documentation. Clients discover the device’s IP address, port, and API version through standard DNS PTR, SRV, and TXT records. There’s no cloud lookup involved in finding the device once it’s on your network.
You can see this advertisement with any generic mDNS browsing tool. On Linux, that looks like:
avahi-browse -r _ewelink._tcp
A device in DIY Mode should show up with its resolved IP, port, and TXT record data. If nothing appears, either the device isn’t in DIY Mode yet, or it’s on a different VLAN or subnet than the machine running the browse command, which is worth checking before assuming the feature isn’t working.
Because the local API doesn’t require an eWeLink account once DIY Mode is active, a supported device can be controlled entirely without ever logging into eWeLink’s cloud. That’s the headline benefit. It comes with a real tradeoff covered further down, so don’t treat “no cloud login” as the whole story.
Enabling DIY Mode and initial local provisioning
There are two documented routes in, and which applies depends on your model’s generation. On the earlier devices, the protocol documentation describes a hardware jumper: DIY Mode is entered by pulling GPIO 16 to a low level. On the current generation, including BASICR3, RFR3, MINI/MINIR2 and MINIR3, ITEAD’s documentation describes a five-second button press that puts the device into compatible pairing (AP) mode instead of using a jumper.
There is also a firmware floor. The original DIY Mode protocol documentation applies to Basic R3, RFR3 and MINI from firmware 3.3.0 upward, while DIY Mode 2.0 is documented against firmware 3.5.0. Below the relevant threshold, the device won’t expose the API regardless of how you try to enter the mode.
Once the device is in DIY Mode, initial Wi-Fi provisioning uses a local, device-hosted setup page rather than the eWeLink app’s normal pairing flow. Instead of pairing through the app and its cloud account creation, you connect to a setup interface the device itself serves and configure Wi-Fi credentials there.
BASICR3, RFR3, MINI/MINIR2 and D1 are mains-wired modules. The jumper route means opening the enclosure of a device that may be connected to mains, so isolate it at the breaker and disconnect it before touching the board. For the exact sequence, follow ITEAD’s own setup documentation for your specific model rather than a generic Wi-Fi pairing guide.
Connecting DIY Mode devices to Home Assistant
The usual route into Home Assistant is SonoffLAN, a community-maintained custom integration (AlexxIT/SonoffLAN on GitHub, with forks such as hmmbob/SonoffLAN). It handles both of Sonoff’s local paths, and the difference between them matters more than most write-ups admit.
DIY Mode is the unencrypted one. SonoffLAN’s documentation is explicit that DIY Mode devices can be used without eWeLink credentials precisely because their protocol is unencrypted. Standard eWeLink LAN mode is a different thing: it’s encrypted, and the integration needs per-device encryption keys that only the eWeLink account can supply. If your goal is control with no eWeLink account at all, DIY Mode is the path that actually gets you there.
It installs like any HACS custom repository:
Repository: AlexxIT/SonoffLAN Category: Integration
SonoffLAN’s documentation recommends running the integration in auto mode and specifically advises against local mode or DIY mode. The stated reasons: the local protocol isn’t always stable, devices can drop off or stop answering local requests, and some POW and TH models can’t update their sensor values without a cloud connection. Auto mode uses local and cloud together. Choosing DIY Mode for privacy reasons means taking that tradeoff knowingly, not avoiding it.
AlexxIT’s repository is the one the HACS instructions point at and the one most guides assume. The hmmbob fork also circulates; if one has stalled on your specific model, checking the other’s issue tracker is a reasonable move before concluding the approach is broken. Choosing between LocalTuya and tuya-local covers the same integration-choice problem on the Tuya side, and tinytuya covers local control without Home Assistant at all.
The security tradeoff of an unencrypted local API
This is the part that’s easy to skip past. DIY Mode’s local API is HTTP, not HTTPS. There’s no built-in encryption and, once enabled, no account credential gate on the LAN side either. That’s exactly what makes local control possible without eWeLink, and it’s exactly why the device shouldn’t sit on a flat network with everything else.
Anyone with LAN access to a DIY Mode device can, in principle, talk to its local API the same way Home Assistant or SonoffLAN does. That’s a reasonable tradeoff on a segmented IoT VLAN where only trusted hosts can reach the device in the first place. It’s a worse one on a flat home network where a compromised phone or a guest device shares the same broadcast domain. What Tuya’s app actually sends covers the opposite failure mode, cloud data collection, if that’s the tradeoff you’re weighing instead.
I think ITEAD publishing an unencrypted local API at all, officially, is a genuinely useful thing for this niche, and more vendors should offer an equivalent path instead of leaving local control to reverse-engineering. That doesn’t make the lack of transport encryption a non-issue. Treat DIY Mode devices the way you’d treat any other unauthenticated local service, on a network segment where reachability itself is the access control.
FAQ
Does Sonoff DIY Mode require flashing custom firmware?
No. DIY Mode is an official ITEAD feature built into the stock firmware on supported devices. It’s a local API you enable, not a firmware you install.
Which Sonoff devices support DIY Mode?
ITEAD’s DIY Mode documentation covers BASICR3, RFR3, MINI/MINIR2, MINIR3, D1, and SPM-Main. That’s the documented set rather than the whole Sonoff Wi-Fi catalog, and newer revisions in the same product line aren’t automatically included, so check your exact model number against the current official list before buying for this feature.
Is Sonoff DIY Mode’s local API secure, since it’s unencrypted?
It’s plain HTTP with no built-in encryption and no account gate once enabled. Treat it like any other unauthenticated local service and keep it on a segmented network where only trusted hosts can reach it, rather than a flat home LAN.
Can I use SonoffLAN and the eWeLink cloud at the same time?
Yes. SonoffLAN’s auto mode uses local and cloud connections together, and the project’s own documentation recommends auto over local-only or DIY mode, because the local protocol isn’t always stable and some POW and TH models can’t update their sensors without cloud. DIY Mode devices themselves need no eWeLink credentials, so a fully local setup is possible. It just isn’t what the integration’s maintainer suggests as the default.
How do I enable DIY Mode on a supported Sonoff device?
Two routes are documented: a jumper pulling GPIO 16 low on the earlier devices, and a five-second button press into compatible pairing (AP) mode on current ones. You also need firmware at or above the documented threshold, 3.3.0 for the original protocol and 3.5.0 for DIY Mode 2.0. Provisioning then happens on a device-hosted setup page rather than in the eWeLink app. Check ITEAD’s setup guide for your exact model before starting.
What this piece verified
This is a research-synthesis piece built from ITEAD’s official DIY Mode protocol documentation and device API pages, the SonoffLAN project’s own repository documentation, and a Home Assistant Community thread on the feature. It is not built from hands-on setup. No Sonoff hardware currently sits on this site’s test bench.
The documented device list, the firmware thresholds, the mDNS _ewelink._tcp discovery mechanism, the two entry routes, and the unencrypted nature of the API all trace to vendor or project documentation rather than inference. The distinction between DIY Mode and eWeLink LAN mode, and SonoffLAN’s recommendation against running local-only, both come from that project’s own documentation rather than from our own testing.
One thing this piece deliberately doesn’t do is give per-model physical steps for entering DIY Mode. The routes are documented at protocol level, the exact sequence varies by model and revision, and these are mains-wired devices. ITEAD’s per-device setup pages are the right source for that.
If a Sonoff MINI or BASICR3 lands on the test bench, the next version of this piece can replace the documented entry routes with a verified walkthrough.