Zigpy integration

[pipiche38]

Purpose is to track Zigpy integration issues and needs. All is under the branch zigpy

[pipiche38]

Focus will be on integration of
zigpy-zigate
zigpy-znp

Integration will be done at low level in order to have all events Zigbee events received and handle by the plugin. Purpose is to rely on the abstract layer given by zigpy- but not more.

Unfortunately from the current investigation zigpy- depends on zigpy packages, which is a shame as a lot of modules has to be loaded for the low level.

It will be the purpose of the integration work/test to define if we can use the zigpy- as such or a fork will be required to remove the zigpy dependencies (or get zigpy team removing the dependency).

[pipiche38]

In order to get a smooth integration, it might be important that we normalize the format of the incoming raw messages

[pipiche38]

@badzz , in mrequest() sequence is an expected parameter which is not used in the raw_aps_data_request(), for ZNP it seems that the sequence called TSN is expected, does that mean that we have to have a dedicated counter/sqn ?

[pipiche38]

Confirmed with @badzz the integration will go up to the /zigbee/application.py module which provide a much tight integration of the radio module in the stack.

the integration will rely on the handle_message() and the request() and mrequest() methods.

We have a number of missing informations like is the device in permit mode or not ? How to send specific device command with that integration as the request() mrequest() are only for the Zigbee part, but not for device specific commands.

[omerk]

@pipiche38 good luck with the project, if you (or any other developers) need any hardware, @electrolama would be happy to ship some zzh sticks free of charge to help out. Get in touch via [email protected].

[pipiche38]

@omerk thanks very much , I know that one has already ordered a zzh stick. Don't know if you can do something for him ( @badzz)

[Hedda]

Wish you guys the best of luck! FYI, I posted a heads up in zigpy discussions for reference to their developers -> zigpy/zigpy#865

A tip for later if future bellows integration is of interest then contact Elelabs for adapter sample hardware -> https://elelabs.com

By the way, Elelabs currently has Zigbee USB and Shield adapters based on Silabs EFR32MG13 but plan on releasing EFR32MG21 (as well as EFR32MG24) based adapter too as soon as the current worldwide chip shortage gets sorted out for Silicon Labs.

In order to get a smooth integration, it might be important that we normalize the format of the incoming raw messages

Read that zigpy is being refactored to provide ZDO events so could one possible workaround be to translate/convert incoming ZDO commands into zigate commands for those not handled natively as suggested by Adminiuga in this PR -> zigpy/zigpy#855 and being worked on for znp by puddly in zigpy/zigpy-znp#109

[pipiche38]

A tip for later is if future bellows integration will also be of interest then contact Elelabs for sample hardware -> https://elelabs.com

For now, will focus on electrolama and zigate

[pipiche38]

#889
#890
#891
#892

[pipiche38]

@badzz :
#896
#898
#899

[pipiche38]

#905
#904

[Hedda]

Would it not be a good idea to also track issues in/with zigpy-zigate in upstream? -> https://github.com/zigpy/zigpy-zigate/issues

Alternatively could to fork https://github.com/zigpy/zigpy-zigate to instead track zigpy-zigate issues in issues tracker in that fork?

[pipiche38]

Would it not be a good idea to also track issues in/with zigpy-zigate in upstream? -> https://github.com/zigpy/zigpy-zigate/issues

we have made a fork of the zigpy-zigate and will continue to work on that one.
and as it is related to our integration work, we will continue here

[Hedda]

Suggest change the repo's "About" so don't specifically say is only for "CC253x" when newer "CC2x52/CC1x52" should be prefered.

https://github.com/pipiche38/Domoticz-znp/

Noted this "Domoticz plugin which communicate with TI CC253X ..." in the "About" description that new znp repo.

Highly recommend adding a warning or at least a note that Texas Instruments CC2530 and CC2531 are not recommended for znp.

Instead, all new developers/users should really use CC2652 (CC2652P/CC2652R/CC2652RB) or CC1352 (CC1352P) based adapters:

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/Z-Stack_3.x.0/bin/README.md

Best is to use recommendations by Zigbee2MQTT as reference -> https://www.zigbee2mqtt.io/guide/adapters/#recommended

Short summary why not use TI's CC2530 and CC2531:

• CC2530 and CC2531 uses old chips with slow obsolete MCU and too little RAM and storage to run a modern Zigbee stack.
  • CC2530/CC2531 with Z-Stack 3.0.x firmware should only for development and testing network with less than 20 devices.
• CC2530 and CC2531 officially only support older Z-Stack Home 1.2 firmware which has been abandoned by TI for many years.
  • Z-Stack Home 1.2 firmware do not support Zigbee 3.0 specification (devices need to use backwards compatibility mode).
• The unofficial Z-Stack 3.0.x firmware for CC2530 and CC2531 is based on older version which no longer receives updates.

Please see more extensive reasons and arguments against recommending CC2530/CC2531 here -> zigpy/zigpy-znp#115

Personally, I don't either recommend CC2538 either which is end-of-life and have now not seen firmware updates for over 3-years.

Tip! Also highly recommend all new developers/users should upgrade firmware to very latest master before use any adapter.

https://github.com/Koenkk/Z-Stack-firmware/blob/master/coordinator/README.md

So regardless it is recommended to upgrade to the latest Z-Stack coordinator firmware from Koenkk's master or develop branch:

https://github.com/Koenkk/Z-Stack-firmware/tree/master/coordinator

https://github.com/Koenkk/Z-Stack-firmware/tree/develop/coordinator

PS: With the lower price of CC2652P/CC2652R/CC2652RB there is no reason why old CC2530/CC2531 adapters should be used:

https://www.ti.com/wireless-connectivity/zigbee/products.html#p1241=Wireless%20MCU

[Hedda]

I don't understand all of this communication from @Hedda, if you are against what we are currently doing, tell us frankly , but so far the zigpy-zigate library is stuck and not maintained. So it is unbelievable to read such messages !

Just to be clear; I am not against what you are doing at all. I am not against it in any way. I am very much a fan of what you are trying to achieve and think all that you guys are doing is a good thing. I think that it is great more projects are trying to use zigpy.

I was just trying to inform others what it means by a fork as do not think that was made clear when the pull requests were closed.

Personally, I understand why you forked and understand that it will hopefully not be your long term goal but something that has to be done in order to speed up the development process and part of the normal everyday development process.

So, me being frank; I really LOVE what you have been doing with your project and I do wish that you will continue using zigpy in it.

I also do hope that you at some point get to having a stable version of zigpy-zigate in it too, no matter if it is a fork of it or not.

@pipiche38 Again I am sorry for the misunderstanding. I am not a native English speaker and I believe that neither are you(?)..

PS: I think if you would re-read my posts and remember they were not posted as something bad then they read very differently. As again, my posts was not aimed towards or against you but instead aimed towards other people reporting about zigpy-zigate issues.

In the end if more support for different hardware /system then better for all parts and our community.

+1 The more projects using zigpy and the more developers/users using hardware with different Zigbee stack the better for us all.

[pipiche38]

@Hedda thanks for your message, you are right , not native language doesn't help.

For your information, I have pointed a previous Domoticz Zigate user whom have switch to HA and who is not happy of the level of integration of the Zigate. He will try to play and test the current fork that we have . Hope he will get some help and support to set it up on his environment

[zigbeefordomoticz]

We have release on beta6 branch and open the plugin to non Zigate coordinators. This leave TI CCxxx coordinators to be handle via the plugin.