Quirks V2 (ZHA Device Handlers version 2) RFC discussion

[Hedda]

@pipiche38 just a heads up that this project's developers might also be interested in participating and giving your feedback or input in this discussion about changing how the ZHA-quirks library should work in the future:

zigpy/zigpy#1312

also tried raising interest here but easy to miss for other projects and non-ZHA developers:

zigpy/zha-device-handlers#2882

and here:

home-assistant/architecture#1032

as well as here:

https://community.home-assistant.io/t/zha-device-handlers-version-2-zha-quirks-v2-architectural-design-developer-discussion/666460

FYI, just want to raise awareness to any ZHA Device Handler (a.k.a. quirk) developers and projects depending on the zha-quirks library that you might be interested in following this architectural proposal and developers discussion about changing how to decouple entities exposed in the ZHA integration from underlying zigpy devices, clusters, and endpoints to make it easier to develop quirks as ZHA Device Handlers.

Summary; the discussion includes a new API concept that will allow ZHA-quirks developers to add support for a new device that uses non-standard Zigbee clusters and attributes without having to both create a quirk and modify both the codebase of the ZHA component in the Home Assistant code. The proposed idea was raised now by puddly with a suggestion on how to make quirks easier and less complicated to create and edit by new ZHA-quirks developers.

[pipiche38]

@Hedda thanks for your post, for now it is not in our focus, and due to zigpy issues we have downgraded zigpy to the version before the watchdog refactoring which is creating issues on conbee, ezsp and znp.