I am glad the maintainers have put this decision down and made their stance known since we have seen a lot of inconsistencies in what is supported via yaml across various integrations recently. Unfortunatly, I feel very strongly that the wrong decision was made.
I get it that you want to widen your base, but to dumb it down to be UI only configuration but come on, yaml is not very hard to get the hang of. If someone can’t handle editing a yaml file, how are they going to understand mqtt?
Anyway, my biggest frustration is with not being able to keep my configuration in GIT. I know you call that as a myth above, but either I’m doing something wrong or you have not tried this. Removing .storage from .gitignore is not a good solution - every time you log in, files are marked dirty because they have last login dttm. Sure, I can remove still ignore the auth file(s), but I still see entities change every time a restart happens. New entities come and go based on what is on line at the time and even some entities seem to randomly change position. Am I doing something wrong here?
Would it be possible to at least provide some type of import and export feature?
That’s what snapshots are for. An exact representation of the target state for deployment. Like Docker images, VM snapshots, and, yeah, even git for .storage.
If you do a minimal CentOS network-kickstart installation, the resulting installation today would be different than the exact same kickstart file would have created 2 years ago. Thank god in this case you won’t have to expect breaking changes by newer packages.
Which could fail with yaml because of the possibility of breaking changes. An integration set up via config flow wouldn’t suffer from this limitation because the outdated configuration would be updated automatically.
Again, snapshots.
Sounds like cloning a VM to me. But ok, that’s a valid use case where I can see the benefit. The hosts IP shouldn’t be cloned as well to avoid a conflict after all, and with yaml the local IP (if required by an integration) could be adjusted programmatically. So in this case yaml wins.
That’s where the integrations based on oauth2 (which at best is a real pain in yaml, if possible at all) actually would be way superior. In case of a breach you just revoke the token and walk through the flow again.
I can relate to your view as well in this case. Although that seems like total overklill to me. But I guess this is a personal preference.
Real ITers don’t need more choice, they want more choice. And I get that. Where I work we deploy machines via kickstart (we’re only working exclusively with RedHat). Saves a lot of time. But: (at least for us) there always are parts of the installation that are (and have to be) manual. Like software licensing, adjusting for the final requirements for the use case etc… After all, these machines won’t be clones. They are individual hosts. That’s why after some form of automation they still need manual care.
I’m a cli-guy as well. I often tend to do my sysadmin work via cli as well, even though my boss wants me to use the GUI to constantly verify nothing has broken in our product. So I totally get where you are coming from. But that’s also exactly the reason why I’m so stubborn at promoting UI usage. I have to deal with customers who aren’t capable of properly handling our software regularly. Customers always find a way to break their system if you give them the chance to so (which our software unfortunately does). So I’ll admit that I’m very biased on this topic as it would make my work-life much easier if the system just wouldn’t allow to do things that are not meant to be done. Which is the direction Home Assistant is heading to.
I don’t really have any thing to add, I just want to add a motivating comment. I love this project and appreciate all of the contributors and what they do. They put in their blood, sweat, and tears into their contributions and they should be commended for it.
I have been using a custom add-on for my nest thermostats and doorbell due to Google / Nest pulling the api. This is using Yaml to store the tokens and cookies. This changes from time to time (more google changes) and is easy to fix in my yaml file. Not sure how easy it would be to do the same using a UI only.
All fair points @templewood. Here’s how I look at it - if we acknowledge that some integrations are infeasible to support via purely YAML config (things involving 2FA for example) then we’ve fallen below 100% YAML support and almost all of the common complaints in this thread already kick in.
And it’s also fair to assume that if we don’t enforce strict guidelines that contributors must support YAML, the percentage of integrations supporting YAML config are only going to decrease over time. Even before this new policy, contributors were already skipping it in new integrations and removing it from existing ones.
So I think regardless of whether it’s encouraged to drop YAML from existing integrations or left up to the contributor as you’ve suggested, it will be more or less the same results in the end, because very few contributors are going to do twice the amount of work adding/maintaining something if they’re not required to. That’s just being realistic about things.
I get the sense that most people arguing strongly in favor of YAML want all of their config to use it, not just some.
That’s true, but it’s interesting to look at the incentives the contributors have. If you want your integration to “behave properly”, i.e. have its devices listed in the integration screen, being able to use areas, etc… you need a config entry. The examples and documentation for config entries and flows are mostly UI based, rather than YAML-import based. Additionally, there are cases where you can’t reliably import from YAML (when the device doesn’t have a native unique id and you want your integration to leverage the entity registry).
There are several threads in this community forum that have been locked by the moderators (including the recent blog post announcing the new branding decision). Therefore, there is precedent for not allowing “peolpe have there says”.
In fact, this thread was briefly locked (while a portion of it was spun off to another thread) and then (after a short cooling period) re-opened. For awhile some people’s emotions ran high and were making personal attacks rather than debating ideas. Fortunately, it was short-lived and so there was no pressing need to lock the thread.
Some integrations won’t have a “YAML editor”. See ADR-10 to know which ones.
I have been following this since the release and have thought about it daily. I have now concluded that the goal of ADR-0010 is not correctly understanding how a new user starts with Home Assistant.
The Goal:
Considering that, enabling and empowering people with managing their Home Assistant instance via the user interface is needed. Not just for the lesser tech-savvy, since it also brings convenience, that even many technically capable users enjoy and prefer.
Goal: Making things easier.
A lot of steps are needed before any user gets to installing integrations / add-ons, yaml, etc.
I believe a non-tech savvy user will never get there and give up a long time before they get to installing new add-ons.
A new user first has to understand how to install Home Assistant. The user will need to be able to understand directions and learn many new things. Many of these are not currently GUI. The user learns how to install home assistant on a PI (usually first step) or NUC or VM or ETC. My experience is that a lot of this is CLI, NOT GUI and certainly not for the person that can’t set the clock on the VCR. Is the goal to sell a Pi configured with Home Assistant installed?
Once Home Assistant installed and running, now what? Most say install SSH & Samba (or monitor and keyboard) to be able to get to Home Assistant from another device to correct any issues. SSH is command line as is the monitor and keyboard. These steps have a steep learning curve for non technical people. If they get this far, they surely can understand yaml add on directions. Sometimes they may need a little help which the developers and forum users have been more than willing to do.
I saw the change of the MQTT from yaml to GUI. This was far from clear and it was not easier than how it was done in YAML.
I agree that the change will make it easier for the code developers as they are now going to maintain only one interface. To state this as a change to enhance a user experience is disingenuous. Once a user has reached the stage of wanting to add on from the standard install they have went through a big learning curve and master a lot. Adding on from the standard install either from GUI or YAML should be something that can easily be mastered provided the documents are clear and valid for the version being installed.
Sure for some part, however, goals are set to get there.
That is incorrect. There is no CLI involved to flash an image onto an SD card, pop it into a Pi and get started.
This has actually been worked on the last months. It is no longer in the installation instructions even. As for problems, safe mode was introduced to remove the need to go into a CLI to get things up and running again. For new users, not in expert mode, the SSH add-on will even be hidden.
No sure where you saw that, but that is not correct.
I’m starting to get into Home Assistant. I have very little Linux experience, some programming experience. I love the configuration via the UI (mostly laziness).
I couldn’t setup the TP-Link Kasa integration via the UI as it failed to find any devices and wouldn’t go any further. It couldn’t find devices as they’re on a different subset. I HAD to setup the integration via YAML which thanks to the documentation I found quite easy.
I agree with some of the other posters that sharing and copy and paste from old YAML files will be missed.
One thing I found odd was the reasoning about contributors not wanting to use YAML and potentially dropping their project/s. What about contributors that DO want to use YAML, or DON’T want to setup their integration/s to use the UI?
Safe mode has never came up for me. Lots of time the system does not come up after an update with zero errors. CLI lets me fix it.
To install home Assistant on to a sd card is not straight forward to a non tech user. They will first have to figure out how to put in the sd card correctly☺️. If you think a non technical user can figure out how to download and install etcher, download the correct image and install it but not handle yaml installation instructions you are kidding yourself.
Nice idea, splitting between config and state in the .storage would be a nice thing to do going forward, even if it would require a re-work of many of the integrations.
It may be simpler to have some sort of ‘manifest’ type file for each integration stating which files are configs and which are state storage.
I “quickly” checked the architecture repository and found some suggestions on how to struct the .storage folder but they were closed as solved by the architecture decision discussed in this thread.
IMO it is an independent discussion to use .storage for some things and how best to structure the .storage folder. So looking at focusing on that discussion.
I plan to go over the different proposals on the architecture repo before making a proposal that tries to combine the options and does not challenge the decision of using .storage/json , just allow addressing the requirements of good history tracking.
I agree that installing it can be an initial hurdle to overcome. But the preferred instructions are not overly difficult for newcomers (install Etcher > insert SD card > select image > hit flash button) and there’s many video tutorials for it where you can follow along visually. The part we can control though is the experience after installation and try to make that smooth sailing for everyone.
Initial setup process has gotten really nice since last year. You pick a username and password, press a button to detect your location and fine-tune it by moving a pin on the map, all from the UI. Then you get a screen with all of the devices discovered on your network - for most people it’s going to find almost everything they own. Their Hue and LIFX lights, Chromecasts, Roku, Sonos, even printers now. You just click the devices you want to add. With the upcoming 0.109 release these will even have nice brand icons now:
After you press “Finish” you’re taken to an auto-generated Lovelace user interface with all your stuff already there. You can create automations, scripts, scenes, zones and more from the UI without needing to know YAML. You can make snapshots from the UI, you can install add-ons within three clicks. With the Nabu Casa trial you can get remote access with one toggle and can easily make your stuff available to Google and Alexa from the UI. The official iOS and Android apps detect HA instances on your network and help you get setup easily with them too.
So it’s simply not accurate to say you need to know any YAML or command line experience to have a fully working Home Assistant setup. As you become more comfortable with using Home Assistant and want to do more advanced things later on, you can choose to learn those skills over time leisurely at your own pace. But it’s no longer required knowledge upfront to get started. Which is how it should be.
The user experience is not perfect yet, there’s still lots of work to be done, but it’s improved a huge amount over the last year or so. Lots of contributors have worked really hard to make this more accessible.
It is interesting to read the discussions about this topic as an outsider (with 25+ years of IT background in different roles as developer, implementation consultant, application manager and architect of rather complicated architectures for several corporates).
I see the same things happening here as in a corporate: a lot of emotions (probably also based on previous interactions), change management issue, architectural design principles and determination of the target user group.
I cannot solve the first two, but I would like to share my experiences as a user of the platform until now (I am a relative beginner on the platform, but normally I pick up these kind of things rather quickly).
Installation was relatively straightforward based on the clear instructions (first on Raspbian and recently on HASSIO).
What I understand is that it can be difficult for someone who is supporting newbies on the platform if these newbies use the UI. It is more difficult to get the right input to be able to spot the issue compared to getting a snippet of a piece of YAML. I am not sure if there could be functionality which can provide someone supporting with the code behind the module that the user is experiencing issues with, which can then be imported in another system to enable the supporting person to reproduce the issue and provide advice.
On the other hand, the UI will also prevent users from making certain mistakes. I think we can agree that YAML is not the most straightforward syntax if you have not been exposed to it. “Do I need to put a - here?”, “Do I need to indent here?”
I also understand that the developers prefer to maintain one approach. One of the basic design principles is: There should be one source-of-the-truth. On the other hand: There are different types of users, beginners and gurus (and everything in between) who might want to get through things easier. I have also been in situation with HA that I needed to make a large number of changes to my entities and through the UI that is more time consuming than in an editor (where you might use search-and-replace) with the risk to break something. Therefore it is good to see that, for now, YAML will still be available for automations and scripts. I think this is a great platform, for one because of the huge number of integrations, but also thanks to the relatively easy set up, although I would not recommend it to a total IT illiterate and I think that would also not be the target user. If you want to play around you can connect it to many things. The other day I got it connected to my MariaDB on my NAS, which opens new things. Anyhow, you can make it as difficult as you want.
Keep up the good work!
I wish the Core team a lot of wisdom in their decisions.
I believe you are minimizing this. Check out the user groups for Wemo, kasa, Google home, etc. These are basically plug and play and a lot of users can’t figure it out. I agree that Home assistant has gotten easier, but it is far from plug and play. I tried to address the statements that this was going to make it easier for new users. This product is for home enthusiasts, not for non tech savvy user or people wanting to become tech savvy on this product. Clearly having 1500 + different integrations / add-ons makes it a big learning curve. I stand by my statement that the change is for the people writing code, not for the users. Again, I have no problem with the change, just be honest on why it is done and not say it is for the benefit of new users.
I don’t think there is a lot of pushing for 100% YAML. I see that as more of a straw man to retroactively justify a bad decision on the part of the management team. (“It never would have worked anyway, and besides they’re just a bunch of complainers who never contribute anything.”)
But even if that was their goal, there’s a big disconnect between “The door for YAML will be left open for Integrations” and slamming that door shut and driving a nail thru it six months later without any dialog or engagement besides the blog post that announced it. Incongruity breeds mistrust. And preemptively locking the door shut on contributions stifles creativity. Is that what Home Assistant wants the future of their product to be?
Personally, I’m strongly in favor of YAML but not 100% YAML. For integrations where someone might reasonably know the configuration answers in advance, and where those configurations may be relatively static, I think YAML is a better paradigm, and a necessary one for those of us whose networks are professionally maintained (static IPs, several devices of a similar type, etc).
If a contributor wanted to support that text-based functionality, I see no useful reason to prevent them from doing so. And if someone had an idea on how to make that coexist peacefully with a GUI-developer’s work on an integration, I see no reason to prevent that relationship forming either. Unless you’re making decisions based on dogma rather than functionality.
The architecture document should be amended to remove the line about refusing commits and integrations which implement YAML functionality. Instead it should simply state that these are not officially supported and their inclusion in integrations is optional on the part of the contributors who maintain them.
