Deprecate knx config_file#46874
Conversation
|
Hey there @Julius2342, @marvin-w, mind taking a look at this pull request as its been labeled with an integration ( |
| { | ||
| DOMAIN: vol.All( | ||
| # deprecated since 2021.3 | ||
| cv.deprecated(CONF_KNX_CONFIG, replacement_key=CONF_KNX_CONFIG), |
There was a problem hiding this comment.
The 'CONF_KNX_CONFIG' option is deprecated, please replace it with 'CONF_KNX_CONFIG'
This doesn't look right that the replacement_key is the same
There was a problem hiding this comment.
This doesn't really break things, it will fire a warning from the cv.deprecated config validator for now.
If I don't specify a replacement_key the config validator removes the key from config and it can not be used further down. This would result in users loosing some configuration like HomeKit room assignment (afaik).
So for now I'd like to just point out the deprecation of this config and log a link to the config-converter. After a transition period is over (maybe in summer) well remove the replacement_key and the logic using the XKNX-Schema.
I was more worried about the link to an external resource (config-converter tool) being accepted.
There was a problem hiding this comment.
would it be ok to also create a persistent_notification ?
There was a problem hiding this comment.
I'm not sure about an external link in a notification. I'll ask for a second opinion on that.
There was a problem hiding this comment.
If it is any help: xknx.io is also the only source for documentation of the deprecated XKNX-Schema - so users of this are probably familiar with this domain.
There was a problem hiding this comment.
Deprecated should not remove the key if you don't specify replacement. You have to explicitly remove it with a vol.Remove() if you want it removed.
There was a problem hiding this comment.
Also we don't generally do notifications on deprecated. If we want to do that i think we should do that globally.
There was a problem hiding this comment.
I've removed the deprecation config validator. It's a log normal log message and notification now. (Only when config_file is used).
Shall I remove the notification again? I think a log message can be quite invisible for users - and this change will probably render their whole installation useless (knx is usually a quite big installation). When it is deprecated there is no way to point to the converter website...
There was a problem hiding this comment.
We should remove the external domain in the notification. If this is useful, add it to the documentation that is already linked instead.
There was a problem hiding this comment.
TBH I'm not really sure users will be pleased and/or successful in finding that link in this 1,3k lines markdown document.
|
second opinion request is for #46874 (comment) |
|
In general +1 from me. |
Co-authored-by: Philip Allgaier <philip.allgaier@gmx.de>
| # deprecation warning since 2021.3 | ||
| if CONF_KNX_CONFIG in config[DOMAIN]: | ||
| _LOGGER.warning( | ||
| "The 'config_file' option will soon be deprecated. Please replace it with Home Assistant config schema " |
There was a problem hiding this comment.
It is deprecated (see code above).
| "The 'config_file' option will soon be deprecated. Please replace it with Home Assistant config schema " | |
| "The 'config_file' option is deprecated. Please replace it with Home Assistant config schema " |
Please note, that having both a cv.deprecated and a custom message, will now cause the user to have duplicate warnings (with different messages).
Is that intentional?
There was a problem hiding this comment.
I can remove cv.deprecated again if you like.
Would it be welcome if I changed cv.deprecated to accept custom messages in general?
There was a problem hiding this comment.
I can remove cv.deprecated again if you like.
I think it's better to choose one or the other. I don't think we should mailbomb a user with duplicate messages from a user experience perspective. However, I don't know if it was intentional or not, hence my question. So 🤷
Would it be welcome if I changed
cv.deprecatedto accept custom messages in general?
We didn't have had much need for it in general. As most are just removed after it has been automatically migrated or imported into the UI. KNX is a special case, so let's not add that for now.
There was a problem hiding this comment.
Well, this could be the first step to migrate knx to config_flow...
Thanks for review!
Co-authored-by: Franck Nijhof <frenck@frenck.nl>
|
Hi! Will this be included in 2021.3 or 2021.4? |
|
This PR should not have been merged, that was an unresolved comment open:
@farmio Please address that comment in a separate PR, so we can avoid reverting this one. Thanks 👍 |
|
¯_(ツ)_/¯ |
Breaking change
xknx.yaml
config_fileis deprecated.With this PR only a deprecation message and a warning in the logs is displayed. The
config_filewill continue to work as before until it is removed.Proposed change
The KNX integration currently supports 2 configuration Schemes
config_file:keyHaving 2 different configuration Schemes is a constant source for issues and bugs.
We want to deprecate the XKNX-Schema and only support HA-Schema in the future.
To help users with the schema transition we set up an online config-converter at https://xknx.io/config-converter/ where users can paste their XKNX-Schema and get a HA-Schema to copy to configuration.yaml .
This will allow us to take complexity out of the HA-integration and xknx at the same time. Maintainability and building new features will also be easier.
Type of change
Additional information
Checklist
black --fast homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.The integration reached or maintains the following Integration Quality Scale:
To help with the load of incoming pull requests: