Implement configuration flow

[mdeweerd]

Add an UI configuration flow which will make it easier to enable the toolkit (and disable/enable it dynamically).

The configuration flow could also lead to some globel defaults for:

• event_fail, event_done, event_success: set a default event name applied to all services (which can be set on a per service call basis);
• backup name format;
• ... .

See https://github.com/home-assistant/architecture/blob/master/adr/0007-integration-config-yaml-structure.md for more information.

[Hedda]

Long-term might it make sense to moves some parts of zha-toolkit usages into the zhaws addon that dmulcahey is working on?

I guess the long-term plan is to split the ZHA integration frontend from backend/server as per client-server model architecture (similar to how the Z-Wave JS integrated for HA is already modular with UI frontend in HA core, HA addon, server, and driver):

https://github.com/zigpy/zhaws-addon

https://github.com/zigpy/zha-websocket-server

https://github.com/dmulcahey/home-assistant/tree/dm/zha-ws

PS: For reference, dmulcahey mentioned in https://github.com/zigpy/bellows/issues/449 that might for ex. make sense to put flashing utilities into zhaws.

[mdeweerd]

"zha_toolkit" is essentially a "toolkit", and even with "zhaws" there is a need to have some kind of ui/HA services to call zhaws itself - in other words, how are you going to call a web service?

Of course a web service probably enables the use of it outside HA, and zigpy can be run standalone already today (without HA).

From HA's point of view one could say that ZHA is just another integration alongside zwave, esphome, tuya, etc . I think HA's interest is mainly to support as many protocols as needed in a way that is "good enough", but the core team (that is paid) can"t spend time on the details of each protocol as this is not in line with Casa Nova's implicit goals (make a living).
So they probably will not add the low level, exotic and potentialy breaking feature that we find in zha_toolkit.

Another thing of the toolkit is that I (and others if they want to) can modify it live and release a new function over night (or keep it private). That's not compatible with requirements for official integrations.
My personnal toolkit (which includes zha-toolkit) grows every day as I craft new tools every day some of which may one day become reusable and others not. In zha_custom there were several commands with a precise IEEE address - showing that it was more a personal toolkit of their developers than a general one.

I did not look at zhaws, but there should be a 'zhawc' and a 'zigpyws', i.e. a web service client in HA and a zigpy web service.

Anyway, that's not the topic of this "Issue" that intends to make setting up zha-toolkit easier:

• Avoiding to have to manually edit configuration.yaml (main goal);
• Providing enable/disable functionnality that can help reload zha-toolkit when needed;
• Set the debug level for zha_toolkit;
• Default output directory;
• Default local scripts directory;
• Options for event data;
• Other configurations that I do not think about.

[Hedda]

Add an UI configuration flow which will make it easier to enable the toolkit (and disable/enable it dynamically).

Any updates on adding a Config Flow with config flow handler for UI configuration and maintainence of zha-toolkit?

https://developers.home-assistant.io/docs/config_entries_config_flow_handler/

https://developers.home-assistant.io/docs/config_entries_index/

https://aarongodfrey.dev/home%20automation/building_a_home_assistant_custom_component_part_3/

PS: Assume will keep it available via (HACS (Home Assistant Community Store)) to get advanced users to test it first?

[mdeweerd]

@Hedda I have quite a few things to do and this is not on the top of my list, but something that I guess could be done with somebody with less knowledge about zigbee, but already some experience with the configuration flow. The thing is that this is not a very appealing task. Users that can code generally submit code that fixes a problem they have, not something that improves the user experience only for other users as they already are past the configuration step which is just adding a line to configuration.yaml and restarting HA (once the component was added using HACS, which is always a thing to do).

That's the thing with open source: as developer we're motivated/kind enough to make the code available, make it even sufficiently generic, and we then also become responsible to maintain and provide support for it. Sometimes someone comes along that has his motivations to invest more time in it. The other way is that the contributor has made a business on top of the open-source motivating enough to get other customers by attending to these things.

I had an open-source in the past that had easily 200 downloads each day and I made a method available to make donations as some users requested me to. That raised around 60 EUR per year covering barely the hosting costs. I rewrote that to another language/framework because companies were asking for it and I had created my company in the mean time and I sold it as a library - I sold it 4 or 5 times, one of them triggered a job to make an application around it and my efforts to rewrite it were paid (but not my efforts if I include the time I spent on the open source).

This is open-source as in "free open source". I appreciate people like you contributing within the scope of their competences, and it would be nice if there could be more users like it: just reviewing and improving the documentation of open-source projects related to an issue they had in understanding the project would already be great!