This completely breaks my automated scripts I use to build a .yaml file for my cameras. On top of that, the HORRIBLE integrations page with the small little boxes for each integration makes it even worse to manage. If you have a lot of generic IP cameras, scrolling though that little box just makes you want to yank out your hair.
Please DO NOT remove yaml support from generic IP cameras. In fact, EVERYTHING should also still work via yaml. Moving everything to UI config only is annoying.
Sorry that this is not to your liking. The move to the UI is to make things more accessible to new users, many that donât want to edit config files. I hope you can see that some pain for expert users such as yourself might be an enabler for many more new users.
Parallel YAML and UI based config is an extreme headache to maintain, so migration was the best option in this case.
The integrations UI can be improved with feature requests and pull requests, it would be great if you could submit some!
No one likes a change that impacts effort theyâve already put in. But you should only have to interact with the new ui once per camera add/remove.
And of course you could maintain pre 2022.4 functionality by copying it as a custom integration if you really want it not to change.
The configs are still saved somewhere⌠Make the UI save each integration in itâs own file not one massive large file. This way people can still manually edit the files or like me make a script that builds one dynamically.
Your excuse would be like Linux saying they are doing away with .conf files and now require everyone to use a UI to manage their servers and configs while writing the changes to a Windows style registry. Linux can do both, manually edit configs or have UI that reads and write to the same config for people who want that way.
The reasons for and against have been discussed at length before, so I wonât attempt to re-cover it all.
The UI is not just a front end for some hidden YAML. It does things like multi stage authentication which is nearly impossible with a text file config.
It is also in control of your settings, knows what version they are and handles upgrades of those settings when needed without causing breaking changes. Doing this in YAML would require constant handling of what users might type and also changing your YAML for you, which would probably make you even more angry (so it doesnât do this).
Sure it is all possible but the developer load and complexity is too vast to be worth supporting both.
I actually think there is a case for an addon that would set up your HA according to whatâs in a YAML file. That could exist in parallel with the current development direction (if community members were willing to develop and maintain it).
But without that I believe that we should cater for the majority (who donât want to mess with YAML).
I see the integration settings are stored in the core.entity_registry file which is just JSON format. Why didnât they design it so there was a folder named âintegrationsâ and within that each integration has itâs own config file. They can still be JSON format.
It just seems like a bad idea to store everything in the one massive core.entity_registry file. Something in that file gets corrupted and everything can break.
I would still like to point out that the Integration UI page is also showing itâs age. If I have 20 cameras, scrolling though them in that tiny little box is a real pain. I have to either set my mouse scroll wheel to 1 line at a time OR try to grab hold of the little scroll slider.
Edit: Iâve also noticed they removed the âscan_intervalâ setting.
With the utmost respect, I think you are missing the point.
Moving to the UI means we donât have to check the validity of the stored config on a per-integration basis, because we make the assumption that the stored config is only read and written by HA code (not by a human), and HA is in control of when this happens.
So yes, you could edit the stored json manually. But after a yaml->UI migration, the integration code no longer includes checking of this and there are no guarantees of when it will be read or written. So you could edit it only to find it overwritten, or make a change while HA is live that is completely unexpected and HA is unable to fix.
It is handling these asynchronous manual edits that create the âpainâ for developers. Then of course weâd have to ensure that all parameters were meaningful to human readers, keep up documentation for all of it, and ensure that text edits or UI edits both rippled through correctly to the other.
A huge amount of additional work is done just to ensure the one-off yaml import works correctly, and was the cause of most of the late bugs I had to fix on this migration. Keeping both running indefinitely would be something close to double the workload (or you could say it would halve the development progress).
So a decision has been made, and now I have seen the developer side of it, I completely understand why. You donât like it because of the effort you put into your automatic config generator. I can see that. Maybe you could develop something to support text file based configuration for UI configured integrations. I am sure you are not alone.
Absolutely the integrations page can be improved. Please raise a bug ticket or feature request and link to it from here for reference.