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

Hello,
I am experiencing recurring fatal disconnections with my SONOFF Dongle Max (Dongle-M) used as a Zigbee coordinator over TCP (Ethernet), and after extensive troubleshooting I believe the root cause is in the ESP32 bridge firmware.
Setup:

Device: SONOFF Dongle Max, Device ID 25231900013758, ESP32 firmware V1.0.10 (latest)
Connection: Ethernet, PoE+ powered from UniFi switch, fixed LAN, TCP mode (port 6638)
Host: Zigbee2MQTT 2.12.1 (ember driver), Home Assistant, ~41 Zigbee devices, channel 11
MG24 firmware tested: EmberZNet 8.2.2.0 and 9.0.2 (both show identical behavior)

Symptom:
Every ~2–3 hours Zigbee2MQTT crashes with:
zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.
zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
z2m: Adapter disconnected, stopping
On some days this escalates to a "restart storm" (10+ crashes per hour). The device's own web UI notifications show matching repeated "HA/Zigbee2MQTT disconnected/connected" events (16+ pages).
Evidence pointing to the ESP32 bridge:
With the device debug log enabled, right before each failure I can see an ASH retransmission loop between the ESP32 and the MG24: the MG24 repeatedly retransmits the same data frames, the host repeatedly ACKs them, and finally the MG24 emits an ASH ERROR frame (c2 02 51 a8 bd 7e), after which the TCP socket is reset (tcp_server: TCP recv error, errno=104). The ESP32 itself never reboots (uptime 8+ days across many crashes).
Ruled out during troubleshooting:

Power supply: PoE+ from UniFi switch (also tested power cycling)
Network path: Ethernet (WLAN disabled), UniFi logs clean, 0% packet loss
Zigbee interference/devices: crashes occur even with availability/pinging disabled and no traffic peaks
MG24 firmware: identical crashes on EmberZNet 8.2.2.0 and 9.0.2

Additional bug: the device fails DNS resolution via the LAN DNS server (getaddrinfo error 202 for timeapi.coolkit.cc), so NTP never syncs and all notifications are timestamped 1970-01-01, which complicates diagnostics. Ping to 8.8.8.8 works.
This matches reports from other users in Zigbee2MQTT GitHub issues #30441 and #30891.
Could you please confirm whether this is a known issue in the ESP32 bridge firmware and whether a fix is planned? I am happy to provide full debug logs from both the device web console and Zigbee2MQTT.
Thank you,
Dominik

Před odesláním doporučuji přiložit výřez hex dumpu z web konzole dongle a kousek Z2M logu (oba máš z dnešní noci). Pokud založí ticket, drž se čísla ticketu — a stejný text (bez pozdravů) můžeš přidat i jako komentář do issue #30441 na GitHubu, tam pomůže ostatním.mužes ho rovnou přidat do textu výřez hex dumpu z web konzole dongle a kousek Z2M logu (oba máš z dnešní noci). ?Thought processThought processZde je kompletní verze s přiloženými logy:

Subject: Dongle Max (Dongle-M) — recurring ASH_NCP_FATAL_ERROR / TCP bridge failure every 2–3 hours (ESP32 firmware V1.0.10)
Hello,
I am experiencing recurring fatal disconnections with my SONOFF Dongle Max (Dongle-M) used as a Zigbee coordinator over TCP (Ethernet), and after extensive troubleshooting I believe the root cause is in the ESP32 bridge firmware.
Setup:

Device: SONOFF Dongle Max, Device ID 25231900013758, ESP32 firmware V1.0.10 (latest)
Connection: Ethernet, PoE+ powered from UniFi switch, fixed LAN, TCP mode (port 6638)
Host: Zigbee2MQTT 2.12.1 (ember driver), Home Assistant, ~41 Zigbee devices, channel 11
MG24 firmware tested: EmberZNet 8.2.2.0 and 9.0.2 (both show identical behavior)

