Thank you very much for using Dongle-M and your suggestions.
We are working on an open source firmware based on ESPHome for Dongle-M. We should be able to release it within next week. This firmware is much simpler and I hope it meets your needs well.
My own issues were general instability that ultimately got pinpointed to be sonoff s40 lite zigbee plugs…and some ewelink sa-003 plugs… I switched coordinators to a cc2650p and the issues I was having persisted. I never saw the ash issue that the other person speaks of, but I had lots of weirdness in the logs with the aforementioned router devices.
I find it interesting in the other thread - that the ash messages were decoded to be related to routing. I question if the person experiencing those issues is facing something similar to the issues I was having; if they have some routers that arent properly self organizing after their initial connection
I have not switched back to the dongle-m simply because things are working and extremely stable - its in my best interest to hold off to see what happens with the dongle-m firmware - i plug it in and check for updates daily lol. I dont want to reconnect everything til 1.0.11beta is 1.0.X stable - i’m intrigued by increased baud rates, but the stability right now is amazing. I will be back eventually.
id argue that architecturally you arent using the same tcp path - yes it goes through the esp32, but ur skipping an entire PHY
I think that’s a fair distinction, and your experience with the S40 Lite / SA-003 routers is actually an interesting data point.
I agree that problematic Zigbee routers could potentially explain some of the instability you were seeing, and it’s also interesting that changing the coordinator to a CC2650P didn’t eliminate those problems. If the ASH traffic in the other thread really was related to routing/network traffic, then I agree that the router devices themselves deserve investigation before concluding that the ESP32/TCP implementation is the root cause.
On the TCP point, though, I’m not sure I would describe my setup as architecturally different at the TCP layer.
With the Dongle-M connected over Wi-Fi, the path is essentially:
ZHA/zigpy → TCP → WiFi → ESP32 → UART → EFR32
With a local connection to the Dongle-M, you would have something like:
ZHA/zigpy → TCP → Ethernet/USB/network interface → ESP32 → UART → EFR32
So yes, the physical/network path is different. WiFi introduces the 802.11 PHY/MAC layer and the associated radio/network stack, whereas a wired connection does not. But both are still carrying the same TCP connection to the ESP32, and the ESP32 is still responsible for bridging that TCP connection to the EFR32 over UART.
That’s actually why I find the fact that my WiFi setup has been stable somewhat useful, although obviously it doesn’t prove that the TCP/UART implementation is problem-free. It just makes me less convinced that there is a universal “Dongle-M over TCP is unstable” problem.
I also think the routing hypothesis is worth testing separately. If the ASH errors correlate with particular Zigbee routers or with changes in routing/topology, that would point in a rather different direction than a pure ESP32/TCP transport problem.
And I completely understand why you don’t want to move everything back to the Dongle-M while your CC2650P setup is stable 
Daily firmware-update checks are probably safer than rebuilding the whole Zigbee network every time SONOFF publishes a beta. I’d also be interested in seeing whether the higher baud rate in 1.0.11 actually changes anything once it reaches a stable release.
Hi, @mikerocklewitz .
We tried running Home Assistant in VirtualBox, using Dongle-M as the coordinator, and adding the S40 ZBTPB Lite (firmware version 1.0.3) through Zigbee2MQTT. However, after four days of testing, we have still been unable to reproduce the issue you reported.
Could there be any differences in our test environment or steps? Do you have a specific environment or a set of steps that can reliably reproduce the issue? This would help us reproduce and investigate the problem as soon as possible.
I appreciate the efforts - i’m not sure what more i can provide. I have 53 devices, 8 of which were routers at that time. 3 being s40zbtpb lite 1.0.3. had one SA-003 in the the mesh as well that produced similar issues after removing the s40’s. My location is pretty noisy with 2.4ghz, so perhaps there was some interference playing a role but i had moved it to channel 25 from 11… which isnt as noisy, the issue persisted, immediately cleared up when these plugs were unplugged.
There are too many variables to properly identify the root of the issue. I can say for certain, its been flawless since removing those plugs.
I will order one of the new s61 plugs this week to experiment with. I must say: your new zigbee stuff is flawless so far.
Edit to add…
these were not new s40 plugs…theyre like 4 years old and were plugged in for the same length of time. I’ve seen other devices become unstable after years of service - capacitors start losing their smoothing abilities etc…
Running HA in a VirtualBox is not the same as running it on a real thing 
in all fairness i’m running it as a vm in unraid server…it depends how they set it up
It seems that the conditions required to reproduce the issue are still not very clear. Could you please provide some more details about your setup and test environment?
We will try running Home Assistant on a Raspberry Pi to see if we can reproduce it.
If we are still unable to reproduce the issue and there is no confirmed reproduction path available, there will unfortunately be very little we can do to investigate it further.
There is nothing more i can provide on my end.
I don’t expect anything else. Thank you for what you have done attempting to replicate the issue. These were my experiences. Removing them is what fixed my issues.
Perhaps someone else having dongle-m issues could provide more information, but i cant. Like i said - too many variables. Too many variations.
The person with the ASH errors that translate to be a router - i thought it was relevant to share that a specific model of router, removed from my mesh, fixed my issues. For all we know it could be a specific brand/make/model/fw version of an end device that initiates the issue and then things start going bad. That is too much testing for me now that things work flawlessly.
Again - thank you for your support and looking into it @SuiKa. Thank you @MichaelLearnsToCode for the continued efforts on the firmware.
personal opinion: for a perfect dongle-m, open the source code. Give it to the community to play with. I understand why its closed due to intellectual property and whatnot. I can understand why as a developer it would be difficult to share your hard work… but this is not a difficult device for anybody (consumer or cloner) to fully reverse engineer the board (especially with shared pin info) and use the official firmware on a blank esp32 chip. No ewelink cloud access - there’s not much to really protect
I think there is one important misconception here: the Dongle-M isn’t really an eWeLink cloud device. It’s a Zigbee coordinator/NCP. It can be used with Home Assistant, ZHA, Zigbee2MQTT, CUBE OS, etc., and none of these require eWeLink Cloud for the Dongle-M to operate.
So “there’s not much to protect because there’s no eWeLink cloud access” doesn’t really follow. The firmware itself contains the coordinator/NCP implementation and other proprietary code, which is valuable IP regardless of whether the device ever connects to eWeLink Cloud. And the fact that the hardware can potentially be reverse-engineered doesn’t necessarily mean the firmware should be open-sourced. Reverse-engineering and open-sourcing are two completely different things.
I’m going to disagree with you completely here …the whole point im making is its NOT an ewelink cloud device. It’s a uart bridge with some extra bloat that has nothing to do with being an actual ncp/rcp/etc.
The zigbee radio firmware itself is nothing special at all - a few clicks from the sdk or borrowed from another repo.
The only ip you speak of is the radio updater (which most likely is an open source component pulled from something else), mqtt implementation - that has zero relevance to the core functionality, webhooks, and the gui itself. The whole of the esp32 firmware is going to be a combination of open source components…i’d be very curious to see the list of GPL licensed components they used - and id very much appreciate the source code of those GPL components as its part of the license.
yes. reversing and open sourcing are 2 different things. That is obvious. The point being, however, anyone with a knack to clone it, could clone it and sell it - as is. With the source closed. The firmware is available to download - bootloader/partitions/app/all of it. Since it is NOT a cloud device, I dont understand what there is to protect. From cloning? well i dont need the source for that…
I think we’re actually agreeing on the first point: the Dongle-M is not an eWeLink Cloud device. That’s precisely why I don’t see the relevance of the cloud argument to whether the firmware should be open-sourced.
As for what’s actually inside the firmware, I think we’re getting into speculation. Maybe much of it is based on existing SDKs and open-source components, maybe it isn’t. Without seeing the source or a proper component/license list, neither of us can really know how much of the firmware is Sonoff’s own work.
The GPL point is different, though. If GPL-licensed components are actually used in a way that triggers the corresponding source-disclosure obligations, that’s a perfectly legitimate thing to ask Sonoff about.
But “the firmware can be downloaded and therefore anyone can clone the device” doesn’t really mean that there is nothing to protect. A binary firmware image can be redistributed or reverse-engineered without giving you the source code, development history, build system, proprietary modifications, or the ability to properly maintain and develop it.
Whether Sonoff should open-source the Dongle-M is a reasonable opinion. I just don’t think “it doesn’t use eWeLink Cloud, therefore there is nothing to protect” is a particularly strong argument.
Agree to disagree.
-protecting ewelink cloud stuff - that i could understand
-protecting revenue stream from random aliexpress shop selling clones - that i could understand
neither of those being protected by keeping it closed? I dont know…theres just no magic sauce here.
Calling it “a UART bridge with some extra bloat” seems like a rather odd way of describing a Zigbee coordinator.
If all that extra code is just bloat, presumably removing it should leave you with a perfectly functional Dongle-M - just a UART bridge. I suspect the result would be somewhat less useful. 
What you call “bloat” is the protocol handling, radio firmware updates, communication with the host, MQTT/webhooks, etc. These are the additional functions that make the device a complete product rather than simply an “ESP32 connected to UART.” I think you’re getting a little carried away 
the esp32 firmware is a glorified uart bridge quit while you are ahead
“Glorified UART bridge” is quite a confident conclusion for someone who hasn’t seen the source code. But sure, agree to disagree. 
I would certainly hope its only a glorified uart bridge. If its doing more than that in normal operation its probably the reason so many have issues lol
A UART bridge alone wouldn’t be much of a Zigbee coordinator, would it?
One more thing: You bought a finished product, and now you’re complaining that it’s too finished.
This post completely lost me. It was supposed to be about reporting Dongle-M issues, but it went down a completely different path as I kept reading.
I messed up my reply…so I’m good on all this…my zigbee works great. I dont care the end result moving forward lol