Repository navigation
Replies: 7 comments 3 replies
|
This concept should be very powerfull if combine with PoE (Power-over-Ethernet), especially with PoE solutions like Unifi Long-Range PoE: UniFi Long-Range Switching by Ubiquiti support delivering power and data over a single Ethernet cable up to 800 meters for 100Mbps PoE: |
|
Just exploring this at a high level, since it triggered my curiosity it looks to be handled entirely in the mg24 firmware: Instead of letting the Silicon Labs EmberZNet stack handle the routing over the air between the Master and Remote, the firmware intercepts the raw 802.15.4 MAC data packets (MAC Protocol Data Units or MPDUs) right as they come out of or go into the radio hardware.
|
|
ZREL sounds a lot like Thread's TREL, which I think is the inspiration. I wonder if they'll open source it? TREL tunnels raw frames over UDP, I wonder why this uses TCP, which adds latency, retries, etc. I'm curious to see how it works. |
|
I think of it like one raw 802.15.4 tunnel over eth with little added for the no standard Zigbee frames implementation. |
@Tarik2142 would you consider open sourcing the implementation and/or protocol that ZREL uses to implement Zigbee Router tunneling? I might benefit the smart home community open specifications for such a protocol and possible even made into open standard someday. Specifically it could be interesting to make a fully open-source implemetation of something like that in ESPHome for the Ziggurat stack. PS: If you do then if possible consider licensing it under MIT or Apache-2.0 license so fully compatible with both without any restrictions. |
ZREL likley work below the Zigbee layer without its knowledge, so the Zigbee network can not tell the frame over IP hop from a radio hop. Could they also be making use of ZEP (Zigbee Encapsulation Protocol) to carry Zigbee / IEEE 802.15.4 raw frames between their routers?
ZEP was not purposly designed to be used in tunnelling product like this, but it is an established wire format for payload and could in theory be used to tunnel raw frames over UDP (similar to how LwIP 6LowPAN stack use it). ZEP looks however to be designed for encapsulating Zigbee and IEEE 802.15.4 packets for transport over IP networks. "ZEP wraps IEEE 802.15.4/ZigBee frames in an IP transport packet, adding encapsulation metadata such as protocol version, packet type, channel or device information, sequence data, and payload length. It is generally used without a session-oriented handshake, with UDP providing the usual low-overhead transport; the IANA assignment also covers TCP. ZEP is an encapsulation format rather than a replacement for Zigbee security, and the encapsulated traffic is not encrypted by ZEP itself." ZEP is at least on open ZREL-style implementation within the Zigbee spec, so maybe it could be reused instead of inventing a new format? There is an Exegin Q51 IEEE/802.15.4 ZigBee Transceiver (hardware sniffer for Wireshark), which captures and forwards radio traffic over a TCP/IP connection. "Exegin's plugins for 802.15.4, 6LoWPAN, Zigbee 2006, Zigbee PRO, and the Zigbee Cluster Library have been donated to the Wireshark project and could be used with any capture device. Interested parties (such as dongle vendors) are encouraged to write a supportive interface." Maybe look at that example how Exegin's plugins and firmware uses ZEP for its Q51 sniffer to forwarded captured radio traffic over TCP/IP. Description says it "wraps each 802.15.4 frame in UDP on port 17754."RIOT OS has also used it as a network device that carries 802.15.4 frames over UDP, in a form Wireshark can parse."? There is also IEEE 802.15.4 Wireshark USB Stick with Zigbee sniffer firmware available from Ubisys with special firmware made for Wireshark sniffing which performs ZEPv2 encapsulation over Microsoft's RNDIS protocol. -> https://www.ubisys.de/en/products/for-zigbee-product-developers/wireshark-usb-stick/ ZREL also share similarites with KillerBee wormhole attacks for Zigbee, which kind of sound like a hostile version of the same mechanism. In those an ttacker tunnels frames between distant parts of a network over an in-band or out-of-band channel, so far-apart nodes appear to be neighbours. One variant uses two malicious nodes that share a link, and a 2019 paper demonstrated an attack on XBee S2C Zigbee hardware using the KillerBee framework. So in effect, ZREL could be describedis a benign wormhole that you install on purpose. -> https://doaj.org/article/7822e8519d024273832106db3ebdb311 -> https://typeset.io/pdf/centralized-routing-protocol-for-detecting-wormhole-attacks-115iup9pjk.pdf Otherwise ZREL concept look to have similarites with TREL -> https://openthread.io/releases/thread-reference-20230706/group/api-trel
The same relay-and-retransmit pattern also exists in LoRa mesh projects. donglora-bridge sends packets that one radio hears over the internet to other bridges, whose radios retransmit them locally, forming a single mesh over a wider area. See example donglora-bridge which uses peer-to-peer bridges that connects LoRa radios to the internet so packets heard by one radio can be retransmitted by another radio anywhere in the world -> https://github.com/donglora/bridge PS: FYI, Apparently ISA100.11a backbone routers did something similar in industrial 802.15.4 networks. The backbone router is a device type the ISA100.11a standard introduced. Backbone routers bridge multiple 802.15.4 subnets and can run in parallel to form one very large network, over a backbone such as industrial Ethernet or Wi-Fi. Unlike ZREL, routing between subnets happened at the IPv6 layer -> https://www.controleng.com/industrial-wireless-field-device-mesh-network-101/ |
|
For reference and FIY, @vsychov is one more developer called who is working on another similar concept with Zigbee frame transfer over IP:
|
|
Yeah, this idea is a really low-hanging fruit. I won't get surprised if CSA would add ZigBee encapsulation (similar to TREL) in the upcoming versions of the standard. Would be cool if the community can assemble and propose a single protocol for ZB encapsulation, to avoid an N+1 incompatible solutions. Unfortunately seems like SMLight's ZREL is proprietary and based on TCP protocol (IMO bad idea) |
@puddly is that something that the Open Home Foundation have enough influence to lobby to the Connectivity Standards Alliance? It should the best long-term outcome if the CSA (which was formelly the Zigbee Alliance) could as a standard specification for Zigbee. I read the Open Home Foundation is a member of CSA now so might at least have a little clout among the engineers at the CSA(?): Home Assistant's articles about CSA officially certifiying the Matter implementation mentions open standards importance to OHF: |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Indirectly related to this previous request for Zigbee Router mode/role support in Ziggurat -> #27
FYI, SMLlight has just announced this new "ZREL" (ZREL-MG24) product which is their own implementation of Zigbee Ethernet router:
https://smlight.tech/products/zrel
"ZREL is a Zigbee Ethernet router. You get two units that talk to each other over your Ethernet cable. Put one unit (the Master) next to your Zigbee coordinator, and the other (the Remote) wherever your Zigbee signal does not reach: the garage, the top floor, another building. The Zigbee devices there join the network you already have, with the same coordinator and the same app. No second network, no new setup. One mesh across all areas · works with ZHA and Zigbee2MQTT · PoE or USB-C power"
https://smlight.tech/articles/introducing-zrel
"Each ZREL Master sits next to your Zigbee coordinator. Through the Ethernet switch of your home network it reaches its ZREL Remote in a far room or another building, and the Remote covers that area with Zigbee. End devices there join the same Zigbee network as everything else. Switch the house to Without ZREL to see what the coordinator reaches on its own."
Could something like that be implemented in the Ziggurat stack if it would first gain full Zigbee Router feature-set?
That is, have a set of syncronized Zigbee Router devices based on Ziggurat where one capture the traffic and forward it via serial communcation to the other device using serial (using for example ESPHome) over IP using Ethernet media for lowest possible latency?
As far I could find, ZREL as the first product/device to carry raw Zigbee radio traffic over Ethernet to allow a remote Zigbee Router over IP.
Perhaps aks is SMLight would be willing to release the full source code for their implementation under a a non-restrictive FLOSS license?
There currently looks to be no ZREL related repo in the smlight-tech org on GitHub -> https://github.com/smlight-tech
For reference, there is a related Zigbee2MQTT discussion about it here but that looks more to be a device handler (quirk) request for Z2M:
PS: On paper concept sounds in theory kind of like a variant of the old "Z/IP Gateway" (ZIP Gateway) which stands for Z-Wave over IP Gateway which I believe also had a feature to provide a Zwave repeater device providing a layer above the serial API:
All reactions