[REQUEST] Zigbee Router application firmware based on EmberZNet SDK 6.7 or later?

[Hedda]

Follow-up to EmberZNet Zigbee Router application firmware from https://github.com/grobasoz/zigbee-firmware/issues/2

@grobasoz Might also be nice idea to offer a Zigbee router firmware as an option, similar to request in https://github.com/tube0013/zb_ebyte_eth/issues/1

It would be very nice to have a few EFR32MG21 based Zigbee routers as Zigbee network mesh extender (a.ka. Zigbee signal repeater)

That would be an excuse for some of us to buy several devices too ;)

@Hedda - It's on my list 😎 Actually just a USB-Zigbee in Router mode! But right now I have to work on Thread based firmware for a customer 😒

@grobasoz FYI, @tube0013 revealed a couple of days ago that he is working on a Zigbee Router based on an a Texas Instruments CC2652P (+20dBa power amplified) module as open source hardware, you can read about that here -> https://github.com/zigpy/zigpy/discussions/664

I suggested he make a EmberZNet Zigbee Router variant with that design as well but he answered that he currently has no plans to do so himself at this time.

I don't think I'm going to look at an efr32mg equivalent to this router design though, the module availability and options are not abundant on that side.

@tube0013 FYI, if you are looking to buy modules as surface mounted components to make and sell boards then know that MGM210P (and MGM210L) RF modules by Silicon Labs that contains EFR32MG21 and are also available.

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules

https://www.silabs.com/documents/public/data-sheets/mgm210l-datasheet.pdf

https://www.silabs.com/documents/public/data-sheets/mgm210p-datasheet.pdf

MGM210PA32JIA and MGM210PB32JIA are both is a +20 dBm TX pre-certified module based module with both built-in antenna and RF Pin for optional external antenna.

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules/device.mgm210pa32jia

https://www.silabs.com/wireless/zigbee/efr32mg21-series-2-modules/device.mgm210pb32jia

The differnce between those two is that MGM210PB32JIA also have support for features Silicon Labs' enhanced security option, "Secure Vault" https://www.silabs.com/security

MGM210PA32JIA and MGM210PB32JIA looks to cost about $11 (US) dollars each when not buying in bulk

https://octopart.com/click/track?ai=1872&sig=02b5980&sid=459&ppid=108099587&vpid=615228293&ct=offers

https://octopart.com/click/track?ai=1872&sig=045aafa&sid=2401&ppid=108099587&vpid=618359838&ct=offers

https://octopart.com/click/track?c=1&ai=1872&sig=0881c5f&sid=459&ppid=112348737&vpid=667261090&ct=offers

https://octopart.com/click/track?ai=1872&sig=09e2041&sid=819&ppid=112348737&vpid=692111326&ct=offers

[grobasoz]

@Hedda - Thanks for the information. I have MGM21 modules here and have been using them for a while now for certain (commercial) customers. They are quite expensive but useful as they are fully certified and support uFL and chip antennae. They are also nice and small. The uFL part needs an external antenna which can also be expensive. The chip antenna module needs a large ground plane to work effectively - no good for USB sticks.

Now the next issue. I have done a small production run of 500 Zigbee modules, with USBA-TTL for USB Sticks and USB-Micro-TTL for cable based devices. Due to the low volume, they cost quite a lot to make - so can't really compete on the open market. However I can sell them locally (Australia and New Zealand) for a small profit as prices of Zigbee products here are very high!

MGM21 modules adds another few $ to the mix as well as a difficulty sourcing them currently.

So I'm currently leaving the supply of USB-Zigbee devices to developers/companies who have greater buying power than me... like Itead :)

I am working on Zigbee2MQTT for my radio modules (EFR32) and have been using Home Assistant for testing - apart from spending time making firmware for certain people :D

I was contacted last year by Elelabs to supply them with my products but they seems to have "disappeared"? So I would still need to build and manage some sort of store-front to sell the products - not a lot of spare time at this stage (many 'paying' projects on the go)...

Anyway - I will keep posting information on the hardware on my github repository as I get sections of the code and documentation complete - and if Mattias leaves me alone :s

Regards, Gary.

[Hedda]

So I'm currently leaving the supply of USB-Zigbee devices to developers/companies who have greater buying power than me... like Itead :)

I was contacted last year by Elelabs to supply them with my products but they seems to have "disappeared"? So I would still need to build and manage some sort of store-front to sell the products - not a lot of spare time at this stage (many 'paying' projects on the go).

