Bad experience with the Sonoff Dongle-M (Dongle Max)

OhmegaStar · February 1, 2026, 8:44am

@humingchun , i’m seeing the same kind of unstable connection from z2m;

Z2M HA AddOn on HA OS (Vm under Proxmox - Xeon Type Multi CPU) ipv4 + ipv6 enabled.

Installation methodHome Assistant OS
Core2026.1.3
Supervisor2026.01.1
Operating System17.0
Frontend20260107.2
Z2M: Fresh Install 2.7.2-1

Dongle M;
EFR32MG24 Zigbee Coordinator Mode Stable V1.0.0 ( SDK Version 7.4.5 )
ESP32-D0WDR2-V3 Stable V1.0.5,
AP Disabled, Static IP,
Connected via POE from a unifi switch

Seeing this type of errors in Z2M
[2026-02-01 09:13:02] error: zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.
[2026-02-01 09:13:02] error: zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
[2026-02-01 09:13:02] error: zh:ember:ezsp: Fatal error, status=ASH_NCP_FATAL_ERROR. Last Frame: [FRAME: ID=52:“SEND_UNICAST” Seq=34 Len=7]

These type notifications in Dongle M Notifications;
[2026-02-01 09:13:12]
HA/Zigbee2MQTT connected
[2026-02-01 09:13:06]
HA/Zigbee2MQTT disconnected. Please check your network and HA/Zigbee2MQTT configuration.
[2026-02-01 09:12:28]
HA/Zigbee2MQTT connected
[2026-02-01 09:12:23]
HA/Zigbee2MQTT disconnected. Please check your network and HA/Zigbee2MQTT configuration.
[2026-02-01 09:11:54]
HA/Zigbee2MQTT connected
[2026-02-01 09:11:53]
HA/Zigbee2MQTT disconnected. Please check your network and HA/Zigbee2MQTT configuration.
[2026-02-01 09:11:19]
HA/Zigbee2MQTT connected
[2026-02-01 09:11:16]
HA/Zigbee2MQTT disconnected. Please check your network and HA/Zigbee2MQTT configuration.
[2026-02-01 09:10:55]
HA/Zigbee2MQTT connected

…
Z2M logs;
[2026-02-01 09:29:53] error: zh:ember:ezsp: ERROR Transaction failure; status=ERROR_WRONG_DIRECTION. Last Frame: [FRAME: ID=52:“SEND_UNICAST” Seq=60 Len=25].
[2026-02-01 09:29:53] error: zh:ember:ezsp: ERROR Transaction failure; status=ERROR_WRONG_DIRECTION. Last Frame: [FRAME: ID=52:“SEND_UNICAST” Seq=60 Len=25].
[2026-02-01 09:29:53] error: z2m: EventBus error ‘OTAUpdate/deviceMessage’: CommandResponse 0xa4c138ccebdf1373/11 genOta.queryNextImageResponse({“status”:152}, {“timeout”:10000,“disableResponse”:false,“disableRecovery”:false,“disableDefaultResponse”:true,“direction”:1,“reservedBits”:0,“writeUndiv”:false}) failed (~x~> [ZCL to=0xa4c138ccebdf1373:45433 apsFrame={“profileId”:260,“clusterId”:25,“sourceEndpoint”:1,“destinationEndpoint”:11,“options”:4352,“groupId”:0,“sequence”:0}] Failed to send request with status=FAIL.)
[2026-02-01 09:30:32] error: zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.
[2026-02-01 09:30:32] error: zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
[2026-02-01 09:30:32] error: zh:ember:ezsp: Fatal error, status=ASH_NCP_FATAL_ERROR. Last Frame: [FRAME: ID=52:“SEND_UNICAST” Seq=69 Len=7]
[2026-02-01 09:30:32] info: zh:ember:uart:ash: ASH COUNTERS since last clear:
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Total frames: RX=2408, TX=2986
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Cancelled : RX=0, TX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: DATA frames : RX=2305, TX=583
[2026-02-01 09:30:32] info: zh:ember:uart:ash: DATA bytes : RX=48664, TX=14935
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Retry frames: RX=91, TX=12
[2026-02-01 09:30:32] info: zh:ember:uart:ash: ACK frames : RX=10, TX=2390
[2026-02-01 09:30:32] info: zh:ember:uart:ash: NAK frames : RX=0, TX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: nRdy frames : RX=0, TX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: CRC errors : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Comm errors : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Length < minimum: RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Length > maximum: RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Bad controls : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Bad lengths : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Bad ACK numbers : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Out of buffers : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Retry dupes : RX=91
[2026-02-01 09:30:32] info: zh:ember:uart:ash: Out of sequence : RX=0
[2026-02-01 09:30:32] info: zh:ember:uart:ash: ACK timeouts : RX=12
[2026-02-01 09:30:32] info: zh:ember:uart:ash: ======== ASH stopped ========
[2026-02-01 09:30:32] info: zh:ember:ezsp: ======== EZSP stopped ========
[2026-02-01 09:30:32] info: zh:ember: ======== Ember Adapter Stopped ========
[2026-02-01 09:30:32] error: z2m: Adapter disconnected, stopping

Dongle M Notifications;
[2026-02-01 09:30:37]
HA/Zigbee2MQTT connected
[2026-02-01 09:30:34]
HA/Zigbee2MQTT disconnected. Please check your network and HA/Zigbee2MQTT configuration.
[2026-02-01 09:13:12]
HA/Zigbee2MQTT connected

Currently 31 Routers added (rebuilding network)
Mixed Ikea, Gledopto, Sonoff and Tuya devices

I hope that we can get something more stable soon.

/Henrik

OhmegaStar · February 1, 2026, 2:40pm

After adding all the routers (42) and the various end devices (18), the connection seems to have been stable for 6 hours so far…

pinionking · February 2, 2026, 12:12am

I am having the exact same issues. Devices just dropping offline. Particularly noticeable during the night as when I actually need things working, they don’t.

Brand new install of HA. Just setting up for the first time.
Running POE through a switch.
Fully up to date with firmware.
I only have 15 devices running on it, as I slowly set things up. A few Hue lights and some Motion Sensors, so it is not being overloaded.
It is in the middle of the house so range isn’t an issue. Doesn’t matter where the device is, still has issues.
I ran the channel scan and the Dongle suggested I be on channel 25. After puting it on 25, it says there are no frequency clashes or issues.
It is running a static IP and HA is connected using the IP instead of the DNS name.
Has an internet connection.

franco101 · February 3, 2026, 12:44pm

Similar issues experienced here…

Dongle is connected to a HP 2530-8G POE switch, the dongle which is running the latest firmware appears unresponsive to ping. Every 5 ping it responds but the rest of the pings are dropped. The WebUI during this time is unresponsive. Tried forcing speed-duplex full-100 and auto-100 but same issue. Restarting the dongle appears to break everything in HA.

@humingchun would appreciate your input in this one?

humingchun · February 3, 2026, 2:44pm

also @Zyxel @dominikprucha Thank you very much for your detailed report. We are doing 2 things right now:

Buying UniFi PoE switch to test PoE compatiblity.
Internal testing of v1.0.6 beta firmware, we’ll release it this week.

We are definitely going to solve these issues.

humingchun · February 3, 2026, 2:48pm

Could you successfully ping Dongle-M, and what’s the Round Trip Time (RTT)? Is the RTT less than 20ms?

humingchun · February 3, 2026, 2:54pm

Sorry for the issue. Would you please provide the following information:

The brand and model of your PoE switch;
Are you using ZHA (Home Assistant Zigbee Home Automation) or Z2M (Zigbee2MQTT)?
Could you successfully ping Dongle-M, and what’s the Round Trip Time (RTT) ? Is the RTT less than 20ms?

@franco101

Sorry for the issue. Would you please provide the following information:

Which one are you using? Static IP, Smart IP, or DHCP.
What’s the Round Trip Time (RTT) of your first 5 ping ? Is the RTT less than 20ms?

Would you mind connecting Dongle-M through USB (not ethernet) just for a short test to see whether the issue is related to ethernet only?

GiuseppeP96 · February 3, 2026, 3:13pm

Hi there,

