dumpfheimer framework for generic exposure of device configuration attributes about zha-toolkit

[mdeweerd]

The framework looks a bit more heavier than zha-toolkit and would require updating zha-toolkit with the vscode setup if it would "take it all".

zha-toolkit is in nature a stop-gap : features that can be easily actionned.

zha-toolkit already has a feature to expose attributes using the read-attributes features that some users call regularly in an automation and let it fill a state or state attribute.

The dumpfheimer framework exposes this more easily in the UI.

I do not know yet if there is a good middle way. It would be easier to integrate zha-toolkit in the dumpfheimer framework, but then we can also state that zha-toolkit can be integrated in zha. The problem is that zha is stricter on methodology and stability than zha-toolkit, and a toolkit in nature has to be capable of evolving fast.

So based on my quick analysis, I would think that the dumpfheimer framework can very well be a component of its own with sufficient stability and for less technical users than those that use zha-toolkit (even if only mildly technical users use it).

Over time, the framework is something that better goes directly in zha once it has the stability and quality required.

As far as zha-toolkit goes: features from it can also be integrated in zha, but it has to stay independant from zha to quickly respond to hackerisch implementations like tuya's magic spell, and make it easier for a user to hack by himself without resorting to complex techniques to modify HA's core components which zha is.

The dumpfheimer framework could benefit from proposing features to allow the user to extend it without modifying the "component" itself, similar to zha-quirks.