Cool, though if you are ever interested a trying to partner with such types of Chinense companies then suggest that you consider reaching out to several different companies to discuss partnership agangements where they would be producing your products and/or paying for products development services for a procentage on each device sold or something. Such concepts might very well work with medium-sized Chinese companies like Itead, Nedis, Zemismart, etc. if you pitch them specific product ideas for more than of Zigbee product.

I know many of those companies have just recently begun to established themselves in North America and the European Union. Most currently look to be mostly be producing WiFi/ESP8266-based products and appear to produce mostly niche home automation products and presumably have both thefinancial backing plus the man-power to do so but IMHO really seem to lack inovation ideas and full-stack developers/engineers to create Zigbee based products.

Regardless, I think such companies already do have a lot of great devices in their WiFi-series could do with more Zigbee products and it should also be worth converting their existing succcessful WiFi/ESP8266-based products products into Zigbee variants. I know that I for am are not very interested in products that do not use either Zigbee or Z-Wave.

[MattWestb]

Its looks like Elelabs have being silent for some time. ZHA devs have not getting any updated firmware for the dev modules (that was promised from the company) and have cooking own firmware for them.

To the "antenna problems". All PCB antennas and also external one is needing one god ground plane for working god. One bad example is the IKEA outlet that have the standard module with on god chip and PCB antenna but have putting one large capacitor very near / behind the PCB antenna that is dirtying the configuration and degrading its function.

I think i dont need explaining it for Gary then hi have enough knowledge and experience of the "RF-Magics" and Zigbee is nearly in the radar spectrum and its some time little tricky for working well.

The "supplying products" is not easy to do then Itead and other companies if "flooding" the market. I hope you is getting enough orders for your hard and software solutions and god customer that keep you busy and paying you well for your work and not only cooking impossible firmware for "no paying persons" ! !

If you need help testing EZSP for Z2M i can helping you with my small test system (Billy EZSP and co).

And im very thankful for your support but you must prioritizing your self before the not paying community problems but im very glad for all the time you is spending for the community.

An you can without problem ignoring my stupid requests if you dont have time then i knowing your situation and for my its "Gary (as person) first" and i dont taking it personal its only true world realistic.

You can also posting interesting soft and hardware things on Zigpy discussions so tube13 is not being alone on the hardware part.

Mvh Mattias

[Hedda]

I am working on Zigbee2MQTT for my radio modules (EFR32)

Always looking forward to hear all and any hopeful news about the future of EZSP support in Zigbee2MQTT! :) 👍 👍

You can also posting interesting soft and hardware things on Zigpy discussions so tube13 is not being alone on the hardware

+1 Yes please do post in https://github.com/zigpy/zigpy/discussions if want testing or brainstorm Zigbee stuff usable with zigpy :D

PS: Jeedom developers are working on a new Zigbee plugin (beta) based on zigpy so Home Assistant ZHA won't be using it alone.

PPS: Also remember that OpenHAB also have its own support for Zigbee -> https://www.openhab.org/addons/bindings/zigbee/

[MattWestb]

+1 Yes please do post in https://github.com/zigpy/zigpy/discussions if want testing or brainstorm Zigbee stuff usable with zigpy :D

Its not only for Zigpy / ZHA, more or less all SW and HW is welcome there but not very likely black talking/writing de(f)CONZ or other bad things.

I think its also good for the devs getting little in and output, even all is not so constructive but much better then open new issues in different gits.

I have giving some "ZHA family cards" to nice hardware that "some" user have made. Perhaps its coming one "ZHA family card" for some one in the near future in the category "EZSP firmware cooking" ;-))

[Hedda]

+1 Yes please do post in https://github.com/zigpy/zigpy/discussions if want testing or brainstorm Zigbee stuff usable with zigpy :D

Its not only for Zigpy / ZHA, more or less all SW and HW is welcome there but not very likely black talking/writing de(f)CONZ or other bad things.

Well, Zigbee hardware and firmware yes, but probably not all Zigbee software unless it at least have some connection to zigpy?

Only the ZHA integration in Home Assistant and Zigbee plugin (beta) for Jeedom are based on zigpy which those disussions are for.

As all here know, Zigbee2MQTT and ioBroker are seperate projects dependent on zigbee-herdsman and have their own forums:

https://zigbee2mqtt.discourse.group/

https://forum.iobroker.net/category/16/english

Similarly, the OpenHAB software (which is dependent on com.zsmartsystems.zigbee) also have its own community forum:

https://community.openhab.org

Posting something about those other application that is not related to zigpy or ZHA is probably frowned upon if not seen as spam.

[MattWestb]