Symptom:
Every ~2–3 hours Zigbee2MQTT crashes. Example from 2026-07-03 (repeated identically at 00:04, 00:30, 00:35, 00:39, 00:46, 03:50, 04:11, 04:22, 07:02):
[2026-07-03 04:11:04] error: zh:ember:uart:ash: Received ERROR from adapter, with code=ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT.
[2026-07-03 04:11:06] error: zh:ember:uart:ash: ASH disconnected | Adapter status: ASH_NCP_FATAL_ERROR
[2026-07-03 04:11:07] error: zh:ember:ezsp: Fatal error, status=ASH_NCP_FATAL_ERROR. Last Frame: [FRAME: ID=52:"SEND_UNICAST" Seq=41 Len=10]
[2026-07-03 04:11:11] error: z2m: Adapter disconnected, stopping
Occasionally also this variant during/after recovery:
[2026-07-03 04:25:55] error: zh:ember:ezsp: ERROR Transaction failure; status=ERROR_WRONG_DIRECTION. Last Frame: [FRAME: ID=52:"SEND_UNICAST" Seq=36 Len=27].
On some days this escalates to a "restart storm" (10+ crashes per hour). The device's own web UI notifications show matching repeated "HA/Zigbee2MQTT disconnected/connected" events (16+ pages).
Evidence pointing to the ESP32 bridge (device web console debug log, captured 2026-07-03):
Right before the failure, the host keeps sending ACK frames while the MG24 side repeatedly answers with the same ASH ERROR frame (c2 ...), then the TCP socket is reset:
W (452540) TCP: (4)=> 82 50 3a 7e
W (452543) MG24_TCP: (6)=> c2 02 51 a8 bd 7e
W (452552) TCP: (4)=> 83 40 1b 7e
W (452553) TCP: (8)=> 84 30 fc 7e 84 30 fc 7e
W (452557) MG24_TCP: (12)=> c2 02 51 a8 bd 7e c2 02 51 a8 bd 7e
W (452560) TCP: (4)=> 84 30 fc 7e
W (452599) TCP: (4)=> 84 30 fc 7e
W (452600) TCP: (8)=> 85 20 dd 7e 86 10 be 7e
W (452606) TCP: (16)=> 86 10 be 7e 86 10 be 7e 86 10 be 7e 86 10 be 7e
W (452607) MG24_TCP: (30)=> c2 02 51 a8 bd 7e c2 02 51 a8 bd 7e c2 02 51 a8 bd 7e c2 02 51 a8 bd 7e c2 02 51 a8 bd 7e
E (453919) tcp_server: TCP recv error, errno=104
I (453922) webserver_api: ... {"z2mOrZhaConnected":false,"tcpSocket":{"connected":false}}
Earlier in the same capture, data frames from the MG24 are visibly retransmitted multiple times (identical payloads repeated, e.g. frames 1c 61 b1 a9 6b 2a ..., 2c 61 b1 a9 0d 2a ..., 3c 61 b1 a9 7d 31 2a ... re-sent at 392108, 394149 and 397318 ms), while the host repeats ACKs — a classic ASH retransmission loop that ends with the ERROR frame above. The ESP32 itself never reboots (uptime 8+ days across many crashes).
Ruled out during troubleshooting:

Power supply: PoE+ from UniFi switch (also tested power cycling)
Network path: Ethernet (WLAN disabled), UniFi logs clean, 0% packet loss
Zigbee interference/devices: crashes occur even with availability/pinging disabled and no traffic peaks
MG24 firmware: identical crashes on EmberZNet 8.2.2.0 and 9.0.2