I’m experiencing an issue with my Sonoff Dongle Max. If I start it with the Ethernet cable connected, it keeps rebooting. The Ethernet interface is configured with a static IP and i can’t access the web ui while the eth cable is connected as it keeps rebooting and also taking down the internal AP.

However, if I start it using Wi‑Fi with DHCP enabled and then plug in the Ethernet cable after the first internet connection, it works fine — but I still need to change the static IP of the Ethernet port at least once even if it was configured previously.

I’m unable to access the debug logs because they are cleared after every reboot and i can’t donwload them just before it reboots as the AP also goes down.

My guess is that, on my wired network, the device is unable to reach something (a system update server or similar), and when it fails, it reboots itself. But i can’t see any network activity in my network it could be also an eth negotiation issue?. I don’t think it’s a static IP related issue.

Do you have any idea what might be causing this issue? I do have some Cisco firewalls on the network, but they shouldn’t be causing the device to reboot even if some remote URL are blocked.
I tried both poe and non poe port.
I also tested on another network with huawei poe switch with DHCP config and it doesn’t auto restart so i think strictly related with my cisco network but i can’t debug what’s wrong and the fact that there is a “path” to make it work with wifi connection at first boot make it even stranger.

@humingchun please ask me if you need any other info.

Thanks,

Giuseppe

humingchun · February 3, 2026, 3:52pm

Sorry for the issue, and thank you very much for the detailed description.

I do have several questions:

How can you tell Dongle-M keeps rebooting? From the LED indicator, or the Disconnect status bar at the top of Dongle-M’s Web UI?
I tried both poe and non poe port. You mean the behavior is the same when Dongle-M is connected to Cisco router/switch?
What is the model name of your Cisco router/switch?

Note: We have identified a bug related to Static IP, and it will be fixed in v1.0.6 beta. But the behavior is different.

GiuseppeP96 · February 3, 2026, 4:02pm

led indicator stops blinking for a second and then starts blinking again (color is blue as i have configure the static ip). Plus the internal ap stops as well and my device disconnects from sonoff dongle ap. Then the wifi comes back until the next reboot which happens at a short distance
Yes i tried to the poe port of my cisco switch but also to the second eth port of a MOXA MB3170 (which is connected to the same cisco switch with its first eth port) and the result is the same. In this case the moxa is not providing poe and i powered the dongle via usb
it should be a Cisco C9300

EDIT: i have also tried another dongle as i bought four of them for my setup but i can’t get them working for this issue

ric-m · February 3, 2026, 5:15pm

I had this problem and was never able to resolve it. Support was very tardy and by the time it arrived (resetting the device - which I’d already tried with no success) I’d sent the device back for a refund.

Maybe a bad batch out there? Dunno. But I like the idea of the device and will probably try again in 6 months when the hardware/firmware has settled. By contrast, the Dongle-E has been working flawlessly 24/7.

iamontresor · February 4, 2026, 7:47am

@humingchun I’m sharing some findings, as I was able to reproduce the behaviour of the Sonoff Dongle Max when used as a coordinator over Ethernet. I haven’t tested WiFi mode since I prefer not to rely on that. However, this appears to be similar to @GiuseppeP96’s issue, just triggered under different conditions.

I’m not a network expert, just documenting reproducible behaviour I observed in case it helps others or the developers.

Setup

Device: Sonoff Dongle Max
Role: Zigbee coordinator (via HA OS using Zigbee2MQTT add-on)
Connection: Wired Ethernet
Power: Dedicated USB power
Network: Separate IoT VLAN
IP configuration: Tested with Static IP, DHCP, and Smart IP modes on the dongle
Router: Asus RT-BE88U (Merlin firmware)

Symptom

After rebooting the dongle, either:

via Web UI, or
by physically power-cycling it

The device does not stabilise properly on the network, even though it remains visible on the network.

Observed behaviour:

Ethernet link flaps as per my (Asus BE88U) router log:

