I feel like expressing my own opinion for what it is worth.
I believe the UI can be the way to go. I felt in love with Home Assistant and I am fully recommending it to my friends who want to start with home automation. Most of them have no programming experience and would most likely use some cloud based out of the box solution. I always try to push them against it.
With the UI getting more mature they are most likely to use it and enjoy the experience.
Or the other hand there are users like myself which love text based configuration (Gentoo Linux user here) and like to be in control of what is happening. I think we should not forget them.
I have a question (maybe feature request): why ui edited automations, scripts, etc are not stored in individual files in a dedicated directory? This could have the same impact on the UI, while being more readable. All automations in one file in one file is one of the reasons I do not enjoy creating them in the UI.
“I like to use a private git repository where I store all my data in, including my sensitive data, since it is not public. Without YAML this is not possible.” This is actually not true, the .storage folder contains all Home Assistant managed configuration files in JSON format, which in those cases, can be stored and versioned in a git repository.
I do like to use a git repo with sensitive data removed, it seems like this is not possible anymore then since there is no secrets file for the JSON configuration files.
IMO HA should stay a geek project for enthusiasts. If someone wants to use it, he’s free to learn and become a geek, too. The community will help every new inexperienced user to become a geek in this field - if the user is willing to learn. If he’s not, there are plenty of commercial easy to use platforms available.
It was not a question, just a conclusion. I do like to have a full backup in git that I can share and that is simply not possible anymore. I understand that the HA devs want also graphical configuration, but if this solution is the best way they can come up with then I think it’s best to go back to full yaml configuration and ditch the UI configuration.
Very sad… our IT industry is maturing with Infra as Code, pipelines, everything as code, moving away from repetitive GUI interfaces used to configure systems. Here HA is going the opposite way.
Before we had Google Assistant, Alexa, Mi Home, Philips Hue, and all Cloud Platforms, easy for non-technical persons, but indeed difficult if you value privacy. Otherwise… if you wanted to own your IoT, avoid the Cloud, and have everything working locally, you got to be tech-savvy anyway and went for HA. I relied on HA to replace all those apps, and now that I can’t simply copy & paste config with people or Git, it just got harder.
that’s a very good point with infrastructure as a code! that’s exactly where it should go. GUI never can be as easy on repetitive tasks as some code or task where you have to add more than just one integration.
And we still remember that ugly beast called Windows Registry. UI and some registry tweaks is not the direction we should go.
Now, I see news of integrations offering GUI-based configuration, like Logitech. I’m heading to the Logitech integration documentation, but only see the nice YAML-based options, nothing about the GUI.
Of course, this is a well-known issue, since the 90’s Microsoft had to make thousands of pages made of screenshot to explain all GUI options, while all modern Infra as Code or old Unix config files were taking a few nice manpages…
Maybe the next phase of HA is removing the documentation together with YAML and let user click-click everywhere like Windows users
What are you talking about? The first section after “supported units” says:
The preferred way to setup the Harmony remote for your installation is via Configuration >> Integrations in the UI, click the button with + sign and from the list of integrations select Logitech Harmony Hub .
First off I would like to apologize if I misinterpreted your comment. That is a fair concern, but historically it has never really played out like that. This is the first time that I’m aware of, and there’s a good reason for it.
Integrations are a bit of a different beast. There’s 1574 unique ones now, different code for each. It requires a lot of work and time to get an integration added initially because it goes through a (human) code review and approval process. And then it requires even more work to maintain that integration - lots of bug reports to address, some of which only occur on certain hardware or installation methods. Lots of time spent keeping up with changes to that integrations API and so forth. It’s easy to take these things for granted, but contributors often have to do lots of upkeep in order to keep integrations running smoothly for the users.
When you start adding extra burdens/requirements like maintaining two different configuration methods, it makes things a lot more complicated and time consuming than they already are. It’s adding complexity not just for the contributor but also the code reviewers I mentioned earlier. This is a bad thing, as a lot of integrations might never get off the ground in the first place. In other cases the contributor might abandon the integration due to stress / workload involved. Then users are stuck with something broken that’s not being actively maintained and not getting bug fixes.
So this solution puts all contributors on the same page, they have to support one method and not two. In theory it should be less stressful on them and reduce burnout, it will mean less bugs to fix, and should result in higher quality integrations across the board. Users will also be on the same page, they’ll have a consistent place to install integrations. And it’s easier and faster, and with no breaking changes or restarts. These benefits outweigh the minor inconveniences to power users who wish to still have 100% of their config in YAML.
I realize you’re probably still going to be upset with this change regardless of any reason for it. You had something working a certain way and wish for it to continue working that exact same way still, totally understandable. But hopefully this provides a little bit more context as to why things went in this direction. You don’t have to believe me, but I can assure you there wasn’t any ulterior motives behind this decision.
So we used to have an awesome documentation with all fields available and all. Now I can also get the example of Doorbird below, documentation is limited to a paragraph or two, no description of the list of elements to expect or anything, I guess we have to install and click to see, no way to know in advance features in advance. I mean, that ‘okay’ lot of software have limited documentation, but HA got us used to great extensive documentation for people who knew what they were doing.
" To add DoorBird to your installation, go to Configuration >> Integrations in the UI, click the button with + sign and from the list of integrations select DoorBird . After filling out UI prompts, click the gear icon to edit device settings. Enter device event names here to associate with a schedule in DoorBird app. See Schedules"
This is only for integrations. And for the most part, you could never simply copy and paste integration config in YAML either and have it work right away, because values like your host IP, username, password, API key and tokens will ALWAYS be different from the persons config you copied it from.
If you’re going to have change most values anyway, what difference does it make if you’re typing them into a text editor and hitting save, or typing them into a web dialog and hitting save? It is pretty much the same amount of keystrokes/clicks.
So how exactly is it harder? In above example you can click a checkbox rather than typing out a full word “true” (easier and faster), and you can use the integration right away after hitting “Submit” button rather than waiting for a Home Assistant restart (again, easier and faster).
This is a good example thank you. How do I secure secret storage with the GUI? In the past I had control what went to secrets.yaml, and I could make sure it’s not part of my backups on Git.
Anyway, if you like to document your change management via screenshots, this is fine. But I used to be able to version my config via Git the right way: as any Infra of Code, I could commit the changes, and auto restart my podman container via a gitlab runner. All easy peasy, using best practices of IT. If a week later I notice a regression, I can easily see the history of changes.
About sharing online, I Google often pieces of config, which is not working that well with screenshots unless Google starts doing OCR.
It’s good to have choice, like Windows vs Linux. My point is that HA is now simply targeting the same user base as all Google Assistant, Mi Home, etc. I’m glad those platforms exists for non-ITers, but even Microservice started to recognize the limitations of GUI-only applications, and improve its command line again for power users.
If the config is not in yaml you can’t use the secrets file. When you put the .storage folder in git as they suggest all your passwords will be in plaintext in your git repository.
But that only applies to integrations that are UI-exclusive. In some cases yaml-configs will remain available (at least for a while), and there the secrets-file should stay available.
What#s the point in googeling how to configure an integration? It will only have so many options that will be documented if necessary. There’s just no reason to google that. Your point only applies to things that can come in different flavours, like scripts and automations. Which, as stated quite a few times now, will remain in yaml.
For now. If both YAML and UI were supported I would have no problem at all with this, but YAML configuration of integrations is actively discouraged, will receive no updates and already several integrations have dropped it.