The Principe its one Zigpy / ZHA forum but its little flexible but shall not going to much out of it. One example is the famous "IKEA bug" that is in all Silab stacks until being fixed in 6.7.7.0 was pinpointed in deCONZ forum and also verified of the ZHA / Zigpy devs there.

I think its better letting Gary have some silent time then hi is cooking nice hard firm software ;-))

[grobasoz]

Thanks for the feedback.

I will post information in my repository for anyone who is interested.

Just to point out - I am not working on an EZSP version of EFR32 for Zigbee2MQTT. I mentioned some time ago that I don't like using EZSP... it does not go far enough to implement a low level Zigbee interface. Too much needs to be done in the Host application - this does not make sense. I prefer the TI ZNP approach, where some level of Zigbee management is handled in the module - so I have implemented a ZNP "compatible" API for host communications in the EFR32 (and EM358x). Due to Silicon Labs licensing however, I can't release this as open source software - but will keep the firmware updated as much as possible.

There are also a couple bootloader options...

1. The "standalone" bootloader (I call BTL_STD) like EZSP uses and allows XModem uploads.
2. The "application" bootloader (I call BTL_INT) that uses the device application and can support over the air (OTA) updates.

I prefer the latter (BTL_INT) as it means the firmware can be uploaded to flash without interfering with the functioning of the Zigbee device and supports OTA updates from a gateway - it also allows for me to implement a BLE based flashing interface so mobile phones can be used for OTA updates.

@MattWestb - Don't worry - I like the "communications" from "the North" 👍

[MattWestb]

You have the "blueprint" for nearly all EM35X and EFR32 devices used in the community only still locked Sonoff devices you cant cocking but its over 90% of the "market" that is not bad for one "Quala EM35X" and "Kangaroo EFR32" for Z2M.

Then My Billy can using the external EEPROM for storing the OTA file and flashing it without serial port connection but the Tuya need using xmodem then dont having enough storage for the OTA file and one running app in the flash.

I think Zigpy have doing one very large work to implanting the multi version protocol for EZSP in bellows but have getting great flexibility in the system but perhaps to the cost of complexity in the host application side. I like the cleanness in Zigpy that all shall being ZCL so all devices that doing on good implanting of ZCL is working out of the box and the quirk is "converting" things that is not following the standard so good. Its very opposite how deCONZ is working with its partly closed source code and need patching around 10 places in the code base for whitelisting one ZLL certified controlling device (and have messed most up then implanting ZHA devices).

The funny thing with all from downunder is that they is going with there feet upwards and the head downwards from "our" point of view but i like the mentality of the people there ;-)

[grobasoz]

@MattWestb - Some very good points and I agree with you totally - especially regarding deCONZ. I have their products here and have built my own EFR32 based deCONZ interface BUT deCONZ uses very "active" communications which I don't like... I started using ZigPy some time ago but wasn't happy with the performance - maybe I will try it again with ZHA and Home Assistant... The key for me is being able to manage the low level Zigbee network myself (ie in my Coordinator) so I can use cool things like Green Power and later on, Thread or Bluetooth... as well as led indication for status and network strength. Coffee time :)

[Hedda]

Just to point out - I am not working on an EZSP version of EFR32 for Zigbee2MQTT. I mentioned some time ago that I don't like using EZSP... it does not go far enough to implement a low level Zigbee interface. Too much needs to be done in the Host application - this does not make sense. I prefer the TI ZNP approach, where some level of Zigbee management is handled in the module - so I have implemented a ZNP "compatible" API for host communications in the EFR32 (and EM358x). Due to Silicon Labs licensing however, I can't release this as open source software - but will keep the firmware updated as much as possible.

hmm, so that would be a new unofficial API that requires a propritory closed source application firmware for EFR32. While I have no stake in the matter I personally do not like the idea of that. I can see huge risks that a such project failing if you would ever abandon it and also I believe a such project could mean way too much work. Also way too much work for very little gain as users can just buy real TI ZNP hardware instead.

If you are not going to switch to TI ZNP hardware then I think it would be probably better in the long run to be satisfied working with one of the existing CLI/API interfaces that the Silicon Labs officially provide or perhaps if you are really only looking for a challange then maybe attemt a try at porting a an open source Zigbee stack/application firmware like ZBOSS or ZiGate to run on ESP32.

benemorius mentioned here that got ZBOSS working in RIOT OS on ESP32 hardware -> https://github.com/basilfx/TRADFRI-Hacking/issues/28

https://zboss.dsr-wireless.com/

https://github.com/fairecasoimeme/ZiGate

Alternativly, maybe it could otherwise be possible to only add extensions for specific low level features? Have you looked at:

