Thank you for the clarification. Does this also apply in the long run or is there a deadline by which old integrations have to support GUI also?
The decision is here. There is no deadline by which existing integrations have to become UI configurable. Even ones that communicate with devices and services (which are the only type that has a UI configuration requirement).
1 Like
Thank you for the link.
Well, it does push devs towards GUI and drop yaml support.
But does this actually not force people:
Changes to existing YAML configuration for these same existing integrations, will no longer be accepted
Devs can no longer update their integrations if they want to be able to implement new functions that would of course add yaml config changes. If they do, they have to implement UI support.
1 Like
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