That’s why I phrased it as a vote, not a decree.
As for what’s the harm, it eventually allows people to ratch up the rhetoric to a point it serves to not only embarrass themselves but reflects poorly on the entire community. That’s why forum software has thread locks, often employed to protect people from themselves.
One thing you’ll notice on all these posts against the changes is that not one of the people has the flag contributor next to their name
I’d be interested to know what the rules are for the contributor flag. I’ve had 3 PR’s accepted (only docs but still), and I don’t have it. And only ~1000 people have it vs the ~4000 contributors listed on the credits page, and that hasn’t even been updated in 6 months. Anyway, I don’t think its a reliable way of telling who a contributor is.
The flag is rather new, less than ~6 months and it’s not retroactive. It also only works when you deliver to the backend I believe. Not sure about frontend. And lastly, it takes like 2 or 3 months to hit your name.
I have been watching this conversation evolve, and feel like I need to weigh in to the debate.
I am a long time HA user, but have not been active in the forums, nor do I have a huge install. I have moved house a couple of times over the course of my use of HA and taken the opportunity to “start over” each time (always using the old configuration as a starting point for the new install). I have occasionally rebuilt my deployment from scratch using my YAML configuration. This would be tedious to say the least if I was forced to do this with a GUI only approach. In fact, the current on-boarding workflow always seems to ignore my YAML core configuration, or at least it is confusing as to which data is actually used in the end. With that said, I have gotten much pleasure and joy in using HA, and I do appreciate all the contributions of so many people.
A couple of points about this debate, even if some of this has been hashed to the max already:
GUI and textual configuration approaches address different use cases (with some overlap in the VENN diagram for sure). Neither approach addresses all use cases nor would I posit that one approach is better than the other. They just address different users and use cases, all of which are valid.
Arguing about whether one approach is better than the other approach isn’t useful IMHO. Both approaches are valid. They just address different users and use cases. Different approaches “scale” along different axes. It would be fantastic if everyone could agree on this point!
Arguments that one can do task “x” with one approach doesn’t mean it is convenient or practical in that approach.
For example: when sharing config, just document the integrations that you use with comments rather than including the integration config itself; or that new users just need to learn YAML; or just copy the unknowable, undocumented black box of .storage around if you want to backup or replicate your install. Of course if one tries hard enough, you can do task “x”.
IMHO that argument just doesn’t hold much water when considering abandoning a more convenient and practical alternative method, its simply trying to justify the approach already taken without considering how best to solve a given use case.
Arguing that YAML should be abandoned because changes require a restart is a deficiency of the implementation, not the approach. The correct solution is to fix the implementation.
The argument that integration developers shouldn’t be burdened with supporting both a GUI and YAML configuration implementation I believe comes from a fundamentally incorrect design assumption. Integration developers should not be presented with the choice of implementing a GUI, YAML, or both approach. I believe that it is an invalid choice to begin with (and I certainly understand the historical path that lead things to this point). Instead, consider:
Integration developers should declare WHAT data is required and not be concerned with HOW that data is obtained.
Taking a different design approach will:
Free the integration developer from having to support multiple configuration approaches.
Follows in the spirit of the tried and true “separation of concerns” design pattern. Integrations “integrate” and no more. How the configuration data is obtained should not be the concern of an integration.
Future proofs the current and on-going investment in new and existing integrations.
Allows different configuration “authoring” mechanisms supporting different use cases to be supported by the platform, not individual integrations.
Data validation becomes the responsibility of the platform based upon the declaration of what the integration requires.
Allows future experimentation with different configuration “authoring” approaches for different use cases.
In fact, this very approach was suggested in the discussion of ADR-0007.
So, I am curious. Is it possible to support a stand alone, text based, unattended configuration mechanism using “config flows”? Are “config flows” inexorably tied to interactive, GUI based approaches? I ask since I have not yet deeply explored what “config flows” are actually capable of. Enlighten me and others please.
I think that numerous use cases supporting a GUI or textual configuration approach are well documented in this forum. I am sure there are other use cases that will come to light in the future. It seems to me that NOW is the time to reconsider this approach, and thus the spirited discussion taking place here.
By making YAML an opt-in choice for integration developers, it effectively locks in the “config flow” (GUI?) approach for the long term and potentially cripples numerous other valid use cases. I don’t think it is unreasonable to assume that YAML configuration will slowly become obsolete. As more and more integrations support the “config flow” (GUI) approach, it will become impossible, given the effort involved, to change course again and support any other approach, however valid, in the future. Alas, me thinks that it is already too late to change course, but I hope…
beta testing by users doesn’t count i guess.
Did you bother to read the post and the replies? Literally putting words in his mouth. More reason to lock this thread.
then lock it
Just let me get out my trusty locking tools… oh wait, I can’t cause I’m just a user.
and so are a lot of us. Users are tired of things working and then changes happening.
The only reason I know about the change is because it was on reddit, and god forbid posting over there is just as tockix.
I hardly ever come here and check anything because of all the changes that keep happening from release to release. God forbid I want to try something new because that just means having to start over from scratch and fix everything that’s now broken just because I want to try a new integration.
It’s been like this from the beginning. People are just tired of seeing change, just for the sake of change.
I am more or less in the same situation as you in terms of using HA and not being active in forums. I completely agree with your points. I think all of this comes from a pure technological design issue, nobody should choose YML vs GUI, and it seems to me with a proper design all type of discussion should be gone. The technology should help people not open these kind of barriers.
I don’t even know how to respond to you. Can you please elaborate on what integration you’re having issues with? It really seems like you came here to start a fight.
markdown doesn’t work, rocket-launch doesn’t work, I’ve got to redo my entire front end because custom cards have been either deprecated or integrated, restart locks up and halts system if all roku devices are not powered on during HA restart…
And what do bugs in integrations have to do with “The future of YAML”?
All the lovelace and frontend changes are for a good reason, speed. You can’t be upset about a custom cards that aren’t backed by hass. You should be upset at those card developers for not maintaining their code. Taking it out on others isn’t fair to anyone.
taking what out on others?
You asked a question, I merely responded.
Again this goes back to change for the sake of change. Something always has to be changing. Always. If it’s not a release that has to be updated, its a minute name change that makes no sense, or this, or that.
Honestly I’m also offended that I make 1 comment and you accuse me of wanting to start a fight.
I strongly disagree with this, we can and should accommodate both types of users.
For example, I’m very thankful that my non-tech savvy parents can text and video chat with me. This is only possible because tech companies didn’t say “LOL go away old people” and completely ignore that audience. My parents don’t know about all the advanced gestures, long-press shortcuts, multi-tasking features of their cell phones, nor do they care. But they can comfortably use and enjoy their small subset of features without any issues. That’s a great thing.
There’s absolutely no reason Home Assistant can’t be the same way - used by people of all different skill levels. These users can peacefully co-exist. It’s the reason for the “Advanced mode” toggle among other things. The implications in this thread (and elsewhere) that developers should only spend time catering to advanced users is rather selfish imo. We all used to be newcomers that struggled through an initial learning curve. Let’s not lose sight of this fact.
A lot of posters in this thread are mentioning how they help and provide support to newcomers (which again, is very much appreciated). Think about why you guys do this - it’s because you want to pass your knowledge along and help more people use the software. You guys update the documentation because you don’t want people to get stuck. And because helping others is the nice thing to do. The pushback and conspiracy theories towards the developers for working towards the same common goal (trying to making things easier for others) is unwarranted IMO.
Okay then, good luck.
I agree with that.
But unfortunately that doesn’t seem to be the direction things are going.
Doesn’t it really seem strange that most of the “older” users who are here are simply asking for their ability to continue to configure their system using yaml? It’s not like there hasn’t been substantial use cases provided to support that desire. And it’s not like we are asking to completely change how things are done. I honestly really don’t care if there is a GUI added for every single function.
All *most" of us are asking is just to keep the existing paradigm and not force us into using the UI to configure our systems because “it’s hard for new users to figure out yaml”. So what? Let them use the UI along with it’s inherent limitations in functionality.
But to shift the focus to cater to “grandpa” (which I am one of several times over…) while alienating your existing user base just doesn’t seem like a winning strategy to me.
Literally the only thing that the majority of people who have issues with this are asking is to just keep the promises made and keep the ability to configure things in yaml along with the UI config if desired.
Well said! Bravo!
As someone who contributes mostly small PRs but also a code owner. The clarification on configuration is great. We were always operating under always changing and unwritten rules. The config flow process also greatly increases the flexibility of the configuration process. Personally, I hate YAML configuration as a user and I like the change.
I will agree that the way this had been rolled out gives off a smell of being pushed through rather hastily in the back room, so to speak. The ADR 0010 was posted and then published in less than a day. Further, it was published only 8 days after ADR 0007, which it significantly superseded. What happened in those 8 days? It is possible this was prediscussed over a period time internally, but this doesn’t help the optics either.
I think your speaking for a smaller subset of veterans than you think.