It absolutely makes sense that a single multi-protocol stick won’t perform as well as two separate sticks, especially for larger networks.
I’m just starting out with my Home Automation journey and don’t plan to have loads of Zigbee devices, about 10 to start with. But I guess it will slowly grow larger and larger over time
Since I’ll have quite few devices, I thought a single stick with both Zigbee and Thread support would be convenient to start with. And if I add more devices in the future and performance is bad, I can just get another stick and run one protocol on each.
The Skyconnect stick looks good, and the estimated delivery time where I live is in November/December. However, if the Sonoff ZBDongle-E is equally good, then I think I might as well get that one now and order a Skyconnect in the future if I wan’t a separate one for Thread/Matter.
I’m also wondering if the Sonoff stick will have a better range due to the external antenna, or perhaps it doesn’t make much of a difference? Becuase the Skyconnect only has an internal antenna, right?
In a real-world environment that does usually not really matter so much if you add many mains-powered Zigbee devices spread out in your home. But a good antenna on the Zigbee Coordinator adapter could matter a lot if do not have many Zigbee Router devices and/or have mostly battery-powered devices as those have short range and will therefore have issues if they try to talk directly to the Zigbee Coordinator instead of sending messages through the network mesh via the closest Zigbee Router.
Zigbee uses mesh networking topology, which means that most mains-powered devices are a “Zigbee Router” that can act as signal repeater and range extended by transmitting data over long distances by passing data messages through the Zigbee network mesh of intermediate devices to reach more distant Zigbee devices. Thus to have a healthy Zigbee network you need many Zigbee Router devices relativly close to each other in order to achieve good coverage and range.
Simply add more main-powered Zigbee devices and decrease distance between Zigbee devices in Zigbee network mesh to get better range and coverage:
Zigbee uses mesh networking and depends on having many “Zigbee Router” devices to extend range and coverage:
Recommendation is to add additional mains-powered Zigbee devices known to be good Zigbee Router devices.
Add more Zigbee Router devices and reduce their distances to extend network mesh coverage and range.
Note that not all mains-powered devices have firmware that make it act as a Zigbee Router device.
Some brands/models of Zigbee Router devices are know to only work well with same brand of devices.
If so then you could also try asking MattWestb who among other things also built loads of such ESP32-based DIY gateways but based on ripped-out and hacked IKEA Trådfri Zigbee modules which are using Silicon Labs EFR32 SoCs as well.
Well I do not know if the EFR32MG21 on the board of the “ZBDongle-E” dongle board is even mapped to be pin-compatible with the EFR32MG21 the NSPanel Pro. I only know that this “ZBDongle-E” is suppose to be pin-compatible with ITead’s previous/old Zigbee 3.0 dongle barebone model “9888010100045” USB adapter (and the SM-011/ZYZBP008 radio module from CoolKit-Technologies used in the first Sonoff ZBBridge by ITead) because I specifically asked about that and was answered by Daniel Zhan here → https://github.com/grobasoz/zigbee-firmware/issues/28
Though I don’t think we should assume ITead definitely mapped BTL to the same pin on ZBDongle-E(?).
In a real world environment that does usually not really matter so much if you have a many mains-powered Zigbee devices spread out in your home. But it could matter a lot if do mot have many Zigbee Router devices and/or mostly have battery-powered devices as those have short range.
…
@Hedda Okay, thanks a lot for your help and explanations! I live in a pretty big house so I’ll probably need some Zigbee routers/repeaters anyway to get a strong and stable connection to all of the Zigbee sensors I plan to use around the house.
I have to use multiple WiFi accesspoints already, and since Zigbee uses the same frequencies I’m going to assume the reach of the Zigbee signals will be about the same as for my WiFi
Nope, that is a wrong assumption, remember that battery-powered Zigbee devices can operate on a single CR2032 (~200 mAh) coin-cell battery for a couple of years by only sending low-power signals.
Zigbee has a much shorter range and poorer penetration of building materials than Wi-Fi because Zigbee is using “low-power” and “low data rate” digital radio (i.e. they send very short messages at low power amplification in order to save battery), but Wi-Fi is relatively “high-power” and “high data rate”.
That is also why Wi-Fi strong signals will interfere with Zigbee, overpowering Zigbee signals and preventing them from being received properly, while Zigbee only sending very weak signals will in practice never interfere with WiFi.
Anyway, I also live in a relatively large house and dense internal walls so radio penetration is horrible, so that is the perfect example of when you should really need to start by adding many Zigbee Router devices first before you even think about adding any battery-powered Zigbee devices to the network.
Having many good Zigbee Router devices generally also makes for a more stable Zigbee network if each device has redundant routes/paths that its messages can take in case one of the routers dies.
Oh, yeah… that’s right. When I think about it it’s pretty obvious that the battery powered ones will send relatively low powered signals, especially compared to the Zigbee coordinator and Wi-Fi devices
Thanks for the link. I saw that guide earlier and will read through it again just to make sure I’m not missing anything! It sounds like I’ll have some more planning to do before I go ahead and buy a bunch of battery-powered sensors Unfortunately the IKEA Signal Repeater seem to be out of stock in every IKEA warehouse here, so I’ll research if there are some other good alternatives or simply wait for it to get in stock again.
Actually, battery-powered devices were a bad example since all Zigbee devices use similar low-power digital radios because all Zigbee radio chips follow IEEE 802.15.4-based specification standards all Zigbee devices, including mains-powered Zigbee Router devices and the Zigbee Coordinator, have similar broadcast power. And even though a Zigbee Coordinator usually has a little more transmit power amplification it does not make it better at receiving signals, as that it only means it shouts louder but does not listen any better. The best is simply to always assume that all Zigbee devices have very short range and poor wall penetration and then just try to build a mesh network that work around those limitations by adding several permanently online Zigbee mains-powered devices as close to each other as as possible, even aiming 10-meter transmission distances with line-of-sight if you can. See summary of the design basis premises → https://en.wikipedia.org/wiki/Zigbee and https://en.wikipedia.org/wiki/IEEE_802.15.4#Overview
@Hedda (or someone else): I’ve ordered the ZBDongle-E, an IKEA Signal repeater and two Zigbee sensors just to try it out before ordering everything that I plan to use.
But I started thinking about Matter/Thread since these products are about to get released and seem to be the “new great thing”. If I start building a Zigbee network today with a bunch of Zigbee routers (repeaters) etc, will a Matter/Thread sensor be able to use the Zigbee repeaters or would I have to build a completely separate network just for Matter/Thread devices if I end up buying one?
For now plan on separate everything for Thread and Zigbee.
The HA folks intend to enable the Yellow and SkyConnect to be dual use - share one radio for both Thread/Matter, but has said that it will initially be single use. Yellow/SkyConnect use the same chipset as your ZBDongle-E, so there may be hope for the same functionality on the “E” some day. However, at this point it’s ALL promises and vaporware, no matter how sincere the intent. Wait and see.
Even in a shared radio situation, I don’t think zigbee and Thread will share a mesh. I think it will still be separate nets that happen to share a radio at the HA end. I am not 100% on that. Again, wait and see.
The short answer is that you will for all foreseeable future need to handle your Zigbee network(s) and Thread network(s) completely separately and you should assume that (not counting the Zigbee Coordinator adapter) even hypothetical Zigbee and Thread multi-protocol devices that once you connect a such device to a Zigbee network then you will not be able to be also connect that same device to a Thread network at the same time (e.g. concurrent multi-protocol support in Zigbee router and/or end-devices), so assume that even with such devices with Zigbee and Thread multi-protocol support you will still need to decide which of those two protocols that you wish to use for that specific device (by choosing which network to connect it to) and then that device will work as a dedicated Zigbee device or as a dedicated Thread device, not both at the same time.
The exception is RPC (Radio Co-Processor) adapters, which EFR32MG2x-based adapters/modules like the ZBDongle-E dongle and the Home Assistant SkyConnect USB Stick will be abe to become when re-flashed with RPC firmware (instead of a NCP / Network Co-Processor firmware), which as per the Radio Co-Processor design a such RPC adapter/module will be able to be both a Zigbee Coordinator and Thread Border Router at the same time by acting as an off-loading part of the Zigbee stack and part of Thread stack to daemon/service applications running in the host operating system and practically just using the adapter as a dumb radio that more or less only handles time-slicing of radio scheduling in order to transmit and receive traffic to and from Zigbee and Thread networks at the same time. For more detailed information see → https://openthread.io/platforms/co-processor and https://github.com/zigpy/zigpy/discussions/894
However, there could potentially come other exception devices in the future as both Zigbee and Thread are network stacks running on digital radios based on the IEEE 802.15.4 specification and most newer such radio SoC/MCU chips for IEEE 802.15.4 (like the EFR32MG21) do have multi-protocol support and some could technically support firmware that runs a Zigbee protocol stack and a Thread protocol concurrently, though personally, I doubt that any commercial company has any clear financial interest in releasing such devices when they could instead just hope to sell the same device twice with different firmware configuration.
Regardless, the fact remains that there will never be any intercommunication between a Zigbee and Thread at the transport or network layers as those protocols are not interoperable with each other, so you will always need to manage your Zigbee network(s) and your Thread network(s) completely separately. As such any interaction between Zigbee and Thread networks will only be done at the application layer, meaning in the gateway/bridge that supports Matter/CHIP.
Understand that Matter (CHIP) is at an architecture design level technically only running at the application layer (and partially also the transport layer) but not the network layer when looking at ISO model, so by design, Matter/CHIP will always be dependent on some other technology to handle the TCP/IP at the network layers which it needs, and the Zigbee network stack does not support TCP/IP (at least not in the Zigbee 3.x specifications and earlier).
As such Matter/CHIP should in the future only ever add support for additional network stacks if that network stack already supports TCP/IP, and I do not think that future Zigbee specifications will ever add TCP/IP support to its transport and network layers, even though I believe there was a few proposals more than 10-years ago to transplant Zigbee network layer to IP using CAP / Compact Application Protocol and CoAP / Constrained Application Protocol to solve a similar purpose that Matter/CHIP was designed for. Bluetooth Low Energy could however be a potential another candidate network stack for Matter/CHIP in the future as there is an IPv6 over BLE / Bluetooth Mesh support.
Not sure if helpful.
I was trying to flash a ZBDongle-E with router firmware and even after what appeared to be 95% success it kept showing as stuck in bootloader mode with probe. Out of curiosity I tried pairing in this state and it worked fine. Im running a ZBDongle-P (coordinator) in home assistant with zigbe2mqtt.
C:\Temp\elelabs\Elelabs_EzspFwUtility.py flash -f Z3RouterUSBDonlge_EZNet6.10.3_V1.0.0.gbl -p com10 -b 115200
2022/10/15 15:28:10 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected:
2022/10/15 15:28:10 Elelabs_EzspFwUtility: Gecko Bootloader v1.12.00
2022/10/15 15:28:10 Elelabs_EzspFwUtility: Allready in bootloader mode. No need to restart
2022/10/15 15:28:11 Elelabs_EzspFwUtility: Successfully restarted into X-MODEM mode! Starting upload of the new firmware… DO NOT INTERRUPT(!)
…
…
2022/10/15 15:28:50 Elelabs_EzspFwUtility: Firmware upload complete
2022/10/15 15:28:50 Elelabs_EzspFwUtility: Rebooting NCP…
2022/10/15 15:29:04 Elelabs_EzspFwUtility: EZSP adapter in bootloader mode detected:
2022/10/15 15:29:04 Elelabs_EzspFwUtility: No such command
I think once powered on (without the case) I presses the innermost button. The outer (closest to the edge of the PCB) does some kind of reset/reboot… I think…
Hi Edwin, I would greatly appreciate if you would like to share your workflow now you’ve got your ZBDongle-E (V2) up and running as routers after your latest update.
Installing and setting up my Zigbee devices in ZHA and need some extra router power for my mesh, due to the used contruction materials in my home. I already have the ZBDongle-P as coordinator running fine and several electrical sockets/meters as zigbee routers.
