Thanks a lot …
i didn´t have luck with any of the methods - did try to build python an my WIN10 PRO - in the ende there were cryptic error messages about not being able to build the “wheel”)
So i gave up for the moment - My SONOFF-E (Ver 1.0) is working “as delivered” - only ZigBee … 6.10.3.0 build 297
Does anyone have a SONOFF-E with higher hardware versions than 1.0?
What would be a reason to advise me to switch from firmware 6.10.3.0 build 297 to the new firmware 7.3.1.0 I have never done any updates, and if I can I avoid it, even if since yesterday a Tuya socket has disappeared from zigbee2mqtt I don’t think it depends on the dongle And for this problem
The old preconception that firmware updates are “risky” doesn’t apply (as much) on recent/decent hardware. Many connected devices will even auto-update firmware by default when a new one is available. The one thing you should avoid is connected devices that don’t allow you to update firmware. 3-5 years down the road (if not sooner), you might as well hang a sign “Entry Here”. Always check on that before buying!
For “lesser” devices (i.e. stuff without much support…) such as the dongle here, you should check the stability of the flashing procedure (quick net search); if you see a myriad of issues, bricked devices, then only update if there is a good reason for it (security issue, not working properly, etc.). On the other end, if the flashing is easy, then definitely go for it, especially if the current firmware is getting old.
As for the dongle specifically, 6.10.3 is 2 years old and there were about 20 updates since. I don’t think there’s much hope for “official” Sonoff updates at this point. But to know exactly what the updates would bring to the table, you’d have to go through the release notes. On devices like this, that define a communication protocol, you also have to consider the “other side”, ZHA/Z2M, and what they support/recommend; new versions may break compatibility with older ones.
Personally, I flashed two dongles, half a dozen times, including router and coordinator firmware. I used Sonoff’s recommended procedure the first couple of times, then darkxst’s tool recently. I didn’t have a single issue (darkxst definitely easier). And like I said, 7.3.1 has been working with Z2M for over a month without problem.
Note that it is recommend to instead use TI CC2652P based “Sonoff ZBDongle-P” instead of Silabs EFR32MG21 based “Sonoff ZBDongle-E” for Zigbee2MQTT.
Reason is that the ezsp adapter code in the zigbee-herdsman library which Zigbee2MQTT does not quite yet have feature-parity with its zstack adapter code, and most notable the ezsp adapter code is missing full backup and restore support → Koenkk/zigbee-herdsman#319 preventing restoring backups and migration → FAQ | Zigbee2MQTT
FYI, check out this thread for unofficial method on how to migrate from ZBDongle-E to ZBDongle-P for thoee using Zigbee2MQTT → Koenkk/zigbee2mqtt#16478
PS: If where to use Home Assistant’s ZHA integration then would instead recommend Silicon Labs over Texas Instruments based Zigbee Coordinator → Zigbee Home Automation - Home Assistant however that is primarly just because Home Assistant SkyConnect is based on Silabs EFR32MG21 → https://www.home-assistant.io/skyconnectDevice Quantity Connection Home Assistant Notes SONOFF Zigbee 3.0 USB Dongle Plus-E 1 USB Zigbee2MQTT Used to control all Zigbee smart bulbs and Blinds. ZHA was becoming un-reliable for me so switched to Zigbee2MQTT
I just wanted to drop a note on this thread in order to be self informed (via email notifications on this thread) of progress about EZSP firmware from time to time.
Here is my setup:
Zigbee network with 79 devices, of which, 51 are routers and 28 are end devices. All end devices are less than 4m away from routers. There is no more than 5m between routers.
Home Assistant, always updated to latest version running on a Raspberry-Pi 4
Zigbee2Mqtt (and the Mosquito broker) in a separate hosts (2 separate virtual machines, they both run in the same hardware with Proxmox)
Last week, I’d a deconz Raspbee Zigbee controller in a dedicated Raspberry-Pi 4 (different from the one running HA) but I decided to migrate to Zigbee2Mqtt because of lack of information about what’s going on in the zigbee network with the deconz hardware/software, lack of support for HTTPS in their web app “Phoscon” (my iPhone refused to connect to their web application without HTTPS, limited capacity to rename devices in the zigbee network as that functionality was removed from their desktop application and some other issues, so I migrated to a SonOFF-E Zigbee 3.0 USB Dongle Plus dongle.
My dongle is running EZSP v8 version 6.10.3.0 build 297. I’m having some issues when disconnecting devices from the network as they re-appear immediately after they are deleted from the net. I’d to repeat the delete process several times to success. Also the touchlink is not supported (lack of support in the firmware). But I like that the serial connection is 115200 bauds because in theory, this can handle more devices and messages. I also suffer from some end devices and routers that don’t like each other in the network (I decided to replace OSRAM bulbs with IKEA ones and SonOFF mini with equivalent Aqara on/off devices…)
I’ve also purchased a second SonOff Zigbee 3.0 USB Dongle Plus (like the one I already have) in order to test new firmware versions with the possibility to go back to the current firmware just switching them.
So, I’m definitively interested to know more and monitor the progress of the EZSP firmware in order to see if I can stabilise my zigbee network.
Re-pairing 79 devices is not an easy task. I’d to review all existing scenes and automations in HA because of the changes in device names…
In the end, a wall switch and a bubble physically connected to the AC is far more reliable than all this stuff I love technology in general and in my mind I know that there is more potential in this mesh networks than in the old physical wires but it has to prove it can be reliable too.
With that many, you can easily change all names/IDs with vscode addon, and a simple search/replace & then config reload. Once you’re in Z2M though, as long as you name your devices consistently, even if you re-pair after a full reset of Z2M, it will pop back up in HA without issue (did for me anyway). If you re-pair without the aforementioned reset, it’ll all just come back on its own, in Z2M (remembers previous devices, names and all) and HA .
Check this for an easier time with device changes
The one thing you want to avoid in HA is using the action/trigger Device, that uses device_id and won’t port if you change a device (even if named the same); use the services of the corresponding domain instead, or State/Numeric state for a trigger.
If you keep that rule in all your automations/scripts/etc, you can re-pair or entirely replace a device, as long as you keep the same name in Z2M (and thus the same entity_id generated in HA), it should keep working everywhere.
Of course, sometimes the logic behind the entity_id automatic generation changes; that might force you to make a couple of changes, but that should be far less frequent.
Despite an issue or two in over two years my house has been running on Zigbee, I wouldn’t go back. I’ve forgotten what wall switches feel like (except when I have to step back and flip one when I’m not at home… ). Not to mention the massive power savings (heat air/water, solar panels optimization, etc)…
The Dongle-E has far better range than my previous hub (Echo 4), and allowed me to save on batteries too; I’d estimate about 3 or 4 times less battery changes on farther devices!
I’m planing to update Sonoff Zigbee 3.0 USB Dongle from 6.10.3.0 to a new version but I’ve some doubts. I already purchased a second dongle in order to be able to flash the new firmware in the new device and just switch dongles for testing.
Here are the questions:
I’m having difficulties to find the firmware to flash. I can find documentation about the new releases of the SDK from Silabs but that is not ready to be flashed to the dongle.
I’ve read that the current firmware (6.10.3.0) provides a complete NCP at the coordinator level. This is what I want, there are some pages suggesting to install an RCP firmware but I’m afraid that would require to also to update Zigbee2mqtt side or even switch to ZHA and this is not desired at this moment. I think I just want to keep using an NCP firmware.
I want to be able to use touchlink capabilities and firmware 6.10.3.0 does not support them. I’m not sure if new firmware versions have added support for it. As stated in point 1, I can’t find sources for unofficial firmwares so I can’t read their release notes.
Only install rcp firmware if you want to install the multiprotocol addon and share the dongle with Thread. Multiprotocol works with z2m or ZHA.
Not sure about touchlink.
I’m not sure how easy that is with the ZBDongle-E if you are expecting plug and play switching between sticks. Z2M doesn’t support full backup/restore for EZSP. I think you should be able to use the zigpy toolchain to backup/restore outside of z2m.
The other possible issue is historically resetting the MAC on EZSP chips was a one time, irreversible action. The HA devs overcame that for SkyConnect, but I am unclear if the SkyConnect updates have made it into other firmware/flashing tool builds.
I’ve successfully flashed ncp-uart-hw-v7.3.2.0-zbdonglee-none-115200.gbl to the new dongle but I’m unable to execute universal-silabs-flasher --device /dev/tty.usbserial-202305080921111 --probe-method ezsp write-ieee --ieee e0798dfffe77c2f0 on the new dongle to write the same address I’ve on the old dongle.
This means my only option will be to just flash the old dongle with new firmware version and forget to just switch dongles.
I’m not sure what functionality is included/required in the Z2M backup/restore for EZSP. I just assumed the change in the dongle with same address and different firmware version would ‘just work’. I consider the dongle was as a pure hardware device without a memory that requires to be permanent between boots (except for the ieee address)
Like darkxst says in the github issue, the only way to know the differences, is to read Silabs SDK release notes… and ensure the adapter also supports new features, if it’s hardware-dependent ones.
That is only partially the case when using as RCP (Radio Co-Processor) with the Silicon Labs EmberZNet Zigbee deamon (i.e. the multiprotocol addon with Silabs zigbeed), though not really true then either as it with RCP just offloads most but not all runtime parts of the Zigbee stack to the host computer when used as RCP. However it really is not the case when using as NCP (Network Co-Processor) as then the whole Zigbee stack is stored and runs onboard the Zigbee Coordinator microcontroller chip hardware on the dongle adapter, including all the Zigbee network information and security keys for your paired/joined devices. More details in Silabs docs if want to know how those two architectures work → https://www.silabs.com/documents/public/user-guides/ug103-03-fundamentals-design-choices.pdf
For tips on workaround backup and restore method/process for full NVRAM backups needed for Zigbee radio adapter migrations if using Zigbee2MQTT see this discussion in their community (which explain how to migrate between different radio types for Z2M regardless of manufacturer and Zigbee stack used) → https://github.com/Koenkk/zigbee2mqtt/discussions/16478
There is still only have experimental support for Silicon Labs EmberZNet based adapters in the zigbee-herdsman libary it depends on but if you upgrade to the very latest community firmware and use Zigbee2MQTT Edge (beta) releases then there is a new ”Ember” driver that you can configure it to use that is supposedly better than their ”EZSP” driver. Note that you should post any follow-up questions to that the in the Zigbee2MQTT community discussion forum on GitHub instead → https://github.com/Koenkk/zigbee2mqtt/discussions
I have a general question as I own a ZBDongle-E to which I have connected several Xiaomi humidity sensors using the zigbee2mqtt protocol.
My question is as follows: I have purchased a https://moeshouse.com/products/wifi-3-in-1-co2-monitor
It says that it is fully compatible with the Tuya protocol. Do I need to buy anything extra for it to be recognized by Home Assistant, or will the adapter I have work? I have Home Assistant running on a Raspberry Pi 4.
Does anyone have a SONOFF-E with higher hardware versions than 1.0?
I love technology in general and in my mind I know that there is more potential in this mesh networks than in the old physical wires but it has to prove it can be reliable too.
). Not to mention the massive power savings (heat air/water, solar panels optimization, etc)…