https://github.com/zsmartsystems/com.zsmartsystems.zigbee

I started using ZigPy some time ago but wasn't happy with the performance

I currently use Home Assistant's ZHA integration with zigpy-znp using a CC2652R coordinator (Electrolama Zig-a-zig-ah) and I am very happy with its performance, however I am considering upgrading to a CC2652P to get improved range and better RSSI/LQI. I am pretty sure that zigpy-znp also have code to control the LED. By the way, puddly have done a great job with zigpy-znp

https://github.com/zigpy/zigpy-znp/

...so I can use cool things like Green Power ...

FYI, zoic21 (lead developer of Jeedom) has now submitted a new pull request for regression testing review to zigpy which would add initial ZGP support for both bellows (EZSP) and zigpy-deconz (ConBee/Raspbee), check out https://github.com/zigpy/zigpy/pull/656

[MattWestb]

I thinking the best making one "origination" that is "maintaining" the source code and only inviting on not to large group to it so Silabs cant complaining its one "open" project. But i cant saying wot is possible or not then im not one US lawyer.

Bellows is not using all functions that Silabs have cooked in the EZSP and is doing some things with discreet low level commands instead for the "normal" integrated scrips that is recommended.

One Micro Python implantation that is in 2 level API one "ZCL" and one very low level for going down in the cellar and doing some magic ?

Im finding it very interesting wot Gary is coming out int he end with his lang and deep experience !

[grobasoz]

@ Hedda - Sorry - I wasn't very clear with my previous post - I use the ZNP API on my EFR32. So to implement Zigbee2MQTT, I just connect my device (as a "zstack" device) and it works... much like a TI CC2531 or CC2652...

Thanks for the excellent side notes and links - I don't have much spare time to look at what is out there but I'll certainly give the zigpy-znp a go. Regards, Gary.

[MattWestb]

@Hedda

I currently use Home Assistant's ZHA integration with zigpy-znp using a CC2652R coordinator (Electrolama Zig-a-zig-ah) and I am very happy with its performance, however I am considering upgrading to a CC2652P to get improved range and better RSSI/LQI.

If you is having one coordinator with one very good radio config and your devices (both routers and end devices) dont have so good or bad radios you is getting one deCONZ problem. = All devices is connecting the the coordinator and dont building one good working mesh network. And if the coordinator is offline you is getting problem with some devices (Xiaomi) that is leaving the network.

The best is have around the same radio "performance" for the routers so the end devices can using on god in its near.

Its the famous "the chain is not stronger then the weakest link".

Or you is building your system as one start network and loosing the benefit of one real mesh network.

One example of how zigbee is using the routers in the mesh network (all routers have OK signal paths to the coordinator but some not direct one = OK and most end devices have good routers in its near that they is using). "Vorzimmer plug" is having over 2 meters reinforced concrete in the direct path to the coordinator but is using better paths for talking with it ala Zigbee Mesh standard.

I is going so long as i thinking banning end devices using the coordinator as direct parent for getting the mesh working better in 24/7/365 config.

[Hedda]

@ Hedda - Sorry - I wasn't very clear with my previous post - I use the ZNP API on my EFR32. So to implement Zigbee2MQTT, I just connect my device (as a "zstack" device) and it works... much like a TI CC2531 or CC2652...

FYI, kirovilya has started developing an adapter compatible with EZSP for zigbee-herdsman (used by Zigbee2MQTT and ioBroker):

https://github.com/Koenkk/zigbee-herdsman/pull/317

[MattWestb]

DSR ZBOSS Zigbee 3.0 split-stack solution running upper layers on host processor and Zigbee MAC on EFR32 radio. https://csa-iot.org/csa_product/zigbee-3-0-platform-3/

Looks Amazon is using EFR32 RCP (likely one MG12) and doing the ZBOSS in the host system. So open for ZB3 and Thread / Matter i the host system.

[Hedda]

DSR ZBOSS Zigbee 3.0 split-stack solution running upper layers on host processor and Zigbee MAC on EFR32 radio. https://csa-iot.org/csa_product/zigbee-3-0-platform-3/

Looks Amazon is using EFR32 RCP (likely one MG12) and doing the ZBOSS in the host system. So open for ZB3 and Thread / Matter i the host system.

@MattWestb Probably off-topic here since in this issue (https://github.com/grobasoz/zigbee-firmware/issues/8) not based on EmberZNet SDK?

Btw, FYI, ZBOSS also runs then Zigbee stack in RCP mode on ESP32-H2 and ESP32-C6 -> https://github.com/zigpy/zigpy/discussions/783