I want to use my Sonoff MiniR4 (Extreme) with my own local system via DIY Mode, but I want to avoid soldering cables or opening the device to access the pads. Does anyone know the current procedure to enable it?
Based on my research, here is the non-invasive method:
Standard Pairing: First, pair the device with the eWeLink App using Bluetooth or Quick Pairing.
Enable LAN Mode: Once paired, go to Device Settings and enable “LAN Control”.
Use the DIY Tool: With LAN Control active, the device can be managed via the eWeLink DIY Tool v1.2 (or higher) on your PC, as long as they are on the same network.
mDNS Discovery: The device should broadcast its service via mDNS (_ewelink._tcp.local).
Is there any way to flash a custom firmware (like Tasmota) purely via OTA without opening the case, or is the “LAN Control” mode the only “DIY” path available for this specific model now?
Short answer: no — the MiniR4 doesn’t have DIY Mode at all.
DIY Mode was something Sonoff put into a few older ESP8266 devices (BasicR3, MiniR2, D1). In theory it let you enable a special mode, get a local HTTP API, and even upload your own firmware like Tasmota over OTA.
In practice… well, many of us spent hours staring at that “local HTTP server” screen while absolutely nothing useful happened. It was more of a DIY‑ish mode than an actual DIY mode.
The MiniR4 is a different beast entirely. It uses an ESP32‑C3 with Secure Boot and Flash Encryption, which means it will only accept firmware signed by Sonoff. So:
DIY Mode: not available
OTA flashing Tasmota/ESPHome: impossible
LAN Control: yes, but only for controlling the stock firmware
Custom firmware: only via UART after opening the case
Thanks for the explanation , that clears things up.
My main issue isn’t really about flashing or DIY mode itself, but about latency.
I’m seeing noticeable delays when controlling the MiniR4, sometimes up to 1–2 seconds before the light actually turns on.
Just to rule out the obvious:
My internal network is solid (full-coverage mesh with Deco X55).
Other local devices respond instantly.
What makes me suspect the firmware / cloud path is that I still have an older Sonoff Mini flashed with ESPHome, and that one reacts immediately (both ON and OFF), consistently, every time.
With the MiniR4, even using LAN control, the behavior feels different — almost like some commands are still going out to the cloud and coming back, or at least passing through a heavier internal stack.
So from a user point of view, the comparison is basically:
ESPHome Mini (older) → instant response
MiniR4 stock firmware → sometimes fine, sometimes ~2s delay
That’s what I’m trying to understand and measure right now.
From my own testing: if you control the MiniR4 through the eWeLink app, the delays you’re seeing are completely expected. Even with LAN Control enabled, the app still prefers the cloud path as long as the device has internet access. That’s why you get those random 1–2 second spikes. When I blocked the MiniR4 from the internet, the eWeLink app suddenly became fully local and consistently faster.
With Home Assistant, it’s different — the LAN integration talks to the device directly, without touching the cloud at all. In that setup my MiniR4 reacted instantly and felt just as responsive as my ESPHome devices.
But it’s also worth saying this clearly: no Wi‑Fi or Zigbee smart relay will ever behave like a mechanical switch. There will always be some latency — usually tiny, sometimes noticeable — because the command has to go through theair, the firmware stack, and only then the relay toggles. ESPHome hides this well because it’s extremely lean, but even there you’re not getting true zero‑latency.
So in practice:
eWeLink app + internet → cloud-first → occasional lag
eWeLink app + internet blocked → LAN-only → much faster
Home Assistant LAN → always local → instant
ESPHome → the snappiest, but still not literally instantaneous
If someone expects “mechanical switch speed,” that’s simply not how any smart device works.
Thanks a lot for taking the time to explain all that — really appreciate the detailed reply
In my case I’m currently using Sonoff LAN in Home Assistant, but I’ve had to leave it in AUTO mode. When I force LOCAL only, I start running into reliability issues (devices going unavailable, missed commands), so AUTO has been the most stable option so far, even if it sometimes introduces those delays.
That said, your explanation about the cloud-first behavior in eWeLink and the difference with HA makes total sense, and it matches pretty well with what I’m seeing in practice.
As a next step, I’m planning to open one MiniR4 and flash it via UART (USB-TTL, 4 wires) to test it with ESPHome, just to see if the responsiveness becomes more consistent. I don’t really want to replace everything right now — I have around 20 units installed, and switching them all to Zigbee at this point would be a significant cost.
So for now this is mostly about understanding the behavior and seeing whether there’s a viable path forward without a full hardware swap.
Thanks again for sharing your experience — it was very helpful.
One more thing to keep in mind: Zigbee devices from the eWeLink ecosystem will never work in LAN‑only mode.
LAN Control applies only to Wi‑Fi devices that explicitly support it. Zigbee devices always go through the Sonoff Zigbee hub, and that hub communicates with the cloud unless the integration forces a local path (like HA does). So if you have a mix of devices — some Wi‑Fi with LAN, some Wi‑Fi without LAN, and some Zigbee — the Sonoff LAN integration in AUTO will constantly switch between local and cloud depending on the device.
That’s why forcing LOCAL breaks reliability: HA tries to talk locally to devices that simply cannot respond locally. Older Sonoff Wi‑Fi switches never had LAN Control, some models got it in updates, some never did. Zigbee devices don’t support it at all.
So the short version:
MiniR4 → supports LAN Control
Older Wi‑Fi Sonoff → maybe yes, maybe no
Zigbee Sonoff → never LAN
AUTO mode → mixed paths → occasional delays
LOCAL mode → works only if every device supports LAN
If you expect consistent instant responses, you need to make sure the integration isn’t silently falling back to the cloud because of one device that simply can’t do LAN.
Since you already have Home Assistant, I’m curious: why not move fully to HA and leave eWeLink behind altogether? You can do it gradually, but if you want to keep every device without opening cases or soldering, some models simply can’t be made fully local.
Thanks a lot for the clarification, really appreciated.
Just to clarify on my side: my Zigbee devices are paired directly to a Sonoff Dongle-M Max, running Zigbee2MQTT, so they’re fully local and completely outside of eWeLink. That setup has been working perfectly and very reliably for me.
I’ll run some more tests over the next few days (especially comparing LAN vs AUTO behavior on the Wi-Fi devices) and see how things evolve.
Thanks again for taking the time to explain all this.
Just a quick clarification, because the terminology matters here. When you say “my Zigbee devices are paired directly to a Sonoff Dongle‑M Max, running Zigbee2MQTT”, that’s not technically how Zigbee works. The Dongle‑M is only a radio coordinator.
It doesn’t run Zigbee2MQTT, it doesn’t have a pairing mode, and it can’t “pair” devices by itself. All the actual logic — including pairing (“permit join”), device management, binding, routing, etc. — happens on the host system that runs Zigbee2MQTT (Home Assistant, Docker, Raspberry Pi, Linux, etc.). The dongle just provides the Zigbee radio interface.
So the accurate description would be something like: “My Zigbee devices are paired through Zigbee2MQTT, with the Dongle‑M Max acting as the coordinator.”
That’s fully local and completely outside of eWeLink — agreed — but it’s not the dongle doing the pairing, it’s the host running Z2M.
ou’re absolutely right — thanks for the clarification, and apologies for the imprecise terminology on my part.
What I meant to say is exactly what you described: my Zigbee devices are paired via Zigbee2MQTT running on the host, with the Dongle-M Max acting purely as the Zigbee radio coordinator. All pairing logic, device management, and routing are handled by Z2M on the host, not by the dongle itself.
The important point I was trying to convey is that this setup is fully local and completely outside of eWeLink, but you’re right that it’s more accurate to describe it that way.
It’s not really about terminology, but about calling things and phenomena by their proper names — mostly because it makes them far easier to understand. That’s the whole point of words, after all: they’re supposed to clarify reality, not just sit there looking decorative in a sentence. Once we stop tiptoeing around what something actually is, the rest tends to fall neatly into place, right?
, that clears things up.