Generally wondering about future of ZiGate native mode implementation versus a zigpy-zigate radio implementation in the ZigBee for Domoticz plugin?

[Hedda]

Curious about ZigBeeForDomoticz plugin general status of native mode ZiGate implementation versus a future zigpy-zigate implementation.

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

Noticed that the zigpy-zigate implemnetation has been disabled/removed in ZigBee For Domoticz plugin:

#1555

Are other zigpy radio libraries working well compared to original native mode ZiGate implementation that the ZigBee For Domoticz still use?

https://github.com/zigpy/zigpy

https://github.com/zigpy/zha-device-handlers

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

https://github.com/zigpy/open-coordinator-backup

https://github.com/mdeweerd/zha-toolkit/

Thinking that it would, in the long run, be better for all projects that uses zigpy-zigate if the igBee For Domoticz plugin could use it too.

Assuming there would be synergy effects if and when could ZigBee For Domoticz plugin could consolidate all radios to all use zigpy API.

Do you think zigpy-zigate could/will ever get to feature parity between native mode ZiGate implementation? What is zigpy-zigate missing?

Are you any closer to considering migrating from native mode ZiGate implementation to the zigpy-zigate radio library for zigpy or given up?

Anything you or Domoticz and ZiGate communities could do to bring zigpy-zigate radio library in feature parity with native mode ZiGate?

Do you have influence on Fairesoimeme / ZiGate developer to make him help actively develop functions/features missing for zigpy-zigate?

Could we ever get to a point where zigpy could be the one and only unified radio API that rules them all in the ZigBee For Domoticz plugin?

PS: Disclaimer; I am not actually a user of ZigBee For Domoticz plugin myself (however know a few other people who are), but I am generally a big fan and enthusiastic of the hardware and Zigbee stack abstraction concept that the zigpy project/organization offers, at least on paper.

[pipiche38]

@Hedda in order to get the Zigbee for Domoticz plugin using zigpy library for Zigate coordinator, the zigpy-zigate must be compliant with the flow-management. This is not the case for now.
In short zigpy-zigate request must not sent any command to the coordinator until

• the coordinator receive a 0x8011 that the command has been received by the target (in ACK mode)
• the coordinator receive a 0x8012 that the command has reached the next hop ( in case there is no ACK mode)

the code has been implemeted inour zigpy-zigate fork, happy to have someone taking it and making a PR (unfortunatly we have done that prior the new radio API)

SO from my perspective the work has to be done on zigpy side, not on the firmware not on the plugin.

[Hedda]

In short zigpy-zigate request must not sent any command to the coordinator until

• the coordinator receive a 0x8011 that the command has been received by the target (in ACK mode)
• the coordinator receive a 0x8012 that the command has reached the next hop ( in case there is no ACK mode)

the code has been implemeted inour zigpy-zigate fork, happy to have someone taking it and making a PR (unfortunatly we have done that prior the new radio API)

@pipiche38 Could you maybe create a new issue with that feature suggestion as an open request for public discussion and tracking? -> https://github.com/zigpy/zigpy-zigate/issues (might be a small chance that someone else with interest in this notice it there and take it on).

[pipiche38]

zigpy/zigpy-zigate#120