> Feb  4 13:28:22 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:28:22 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:28:22 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:28:24 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:28:24 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:24 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:24 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:28:31 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:28:31 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:28:34 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:28:34 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:28:34 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:28:34 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:28:34 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:34 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:34 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:28:41 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:28:41 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:28:43 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:28:43 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:28:43 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:28:43 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:28:43 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:43 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:43 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:28:50 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:28:50 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:28:53 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:28:53 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:28:53 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:28:53 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:28:53 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:53 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:28:53 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:29:01 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:29:01 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:29:03 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:29:03 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:29:03 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:29:05 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:29:05 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:05 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:05 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:29:12 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:29:12 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:29:15 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:29:15 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:29:15 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:29:15 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:29:15 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:15 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:15 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:29:22 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:29:22 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:29:25 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:29:25 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:29:25 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:29:27 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:29:27 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:27 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:27 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900
> Feb  4 13:29:34 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link DOWN.
> Feb  4 13:29:34 kernel: br52: port 3(eth8) entered disabled state
> Feb  4 13:29:37 kernel: eth8 (Int switch port: 3) (Logical Port: 3) (phyId: 4) Link Up at 100 mbps full duplex AN: On
> Feb  4 13:29:37 kernel: br52: port 3(eth8) entered blocking state
> Feb  4 13:29:37 kernel: br52: port 3(eth8) entered forwarding state
> Feb  4 13:29:37 dnsmasq-dhcp[8344]: DHCPDISCOVER(br52) c0:cd:d6:54:39:03 
> Feb  4 13:29:37 dnsmasq-dhcp[8344]: DHCPOFFER(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:37 dnsmasq-dhcp[8344]: DHCPREQUEST(br52) 10.10.20.106 c0:cd:d6:54:39:03 
> Feb  4 13:29:37 dnsmasq-dhcp[8344]: DHCPACK(br52) 10.10.20.106 c0:cd:d6:54:39:03 Dongle-M_3900

So, the dongle appears to be stuck in a network reinitialisation loop.

Key observation

Resetting the dongle itself does not resolve the issue, which is unusual. A full reboot would normally reinitialise the network stack from a clean state. However, the dongle immediately becomes stable only after router-side DHCP/IP state is refreshed. For example, modifying the DHCP reservation for the device (which restarts DHCP/network services) or rebooting the router. After that, the dongle works normally and remains stable.

This behaviour occurs regardless of the dongle being set to:

Static IP
DHCP
Smart IP

This suggests the dongle fails to complete its network initialisation properly after reboot and appears to be waiting for a network condition that never resolves. When router’s DHCP/ARP state is refreshed, that state clears, and the dongle finishes startup.

I’m not sure whether this is a hardware or firmware issue, but it appears to be related to how the dongle handles network state recovery after reboot. Hopefully, this can be addressed in a future firmware update.

GiuseppeP96 · February 4, 2026, 9:23am

On your side are you experiencing reboots of the device? As i’m also having issues with eth connection but the device also restarts itself and i see from the switch interface the port going up and down.

iamontresor · February 4, 2026, 10:16am

Mine did not start rebooting on its own. I only discovered this behaviour when I manually rebooted the dongle to see if the signal would improve. After that reboot and several additional resets, it would not stabilise on the network, and I couldn’t properly access the device’s web interface. The login/password page would load, but it showed “disconnected” at the top and would not proceed after login attempts, until I rebooted my main router. The dongle is otherwise stable once running.

GuyFromMars365 · February 6, 2026, 2:49am

Dongle-M is in same location, antenna pointing up the same, over .8 meter from floor. It’s connected via LAN, powered via USB, running Z2M. Running 1.0.5 with AP disabled. Migration was simply switching device in Z2M config file.

GiuseppeP96 · February 6, 2026, 1:02pm

@humingchun still haven’t found a way to solve the issue. I managed to make it work by starting it powered via USB and Wi‑Fi with DHCP enabled for the first network connection.
Then i plugged in the Ethernet cable with PoE and changed the static IP configuration. Finally i have unplugged the usb cable.

humingchun · February 6, 2026, 5:24pm

@GuyFromMars365 @Zyxel @dominikprucha @OhmegaStar @pinionking @franco101 @GiuseppeP96 @ric-m @iamontresor

Thank you all for your valuable feedback and for your tolerance for SONOFF Dongle-M. Please believe us that we are working hard to debug the issues and fix the bugs.

We have just released v1.0.6 beta version. If you are still interested, please try it through Web UI -> Firmware -> ESP32-D0WDR2-V3 -> Check for Updates -> Beta -> Flash Firmware V1.0.6.

Note: You will need to refresh the Web UI after flashing v1.0.6.

@Zyxel @dominikprucha @franco101 @GiuseppeP96 We are still investigating the ethernet issue. We’ve just got UniFi USW-Ultra PoE switch, and will test it tomorrow.

@iamontresor Thank you very much for your detailed report, we’ll study it carefully.

dominikprucha · February 6, 2026, 5:47pm

nice work

fransward · February 6, 2026, 8:23pm

@humingchun, good work!
I recently purchased the Dongle-M and had the same problems. Couldn’t get a stable connection with the UI due to a constantly resetting network connection.
With the 1.0.6 beta update all seems stable now.
It is connected via POE to a Netgear GC510P Switch.

Ping results with 1.0.5:

PING 192.168.2.46 (192.168.2.46): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 192.168.2.46: icmp_seq=1 ttl=64 time=1.930 ms
Request timeout for icmp_seq 2
Request timeout for icmp_seq 3
Request timeout for icmp_seq 4
Request timeout for icmp_seq 5
Request timeout for icmp_seq 6
Request timeout for icmp_seq 7
Request timeout for icmp_seq 8
Request timeout for icmp_seq 9
Request timeout for icmp_seq 10
Request timeout for icmp_seq 11
Request timeout for icmp_seq 12
64 bytes from 192.168.2.46: icmp_seq=13 ttl=64 time=1.992 ms
Request timeout for icmp_seq 14
Request timeout for icmp_seq 15
Request timeout for icmp_seq 16
Request timeout for icmp_seq 17
Request timeout for icmp_seq 18
Request timeout for icmp_seq 19
Request timeout for icmp_seq 20
Request timeout for icmp_seq 21
Request timeout for icmp_seq 22
Request timeout for icmp_seq 23
64 bytes from 192.168.2.46: icmp_seq=24 ttl=64 time=2.497 ms
Request timeout for icmp_seq 25
Request timeout for icmp_seq 26
Request timeout for icmp_seq 27
^C
--- 192.168.2.46 ping statistics ---
2288 packets transmitted, 23 packets received, 99.0% packet loss
round-trip min/avg/max/stddev = 1.565/2.103/3.565/0.433 ms

Ping results with the 1.0.6 beta firmware:

PING 192.168.2.46 (192.168.2.46): 56 data bytes
64 bytes from 192.168.2.46: icmp_seq=0 ttl=64 time=9.078 ms
64 bytes from 192.168.2.46: icmp_seq=1 ttl=64 time=3.024 ms
64 bytes from 192.168.2.46: icmp_seq=2 ttl=64 time=3.006 ms
64 bytes from 192.168.2.46: icmp_seq=3 ttl=64 time=8.925 ms
64 bytes from 192.168.2.46: icmp_seq=4 ttl=64 time=2.943 ms
64 bytes from 192.168.2.46: icmp_seq=5 ttl=64 time=9.337 ms
64 bytes from 192.168.2.46: icmp_seq=6 ttl=64 time=2.459 ms
64 bytes from 192.168.2.46: icmp_seq=7 ttl=64 time=2.524 ms
^C
--- 192.168.2.46 ping statistics ---
8 packets transmitted, 8 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.459/5.162/9.337/3.069 ms

Cyc · February 7, 2026, 1:44pm

I bought 3 dongle-m and I will resend them all. The software is way not finished ! Since when companies sells products with 50% finised software ???

Impossible to flash a new firwmware. New firwmware is detected but flash fails (at downloadint I think). I had to sflash with USB.

Ap mode is unusable : it create a new network so devices that are connected to this new network cannot speak with my main network. What on Earth is this ? Is it so difficult to add an “wireless switch mode” ? It is is only to get access to the net is is not usefull for home assisted people that frequently prefer local access (that becomes impossible).
And of course ap name cannot be changed.

Really the software is only 50% finished. What a shame.