Very often the transition from yaml to UI causes loss of integrations. Users need to add the integration again. It is better disable breaking changes, and requiring automatic migration to be written. HA is already in a stable version. Why are breaking changes now, if in almost all situations it is possible to write an automatic migration? In those rare cases when automatic migration is not available, users can vote on whether it is better to leave the first version of the integration in this form and make the second version of the component through the UI, or users are ready for breaking changes. Very often on various automation forums it is said that HA is not production level, since updates break old features. I think HA is smart enough to almost never break backward compatibility.
I’m not really sure why a automatic migration isn’t already a requirement of the shift from yaml > UI. It just makes sense from a usability point of view, having to rename entities and manually re-enter config that is already there due to an update seems like a bit of a show stopper to me.
I also don’t really understand why making something configurable via the UI requires stopping it being configurable via yaml, tbh. Having both as options and just exposing the same configuration variables to each “interface” seems pretty doable… it works great for my with the HomeKit bridge, for example. I have a yaml config for almost everything so I can have the various entity config options I want, but also have a TV exposed through a UI configured instance since I don’t need any custom config for it.
Having most of my stuff configured in yaml makes backups really lightweight, since I just keep a git repo of my config files…
I think they tried automatically doing stuff like this in the past and got crucified from people telling them not to touch their files, so i doubt they will make it automatic again
That ship has sailed regarding keeping both options for a integration, just do a search and check the architecture repo
Hmmm, maybe have the migration available, but user initiated, and show what the settings look like in the UI from that before committing them?
That’s a pity. I’ll go looking in the repo to get a understanding of the reasons at least
As far as our experience goes (Plugwise), it’s actually not that difficult once you know what you are doing. It’s about the entry-data, as long as exisiting key parameters aren’t overwritten, nothing should break.
Many integrations do/have done automated import. They just don’t delete your YAML. Doing that will re-write the file, removing comments, changing the order, etc. This, as was said above, has caused people to be understandably annoyed - hence why it’s not done.
@Tinkerer But HA may put big banner, that integrations automatically migrated to the config flow, remove them from yaml or click on button so that we remove them automatically. And do not remove this banner until the user clicks on it or cleans it himself yaml
Thank you for your hard work in reducing the breaking changes. The integrators have already said thank you. But you can’t stop, and you have to keep working. As an option, divide HA by 3 the essence of a super core that never changes and works on the protocol of the MQTT for example core and UI