[REQUEST] Zigbee Router application firmware based on EmberZNet SDK 6.7 or later? #8
Comments
|
@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. 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, |
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. |
|
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. 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 |
Always looking forward to hear all and any hopeful news about the future of EZSP support in Zigbee2MQTT! :) 👍 👍
+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/ |
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. |
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: Posting something about those other application that is not related to zigpy or ZHA is probably frowned upon if not seen as spam. |
|
The Principe its one Zigpy / ZHA forum but its little flexible but shall not going to much out of it. I think its better letting Gary have some silent time then hi is cooking nice hard firm software ;-)) |
|
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. There are also a couple bootloader options...
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" 👍 |
|
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. 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 ;-) |
|
@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... |
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 -> basilfx/TRADFRI-Hacking#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 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/
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 zigpy/zigpy#656 |
|
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 ! |
|
@ 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. |
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. 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). 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. |
FYI, kirovilya has started developing an adapter compatible with EZSP for zigbee-herdsman (used by Zigbee2MQTT and ioBroker): |
|
DSR ZBOSS Zigbee 3.0 split-stack solution running upper layers on host processor and Zigbee MAC on EFR32 radio. Looks Amazon is using EFR32 RCP (likely one MG12) and doing the ZBOSS in the host system. |
@MattWestb Probably off-topic here since in this issue (#8) not based on EmberZNet SDK? Btw, FYI, ZBOSS also runs then Zigbee stack in RCP mode on ESP32-H2 and ESP32-C6 -> zigpy/zigpy#783 |
Follow-up to EmberZNet Zigbee Router application firmware from #2
@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 -> zigpy/zigpy#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.
The text was updated successfully, but these errors were encountered: