Closed pipiche38 closed 2 years ago
pipiche38
commented
2 years ago 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-
Unfortunately from the current investigation zigpy-
It will be the purpose of the integration work/test to define if we can use the zigpy-
pipiche38
commented
2 years ago In order to get a smooth integration, it might be important that we normalize the format of the incoming raw messages
pipiche38
commented
2 years ago @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
commented
2 years ago Confirmed with @badzz the integration will go up to the
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
commented
2 years ago @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 support@electrolama.com.
pipiche38
commented
2 years ago @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
commented
2 years ago Wish you guys the best of luck! FYI, I posted a heads up in zigpy discussions for reference to their developers -> https://github.com/zigpy/zigpy/discussions/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 -> https://github.com/zigpy/zigpy/pull/855 and being worked on for znp by puddly in https://github.com/zigpy/zigpy-znp/pull/109
pipiche38
commented
2 years ago 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
commented
2 years ago Hedda
commented
2 years ago 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
commented
2 years ago 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
commented
2 years ago 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:
Please see more extensive reasons and arguments against recommending CC2530/CC2531 here -> https://github.com/zigpy/zigpy-znp/issues/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
commented
2 years ago 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
commented
2 years ago @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
commented
2 years ago 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.
Purpose is to track Zigpy integration issues and needs. All is under the branch zigpy