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.
I really wish I could answer your question, but I tried so many things when I got the errors I really cannot remember exactly what I did. To top it off, I even no longer own the Surface Pro’s I used: I sold them just last week after a factory reset. I basically tried to follow the descriptions from here:
Used my previous flashed ZBDongle-P to pair it into ZHA. Devise is visible in the Visualization but not connected to the coordinator. Has no end devises connected as well. WTH?
edit: updated wrong screenshot / added OS platform
FYI, many if not most Zigbee End Device products will not automatically change their connection to a closer Zigbee Router if you added that Zigbee Router after you added the Zigbee End Device products, so in those cases, you might just have to remove its battery/power for a while in order to it to make a new connection when put battery/power back or sometimes manually re-pair/re-join the Zigbee End Device in ZHA.
Those Zigbee End Device products that do automatically change their connection to a closer Zigbee Router usually only do so in intervals of once every 24 hours or more after it has evaluated its strongest neighbours.
Most other Zigbee Router products will however automatically change their connection once every 24 hours or more after it has evaluated its strongest neighbours.
Thank you Hedda for your elaboration. I was assuming that the SONOFF DONGLE-E_R used as router would make faster pairing possible than my BlitzWolf SHP-13 Energy Sockets/Meters.The SONOFF DONGLE-E_R has now paired itself into the mesh - 15 hours later - and has already made some connections.
Still not sure about the LQI / RSSI (not showing) for the majority of devices in my mesh. For now I’ll let the ZHA mesh do its thing and check it everyday or so.
Next time I pair a device I’ll have more patience.
@Arc8dium ,
did you able to recover from firmware 7.X.X?
also try to downgrade to 6.10.3,
but after firmware flush the device stop to respond,
try again to flush with the bootloader mode,
but nothing help.
with the ezsp utility getting this messege:
python3 Elelabs_EzspFwUtility.py probe -p /dev/ttyACM1
2022/10/27 10:39:26 Elelabs_EzspFwUtility: Couldn't communicate with the adapter in Zigbee (EZSP) mode, Thread (Spinel) mode or bootloader mode
After that push enter then you will see a text in the console.
Enter 1 then click “File transfer” at the top → Xmodem → send
It is important that you push 1 and then you will see: CCCCCCC
While you see this you have to start the file transfer.
After that extraputty uploads the firmware and after finishing you have to push 2 → it goes to paring mode.
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.
