deCONZ - Remove mechanisms to import a configuration from configuration.yaml

[Kane610]

Breaking Change:

With Home Assistant releases 0.100 and 0.101 deCONZ will end support of importing configurations from configuration.yaml

In 0.100, deCONZ will ignore what is in the deconz:
In 0.101, deCONZ will fail on config validation and not allow the deconz section to exist in configuration.yaml.

TL;DR This will no longer work:

deconz:

Description:

Remove import mechanism of configuration.yaml, but allow deconz: to exist

Checklist:

• The code change is tested and works locally.
• Local tests pass with tox. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist

[MartinHjelmare]

Removing support for config yaml goes against what home assistant is saying to users.

Config yaml is not going away.

I think this should be discussed further. CC @balloob

[Kane610]

This is the same thing as the unifi component we discussed a few days ago @MartinHjelmare. Of course config yaml isn't going away. But it is up to each integration how it is configured.

[MartinHjelmare]

I don't think it can be up to each integration since home assistant is saying config yaml won't go away. Those two ways are not compatible.

I think we should write an ADR and make it clear what the requirements are for config ways when structuring integrations.

My suggestion is that we require both config yaml and config flow for new integrations. And we don't allow removing either config yaml or config flow as a way of config for existing integrations.

Whatever the outcome is, I hope we make it more clear than today what the expectations for integrations are for users, for contributors and for organization members.

[Kane610]

There are multiple integrations that only allow configuration through gui; met, ps4, SMHI (axis, deconz and unifi soon as well)

Nothing wrong with clearer guidelines but allowing integrations not having a configuration.yaml path is not the same as saying that configuration.yaml is going away

For me personally I only want to support one path, the path that easily can be modified when new features arrive. Supporting configuration.yaml is far too static and limits evolution

[Kane610]

I forgot to mention that I removed any references to configuration.yaml in deCONZ integration documentation nearly a year ago.