Personally, I don’t care if it is yaml or GUI, if the GUI would/will give the same features as yaml gave before. But in most transition from yaml to GUI of the bigger interactions here in use don’t give this. I think this is not necessary but most times the result of these transitions and really a pity, if more and easier things were possible before.
You’re taking that out of context. Here’s that section:
- Integrations that communicate with devices and/or services are only configured via the UI. In rare cases, we can make an exception.
- All other integrations are configured via YAML or via the UI.
These rules apply to all new integrations. Existing integrations that should not have a YAML configuration, are allowed and encouraged to implement a configuration flow and remove YAML support. Changes to existing YAML configuration for these same existing integrations, will no longer be accepted.
So changed to yaml configuration are accepted for integrations which do not communicate with devices and services. Integrations that do communicate with devices and services are the only ones that are being strongly pushed towards the UI and are restricted from updating the yaml config.
It’s not a blanket restriction on all integrations.
With all this talk about moving from YAML to the UI, I have a (probably stupid) question:
Where are the settings made in the UI stored?
I can imagine times when, with more complicated integrations, I might want to save or copy the settings, or move them to another integration, or another HA implementation. I might want to make a backup of my current settings before I start tweaking things.
.storage, and the individual integrations / Add-Ons( I.E HACS is a bit tricky, if one has 2 dozen , through HACS ) 
Thou Backup of .storage, or copy-paste, after major changes/implementations, is recommended.
Thou as i use VMware, i have a bad habit of Backup the whole VM-Folder 
, yes A-Lot GB !, but after 3 month, in HA’s pace, and me still “Building/Adding” , i do have to regularly Delete, the OLD ones, as there’s really no point in having more than 3 month
EDIT: Apropos HACS , i just installed latest Breaking Changes, Guess i can Delete All backups past 2022.4 now … next month, maybe
2 Likes
Great to see some more discussion on this YAML vs GUI conundrum. The discussion has prompted me to go back and actually read ADR-0010.
From what I can see, the intent of the ADR has been lost. Right at the top, the ADR identifies (what I perceive) to be the core problem:
However, in the first two cases, it doesn’t work. Integrations are discovered. Integrations require users logging in on the vendor’s website and authorize linking (OAuth2) or users are required to press buttons on the hub to authorize linking (i.e. Hue).
(The first two cases are devices and services). I completely agree - anything that involves having to authenticate with an external service using OAuth2 or similar is unnecessarily difficult using YAML config. The ADR reads clearly that it is designed to solve this problem.
The ADR also acknowledges the potential impact on contributors of having to maintain both a GUI and a YAML config option. More than fair enough - particularly for those cases where the YAML config would be awkward and the UX confusing, particularly for new users.
I think there are now two problems:
- The definition for the second case (integrations that integrate services) is too open
- The general understanding of the ADR has morphed into “thou shalt not YAML”, with a slow march towards GUI for every integration
For a service that needs complex external authentication, there’s no question - GUI all the way, and ditch the YAML because it only makes everyone’s life harder. But for a “service” like an SQL query, it makes no sense. There’s no discovery. The config is code and the login is trivial. GUI is a step backwards; YAML is easier to work with for all the reasons we’ve discussed. I’d also argue that GUI is harder for the contributor to maintain (my guess), so frankly no-one wins.
I absolutely respect the devs and the comments in the ADR that a decision like this can be controversial, which may lead to unfair blowback on the devs who do this work as a contribution to the whole community. It is not my intention to throw shade or make anyone feel bad.
But I feel like the point of the ADR has been lost and (for certain integrations) the shift to GUI config benefits no-one.
I’d love to see some thoughtful engagement on whether we should consider making the ADR clearer on the point of what a service is and whether “GUI is always right” is the direction we want to continue along here.
7 Likes
Is it? Curious question, how do you come up with your sql? Do you know sql so we’ll that you simply enter it and restart without any need to test? Or do you pop into phpMyAdmin (or the SQLite equivalent), iterate on it and then copy it back when you’re done?
Something to consider here, perhaps the codeowner isn’t done? For example imagine if the config flow validated your credentials, sql and showed you the resultset as part of the process. Something only a gui could do that actually would make this experience a lot easier without requiring separate software and copy and paste. I get that there are probably some folks out there who know sql so we’ll that they have no need of a validation step. But I would also guess that most of us need some iteration to get sql right and a gui can help with that.
To be very clear, I am not promising anything. I don’t know what the codeowners plans are here. But your point seems to be that GUI is 100% worse then yaml for this integration and I would tend to disagree. Today that may be true since yaml config was simply migrated to GUI config with no other changes, tomorrow it may not be.
1 Like
I really like this argument, I think we should just clear the whole codebase and start fresh with a little login page that takes us to an animated loading splash screen, that’s it - nice and simple.
Then just tell everyone who whines it’s a “step backward” and “where’s the functionality gone” or something silly like that, just say we’re not done yet
1 Like
While I’m not too phased with the move towards GUI from YAML, in particular the SQL integration discussed quite a bit, it does seem odd that parity wasn’t kept: There is no scan interval setting available, which means one needs to disable the automatic updating of the sensor and then create your own automation. While this definitely provides more flexibility, it seems like such a basic convenience that it should’ve been kept, but I did note that other integrations have been doing something similar (a search of the forums will yield several results). I mention this, since one of the arguments of the move towards GUI is for convenience.
YAML vs. GUI is not really the point (or partially).
For techies, you’ll never get the flexibility of YAML in GUI, for sure, but yeah, that train has passed.
What is hardly acceptable is that the GUI configuration framework has barely evolved in those 2 years, and it still lacks basic functionality like proper list handling, which makes both devs and users life miserable …
So yeah, for sure button and update entities , reorganizing the settings page, … are nice to have, but there are some priorities that went under the radar, here…
2 Likes
I’m actually quit new to HA, thou i’ve “followed” it’s progress towards a more “user friendly” alternative to other “limited” Home-Automation Brand Applications, until i decided, it was “mature” enough. i’ve had/have a webserver, DB, MRTG, SNMP etc., i know old stuff, but still a major reason i didn’t go for HA before, was the fact that there was Too Much “code” solutions, as i do find ( ever since the 80th ) Old Fashioned
Why old fashioned ? , in 90th, way into the new millennium, and still, there’s been a “battle” between Unix/Linux VS Windows, Linux enthusiasts always claimed ( still does ) that Linux is superior in literally everything, security, performance, flexibility, efficiency etc etc, GUI is for “noobs”, Tech-knowledge "smart-ass " Programmers use Linux, GUI’s just sucks.
Well, i’ve had my battles proving i.e Windows(GUIs) as a very competitive in basically most, if not all above mentioned( well atleast up until after Win2000, as M started there “journey” towards, to much restrictions and to much “mandatory” redundant Processes “for my needs, requirements” ) , and again, my first Debian in late 90th, i still remember as “VERY” old fashioned, because i then already with a few click could overcome most “obstacles” that my fellow Linux friends spend hours “tapping” code to accomplice. So when Oracle came with an improved GUI i was trilled, and time went by, Linux etc adapted GUI as the most common/used interface … Sure some “tasks” still need to be done, coding , and So here in HA, InfluxDB (or whatever DB ), Grafana, Graph-Cards, Mod-Card, Templates, automations etc. etc.
But the GUI is still a subject to hate and disparage, spite the fact that it’s what “moved” the industry further, i.e Windows is world leading( sorry Linux, but you never had a chance, spite you moved into GUI’s )
PS, i still prefer Linux for certain “components” i.e Apache-server, DB, firewall etc. And i openly admit, i use GUI where ever i possible can (its soo cool, just a click, or 2 away, unless some “new” GUI-Generation mess it up for me) 
, and i welcome any improvements, “New” Features, FR’s etc. Tech moves “forward” People tend to stick to “old” habbits
Well, I would say that community based integrations are primarily focused on devices and services. At least that is my observation. I do not know if statistics would back me up on this, but I would reckon that the primary development and usage of third-party integrations aims at using devices (and services).
So the quote is quite relevant as it aims at the core of these third-party devs. HA core might be different, but third-party is then stongly pushed towards UI.
P.S.: I accept this change of course. I don’t like losing more and more yaml configs as I much prefer them to the UI, but I accept that new users will like it. Since I am not a fan of built-in backup solutions and prefer to restore using yaml, I am of course one of the minority who prefer the old approach.
1 Like
I’m with @AleXSR7001 on this. My preference is YAML for configuration settings, simply because it’s the way I’m used to working. (I go all the way back to .ini files!) There are good arguments in favor of YAML, but clearly the UI is easier for beginners. If that’s the direction HA is going, that’s OK.
What’s not OK is removing functionality that people are already depending on. For example, the ability to use multi-line, formatted SQL, or the ability to set a scan interval.
I personally haven’t run into this situation yet, so I haven’t complained. But I hope this isn’t going to become an acceptable practice.
You can set your own scan interval with an automation. Scan interval is going away in favor of automations because so many people wanted custom intervals. So there is no loss of functionality here, you just need to make an automation and set the interval to what you want with homeassistant.update_entity.
Before I get flack for this, the default scan interval is set by the integration. That’s not changing. If you want a different scan interval, then you turn off polling for updates. Then make your automation with your custom polling frequency.
2 Likes
Thanks, just bookmarked this post. I don’t really think that’s a “better way” than it was before, but at least I know how to fix my scan intervals now! The automation page grows ever longer 
You’ve only been here a short time. A constant question on the forums has been for a custom scan intervals in yaml. It’s sparked many debates about how to format it in yaml to provide a more complex frequency. As always, the debates got heated and the feature request would get out of hand and require sweeping changes. This is the compromise to all those discussions. No update to yaml, but unlimited flexibility with polling because you can use the automation engine.
Nothing wrong with a compromise. Just seems odd that more and more “solutions” are to have an ever expanding automation page filled with 100s of things doing small jobs. Where before I kept things neat and tidy by splitting yaml config into files.
So now I’ve found myself abandoning the automation UI in favour of folders for automations and writing yaml, because the list is too big to manage in the UI and keeps getting longer.
The move to UI has ended up pushing me more and more to yaml… not complaining, just worth pointing out imo.
4 Likes
No disagreement there, automations need some organization that’s missing. It’s the top feature request.
7 Likes
Thank you for the replies. I had no idea scan intervals were controversial. It seems so simple; some things should be done every second, some things once a day, and anything in between. I assumed one simple setting in hh:mm:ss format would be plenty.
I think I had one integration which went to the UI from YAML and I lost scan interval control. That’s fine, the default was good enough for me. I can’t imagine how I’d trigger that integration to do it’s thing from an automation though. It calls a manufacturer’s API. If I needed to write an automation to do that, I don’t really see why I’d even need the integration.
I guess my point (if any) is that every situation is different. I understand there’s a compromise between simplicity and control. I hope we don’t end up making things more complex in the name of simplifying.
I assume what you mean by third party devs is folks making custom components that you downloaded from somewhere like HACS? Custom component devs don’t have to follow that adr. Or any ADR really, they can do whatever they want.
This ADR is enforced entirely by PR reviews. Generally no one from core reviews PRs for custom components and even if they did their feedback would only be suggestions, not requirements.
That would change if a dev wanted their custom component added to core, then it would be treated as a new integration. But many never seek that so they can continue to do whatever they want in their repo.