Additional bug: the device fails DNS resolution via the LAN DNS server (esp-tls: couldn't get hostname for :timeapi.coolkit.cc: getaddrinfo() returns 202), so NTP never syncs and all notifications are timestamped 1970-01-01 (see sys_time: local time :1970-01-01 in the log), which complicates diagnostics. Ping to 8.8.8.8 works.
This matches reports from other users in Zigbee2MQTT GitHub issues #30441 and #30891.
Could you please confirm whether this is a known issue in the ESP32 bridge firmware and whether a fix is planned? I can provide complete debug logs from both the device web console and Zigbee2MQTT on request.
Thank you,
Dominik

Could you please provide the complete Z2M logs, as well as the full debug logs of Dongle-Max from the moment it connects to Z2M until it crashes?

This will help us better identify the issue.

This is very similar to the issue with my ZigStar UZG01 POE dongle. An ESP firmware update resolved it for me with my Cisco 2960 switch.

Hi everyone,

After following this thread for a while, I wanted to share my own experience.

Unfortunately, the Sonoff Dongle-M has not met my expectations so far. I’m not saying it is a bad coordinator, but compared to my previous Dongle-E, the experience has been noticeably worse in my environment.

Hardware

Previous coordinator

  • Sonoff Dongle-E - EFR32MG21

New coordinator

  • Sonoff Dongle-M:
    EFR32MG24 Firmware: Stable V1.0.0 (SDK 7.4.5)
    ESP32-D0WDR2-V3 Firmware: Stable V1.0.10

Both coordinators were used with Zigbee2MQTT (Ember adapter).

Network

  • ~20 Zigbee devices
  • Routers and battery-powered devices
  • Same house
  • Same coordinator location
  • Same USB extension cable
  • Same Zigbee channel
  • Same router locations
  • Same end devices

The coordinator is the only hardware change.

What I observed

Compared to the Dongle-E, I experienced:

  • Noticeably lower LQI values across many devices.
  • Devices choosing unexpected parents.
  • Some battery-powered devices taking much longer to pair.
  • Temporary Interview failed states that sometimes recovered by themselves.
  • Devices occasionally appearing in Home Assistant later than expected.
  • Initial network formation taking significantly longer.
  • Some battery devices becoming unavailable or requiring re-pairing during testing.

I understand that LQI alone is not an indicator of network quality, and I’ve read many comments saying it should not be compared directly between coordinators.

However, even ignoring the LQI values, I still experienced practical issues such as delayed pairing, interview problems, and devices occasionally dropping from the network. Those are the issues that concern me the most.

Troubleshooting performed

To rule out migration-related issues, I eventually rebuilt the entire Zigbee network.

Steps:

  • deleted database.db
  • deleted coordinator_backup.json
  • generated a new PAN ID
  • generated a new Extended PAN ID
  • generated a new Network Key
  • stopped using the previous coordinator IEEE and switched to the Dongle-M hardware EUI64

The clean rebuild is behaving a little bit better than the migrated network, but I’m still rebuilding the mesh and monitoring stability.

Data I’ll provide

To keep this discussion objective, I’ll also post:

  • complete Zigbee device list
  • old vs. new LQI values for every device
  • house floor plan showing coordinator, routers and end devices
  • topology graph

Hopefully this information will help determine whether what I’m seeing is expected behaviour, a firmware issue, or something specific to my setup.

Topology Graph (Graphviz):

digraph G {
node[shape=record];
  "0x7c31fafffed16125" [style="bold, filled", fillcolor="#e04e5d", fontcolor="#ffffff", label="{Coordinator|0x7c31fafffed16125 (0x0000)|0 seconds ago}"];
  "0x7c31fafffed16125" -> "0x70b3d52b601339ad" [penwidth=0.5, weight=0, color="#994444", label="160"]
  "0x7c31fafffed16125" -> "0xa4c1380263b9fab7" [penwidth=0.5, weight=0, color="#994444", label="255"]
  "0x7c31fafffed16125" -> "0xa4c138f5a2095d76" [penwidth=0.5, weight=0, color="#994444", label="144"]
  "0x7c31fafffed16125" -> "0xa4c13890f122b40b" [penwidth=0.5, weight=0, color="#994444", label="218"]
  "0x70b3d52b601339ad" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{Zigbee Router - Mutfak|0x70b3d52b601339ad (0x3e2a)|Tuya Zigbee signal repeater (TS0001_repeater)|4 minutes, 51 seconds ago}"];
  "0x70b3d52b601339ad" -> "0x7c31fafffed16125" [penwidth=0.5, weight=0, color="#994444", label="159"]
  "0x70b3d52b601339ad" -> "0xa4c1380263b9fab7" [penwidth=0.5, weight=0, color="#994444", label="160"]
  "0x70b3d52b601339ad" -> "0xa4c138f5a2095d76" [penwidth=0.5, weight=0, color="#994444", label="65"]
  "0x70b3d52b601339ad" -> "0xa4c13890f122b40b" [penwidth=0.5, weight=0, color="#994444", label="137"]
  "0xa4c1380263b9fab7" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{Priz - Yatak Odasi|0xa4c1380263b9fab7 (0xf485)|Elivco Smart plug (with power monitoring) (LSPA9)|26 seconds ago}"];
  "0xa4c1380263b9fab7" -> "0x7c31fafffed16125" [penwidth=0.5, weight=0, color="#994444", label="210"]
  "0xa4c1380263b9fab7" -> "0x70b3d52b601339ad" [penwidth=0.5, weight=0, color="#994444", label="111"]
  "0xa4c1380263b9fab7" -> "0xa4c138f5a2095d76" [penwidth=0.5, weight=0, color="#994444", label="114"]
  "0xa4c1380263b9fab7" -> "0xa4c13890f122b40b" [penwidth=0.5, weight=0, color="#994444", label="188"]
  "0xa4c138f5a2095d76" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{Hareket MW - Kiler|0xa4c138f5a2095d76 (0x4ab7)|LeapMMW Human presence sensor (MTD085-ZB)|11 seconds ago}"];
  "0xa4c138f5a2095d76" -> "0x7c31fafffed16125" [penwidth=0.5, weight=0, color="#994444", label="151"]
  "0xa4c138f5a2095d76" -> "0x70b3d52b601339ad" [penwidth=0.5, weight=0, color="#994444", label="55"]
  "0xa4c138f5a2095d76" -> "0xa4c1380263b9fab7" [penwidth=0.5, weight=0, color="#994444", label="206"]
  "0xa4c138f5a2095d76" -> "0xa4c13890f122b40b" [penwidth=0.5, weight=0, color="#994444", label="255"]
  "0xa4c138581c46934c" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Sicaklik/Nem - Mutfak|0xa4c138581c46934c (0x3a27)|Tuya Temperature & humidity sensor with display (TS0201)|25 seconds ago}"];
  "0xa4c138581c46934c" -> "0x70b3d52b601339ad" [penwidth=1, weight=0, color="#994444", label="111"]
  "0xa4c138083d7cf304" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Sicaklik/Nem - Yatak Odasi|0xa4c138083d7cf304 (0xcfe9)|Tuya Temperature & humidity sensor with display (TS0201)|6 minutes, 17 seconds ago}"];
  "0xa4c138083d7cf304" -> "0xa4c1380263b9fab7" [penwidth=1, weight=0, color="#994444", label="221"]
  "0x00124b002397263f" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Buton - Yatak Odasi|0x00124b002397263f (0x6ded)|SONOFF Wireless button (SNZB-01)|1 hour, 22 minutes ago}"];
  "0x00124b002397263f" -> "0x7c31fafffed16125" [penwidth=1, weight=0, color="#994444", label="134"]
  "0x00124b002397399e" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Buton - Yatak Odasi 2|0x00124b002397399e (0xa469)|SONOFF Wireless button (SNZB-01)|1 hour, 21 minutes ago}"];
  "0x00124b002397399e" -> "0x7c31fafffed16125" [penwidth=1, weight=0, color="#994444", label="150"]
  "0xfc4d6afffe371b3d" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{IR - Yatak Odasi|0xfc4d6afffe371b3d (0x73aa)|Moes Universal smart IR remote control (UFO-R11)|1 hour, 22 minutes ago}"];
  "0xfc4d6afffe371b3d" -> "0xa4c1380263b9fab7" [penwidth=1, weight=0, color="#994444", label="230"]
  "0xa4c13820b48c197b" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Sicaklik/Nem - Salon|0xa4c13820b48c197b (0x2c9e)|Tuya Temperature & humidity sensor with display (TS0201)|19 minutes, 1 second ago}"];
  "0xa4c13820b48c197b" -> "0x7c31fafffed16125" [penwidth=1, weight=0, color="#994444", label="40"]
  "0x3425b4fffe4c4538" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{IR - Salon|0x3425b4fffe4c4538 (0x7bdd)|Moes Universal smart IR remote control (UFO-R11)|1 hour, 17 minutes ago}"];
  "0x3425b4fffe4c4538" -> "0x7c31fafffed16125" [penwidth=1, weight=0, color="#994444", label="56"]
  "0xa4c13890f122b40b" [style="rounded, filled", fillcolor="#4ea3e0", fontcolor="#ffffff", label="{Zigbee Priz 1|0xa4c13890f122b40b (0xf905)|Elivco Smart plug (with power monitoring) (LSPA9)|27 seconds ago}"];
  "0xa4c13890f122b40b" -> "0x7c31fafffed16125" [penwidth=0.5, weight=0, color="#994444", label="134"]
  "0xa4c13890f122b40b" -> "0x70b3d52b601339ad" [penwidth=0.5, weight=0, color="#994444", label="55"]
  "0xa4c13890f122b40b" -> "0xa4c1380263b9fab7" [penwidth=0.5, weight=0, color="#994444", label="188"]
  "0xa4c13890f122b40b" -> "0xa4c138f5a2095d76" [penwidth=0.5, weight=0, color="#994444", label="181"]
  "0xa4c138fc8ad8d27e" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Kapi/Pencere - Calisma Odasi|0xa4c138fc8ad8d27e (0x4cd0)|Tuya Door/window sensor (TS0203)|55 minutes, 28 seconds ago}"];
  "0xa4c138fc8ad8d27e" -> "0x7c31fafffed16125" [penwidth=1, weight=0, color="#994444", label="217"]
  "0x00124b00251334d4" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Kapi/Pencere - Giris|0x00124b00251334d4 (0xe903)|SONOFF Contact sensor (SNZB-04)|52 minutes, 8 seconds ago}"];
  "0x00124b00251334d4" -> "0x70b3d52b601339ad" [penwidth=1, weight=0, color="#994444", label="127"]
  "0x00124b00239e4a4f" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Kapi/Pencere - Mutfak|0x00124b00239e4a4f (0x3348)|SONOFF Contact sensor (SNZB-04)|28 minutes, 13 seconds ago}"];
  "0x00124b00239e4a4f" -> "0x70b3d52b601339ad" [penwidth=1, weight=0, color="#994444", label="160"]
  "0xa4c1384bc091c389" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Kapi/Pencere - Kiler Pencere|0xa4c1384bc091c389 (0xb223)|Tuya Door/window sensor (TS0203)|46 minutes, 16 seconds ago}"];
  "0xa4c1384bc091c389" -> "0xa4c13890f122b40b" [penwidth=1, weight=0, color="#994444", label="209"]
  "0xa4c138a6997be222" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Kapi/Pencere - Kiler Dis|0xa4c138a6997be222 (0x1ace)|Tuya Door/window sensor (TS0203)|33 minutes, 8 seconds ago}"];
  "0xa4c138a6997be222" -> "0x7c31fafffed16125" [penwidth=1, weight=0, color="#994444", label="93"]
  "0xa4c138ef633fcc63" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Sicaklik/Nem - Balkon|0xa4c138ef633fcc63 (0x7a11)|Tuya Temperature & humidity sensor with display (TS0201)|4 minutes, 9 seconds ago}"];
  "0xa4c138ef633fcc63" -> "0x70b3d52b601339ad" [penwidth=1, weight=0, color="#994444", label="55"]
  "0x00124b0025143fc3" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Buton - Kiler|0x00124b0025143fc3 (0xf0e5)|SONOFF Wireless button (SNZB-01)|13 minutes, 13 seconds ago}"];
  "0x00124b0025143fc3" -> "0xa4c13890f122b40b" [penwidth=1, weight=0, color="#994444", label="208"]
  "0xa4c13822d8313cee" [style="rounded, dashed, filled", fillcolor="#fff8ce", fontcolor="#000000", label="{Sicaklik/Nem - Kiler|0xa4c13822d8313cee (0x95f6)|Tuya Temperature & humidity sensor with display (TS0201)|1 minute, 5 seconds ago}"];
  "0xa4c13822d8313cee" -> "0xa4c138f5a2095d76" [penwidth=1, weight=0, color="#994444", label="102"]
}

