Hi @MichaelLearnsToCode , just wanted to ask, is my firmware on the latest stable versions ? I noticed i do get randomly new ip assigned without doing anything.
Hi, your Dongle-M is running v1.0.7 stable firmware, the latest beta is v1.0.8. You can update Dongle-M to v1.0.8 beta.
IP 169.254.232.8 is a Link-local address which is automatically assigned to host (Dongle-M) when host’s DHCP requests fails. But host will retry, so you can see a normal LAN IP 192.168.1.123 is assigned later.
We will look into it to see if there is anything wrong with the firmware.
And how get back to factory fw, there to download, want make it through web interface.
I dont want use SONOFF Dongle Flasher (my Dongle-M connected by POE ethernet, so only web interface usable for update )
Can you post direct link for all actual EFR32MG24 firmwares
Hi @MichaelLearnsToCode , i would like to report some issues with the Sonoff Dongle-M in router mode.
I have a home assistant server with a Home Assistant ZBT-2 as the main coordinator using Zigbee2MQTT. And i had setup the Sonoff Dongle Max in zigbee router mode, and it does not work to connect 3rd party devices through it. For example i am trying to connect some Aqara Window sensors , but it does not work through the Dongle M. I also have some Sonoff S60ZBTPF plugs which works perfectly as routers in my system. Just the Dongle M does not work as a router. I had tried the stable firmware 1.0.7 and does not work, and i had also tried 1.0.10 beta firmware and same issue.
Do you mean that Dongle-M as a Zigbee router could not be added to your Zigbee network managed by Zigbee2MQTT?
Or Dongle-M can be added to Zigbee2MQTT but is not labeled as a Zigbee router?
Or it all looks good for Dongle-M in Zigbee2MQTT, but no other Zigbee devices are connected to Dongle-M (as a Zigbee router) in Zigbee2MQTT’s network topology?
The issue is the 3rd variant: it all looks good for Dongle-M in Zigbee2MQTT, but no other Zigbee devices are connected to Dongle-M (as a Zigbee router) in Zigbee2MQTT’s network topology. Also when i press “Permit join” in Zigbee2Mqtt and i select Dongle-M, the end device does not connect. If i select for example another router like sonoff plug, or coordinator, that device connects.
What is the tool / site that you use in your screenshots, which can show device recent activity in the first image and can show legend in the second image ?
I am not familiar with it, I am sure that: it is not the dongle-m zigbee2MQTT web interface.
@ MichaelLearnsToCode I’ve noticed something in the firmware update panel and wanted to ask for clarification. Wouldn’t it make sense to remove the beta release notes once a stable firmware with the same version number is published? Right now the interface still shows the beta notes even though the corresponding stable version is already available.
From a user’s perspective this doesn’t seem to serve any practical purpose, and it can even create confusion about which changes actually apply to the stable release. Is there a specific reason for keeping the beta notes visible?
Its obvious that the dongle max has issues over tcp/ethernet/wifi…apparently usb even
I have weird issues as well with mine.
So my question is simple…can we get a firmware for esp32 + zigbee ncp that eliminates all the extra junk? Make the esp32 a tcp bridge only. Me personally, i dont need a web page. I dont even want wifi to work. I just want poe, DHCP gives static ip based on router rules. None of the stuff that it is now.
I think the HA thread you linked is worth looking at, but I would distinguish between two things.
I have actually been using the Dongle-M for many months. I received it for testing even before its official release, so I have used it with several different firmware versions over a fairly long period of time.
I did have some issues during the early period, but nothing resembling the failure described in that HA thread. I have never seen the repeated ASH frames / ACK loop followed by ERROR_EXCEEDED_MAXIMUM_ACK_TIMEOUT_COUNT, ASH_NCP_FATAL_ERROR and a TCP disconnect.
I’m using my Dongle-M over Wi-Fi with ZHA, so architecturally I’m still using the same TCP path. If this particular failure were happening in my setup, I would expect ZHA/zigpy to show coordinator/adapter communication errors, timeouts or eventually loss of the NCP connection.
But I see none of that in my logs. The Dongle-M has been running normally, and ZHA is not reporting anything resembling the failure described in that thread.
So I agree that the ESP32/TCP side deserves scrutiny - especially given SONOFF’s own statement that firmware 1.0.8 significantly improved UART-over-TCP connection stability. But I don’t think the linked HA thread proves that every Dongle-M user has a general TCP/Wi-Fi problem.
The minimal ESP32 TCP ↔ UART bridge idea is certainly interesting as a troubleshooting experiment. It could reduce the number of moving parts, but I would see it as a way to isolate the problem rather than proof that the Web UI, MQTT, eWeLink-Remote, etc. are actually causing the ASH failures.