ZHA or Z2M?

In my experience using the Dongle M, I still am fighting daily with device drop outs etc. but I have around 150 devices on my network. I do have a high number of dedicated repeaters and a high ratio of routers in the form of mains powered ZigBee devices such as lights.
Do try to use AI to analyse debug logs as it helped me to a degree.

I honestly gave up on trying to use it. It was just a waste of money.
I tried to give it another chance by waiting for updates but it never really fixed the main issue of devices randomly getting disconnected.
In this thread sonoff team explained why it will show a lower LQI per devices, but they never explained the disconnects or devices just taking forever to pair.

I’m not having disconnection issue with about 30 devices connected and 3 dongle max as router. I don’t know maybe is just an issue with more devices.

Hi, are there any updates regarding the implementation of this feature? Several months have passed and the latest available version is still 1.0.10. Thank you

I got 69 devices and I´ve had literally zero issues since I bought my Dongle-M almost half a year ago.

Glad it works for you. I have the Dongle Plus - E & all my instability problems started when I switched to the Dongle M, the opposite of what I expected. :frowning:

I’m using a Dongle-M (Max) as a Thread border router with OpenThread on HA. It seems to be performing just fine and signal levels appear solid. I know this post is about the -M as a Zigbee coordinator but just wanted to post my experience with it running the Thread firmware.