The reason HA is as popular as it is today is not because the UI was easy to use, it’s because the so called “power users” helped the new users who didn’t know how to use anything in HA, including YAML.
I was one of those people a couple of years ago and learnt how to use YAML and make HA work with the help of the community and now try to give back in the same way with the still limited knowledge I have. I don’t necessarily have a huge problem with this particular change, but don’t like it either.
To go back to the original quote, the only reason I can see for something to be made easier so it will attract more people, is money. If there is no financial motivation, then why try and make it easy for the guy who can not program the clock on his Microwave to be able to use HA?
As I mentioned earlier, it is a slippery slope when money starts driving decision making.
That sounds like “for these integrations we do it like this, for those integrations we do it like that.” To me that’s not worth the effort. Besides, new contributors would be confused why some integrations do it this way, some the other. There should be one guideline to follow. Allowing different paths will cause fragmentation, and eventually prevent improvements to the core because one of the two options isn’t compatible with a new feature. This will stall the overall progress.
Regarding the rest of your response: I very much appreciate the amount of thought you’re putting into this. But I doubt this will lead anywhere. My statements further above were rather abstract and didn’t necessarily reflect the actual state of what is happening in Home Assistant. It was more like a fundamental view on the pros and cons of different types of configuration, and what I believe is a subset of the reasons that lead to the decision to put UI-driven configuration into the foreground.
There often are paradigm-shifts in software development. So what appears to be a good idea now may turn out to impose significant limitations later on. Of course nothing can be entirely future-proof. But I believe taking away / limiting an approach that heavily relies on syntactically correct input and replacing it with something only the developer has control of has the chance of minimizing problems for the majority of users.
Hence I approve, even though I get why it hurts to lose the more open approach. Just about 2 hours ago I had to replace a sensor, and it wasn’t fun. I have dodged Lovelace until it was mandatory, so it took some time figuring out where I had to click which button to make everything look as before. Back in the days I would have to replace the old entity ID with the new one in a few files and everything was done. So from my point of view I would sooooo much more complain about making Lovelace standard than the shift to UI-config. But…I don’t. Because even though I don’t like it, I see how others benefit from it.
Thinking about it, I get the feeling like this topic share some similarities with the Infinity Saga. Now that everybody knows Thanos wants to Snap his fingers for the greater good, the Avengers assemble to fight him.
Sounds like a good reason for making the integration-config UI-driven (nobody needs help anyway because it’s so easy), and keeping stuff like automations and scripts in yaml.
There are a few of us now who’ve made or alluded to this point. I think it is very pertinent. It is obviously going to inform all decision making going forward.
As I said, very much earlier in this thread, only time will tell how that works out but once on that slope there is no way to turn back.
There’s Almond (0.102+) built-in which allows you to create automations with natural language. You can create some automations very easily with that. For example here is the “turn on light when motion is detected” example which lets you make that automation in just two clicks:
There’s also Device Automations (added in 0.99) that let you do all this with simple dropdowns. I know you’ve said that you don’t ever use the Automation Editor (and personally I don’t either, YAML automations for me), but it’s gotten a lot more usable for newbies lately.
It’s not necessary to know advanced templates to create automations. I doubt you did that when you initially started either, it’s something that people eventually work their way up towards.
If someone can’t figure out how to follow directions for a straight-forward thing like an integration then automations and scripts would be totally beyond them.
then they would come here asking questions and expect us to help.
Heck there are those that can’t figure out the UI editors without help (as in the example posted earlier).
Yeah, YAML is aimed for people to read and use. Hence it is used for the configuration one would edit.
The storage does not have that goal. It is meant to be read by software, not humans.
The storage is changing and updated during the runtime, in area’s where the YAML configuration is static. It means that it is processed (read/write) quite a bit. JSON is much faster as well.
The thing that has never been explained (ok I may have missed it) is why the ui generated config has to stored in json rather than yaml? They (json and yaml) are supposed to be functionally equivalent, apart from the ability to comment. So why the swirch? There may be technical reasons: what are they?
I agree that you work your way up to it, BUT, if you only use the Automation Editor because it’s easy, then want to do something more complicated that can not be achieved in the editor and have to use YAML, you will have no idea what you are doing.
If you start using YAML to do basic tasks and learn how to use it correctly, some trial and error, make mistakes, then when you want to do some more complex tasks, you will have some know how and understand the cookbooks or examples from others with more complex documents.
The choice of using JSON, as opposed to YAML, was because no human was supposed to be poking around in the .storage directory. Making it easy for the average user to modify those files was not a requirement.
I disagree. At least it depends on the instructions. I myself have encountered Home Assistant documentation that I, as someone using HA since before 0.20, didn’t get. The problem with developers is, that they usually are rather bad at writing documentation. It’s just not their primary focus. And there are times where some prior knowledge is assumed by the reader. In german I’d call this Betriebsblind, don’t know how to translate that. Roughly it means that the developer is so used to the topic, that it doesn’t even occur to him that someone won’t know what he knows.
From that it could be derived, that the documentation (at least for some integrations) would require improvements. However, if the integration-configuration is stripped down to clicking Next 3 times and entering a username at some step, there isn’t even a need for documentation. It just can’t go wrong. Except from rare environments where firewalls or whatever may be an issue.
Thinking about this makes me wonder: has anyone set up their Philips Hue stuff (connected to the regular bridge, so the regular Hue integration that’s being discovered automatically) via yaml in the past months/years? My guess: only the people who did disable discovery altogether.
Oh, not at all. I’m thinking that for those simple integrations, its a subset of the full capabilities that is needed, not a different set. That is, just a single schema definition without the need to define a state machine to drive a more complex configuration.
Oh, that is kinda discouraging
I actually don’t mind that a UI driven configuration be one of the options. I think the whole point of this discussion is that it shouldn’t necessarily be the only option (which, IMHO it is destined to be with the current approach).
So, what is the actual state? And, what are the complete set of reasons that lead to the decision? Care to enumerate? Really, I’m interested in the background.
I am not advocating for something that the developers don’t have control of. How is a schema definition not something that the developer is in control of? It would be part of what must be supplied with the integration. What the approach theoretically does do is shift the requirement from code (config flow) to something else (a set of declarations) that can drive multiple authoring approaches.
Sorry, guess I’m to much of a codger to get the reference But I think I get your point. I think that the whole point of this thread is that it isn’t necessarily for the greater good of everyone concerned. I suppose we all will get used to it.
Thanks for responding. Alas, I think its time to accept those new flying machines although I just don’t know who would ride in one of em anyways.
Don’t get me wrong. It’s not about what you have to say. I just think all this is already decided, so thinking about alternative approaches won’t have any effect. At best, this would be a mental exercise. Which of course is a legitimate thing to do. But I think we both have better things to do than thinking about solutions which will never be applied.
I don’t know. I’m not involved at all with this topic. I’m just a developer (outside of Home Assistant, only occasionally contributing minor things) who advocates for the devil because I can relate to the decision. Probably for different reasons than the ones who make decisions.
Sorry, I was stuck at the point where users shouldn’t be able to enter parameter x if it’s not applicable in a certain configuration, but available in another one. So the rendering of the schema. Essentially: the user shouldn’t be able to mess with things he shouldn’t mess with.
In case you have a Disney+ subscription, there are 23 movies in the Marvel-section which can occupy you during your Corona-boredom. When you’re done you’ll understand the reference.
Retired developer, mobile industry mostly. Fun to play with HA and my uProcessors. Or watch the bark stretch on the trees.
Wire up the house you know, just like when I was a kid. You know what they say, twice a boy, once a man. Think I’m on the second boy round now.
Oh, not bored at all. More projects to tackle than I have time for. Guess it’s time to go back to trying to hack Lovelace cards, or some C++ for uProcessors.
Is there a way to make a cli based program to edit the configuration in the .storage folder? Maybe an API? Then maybe the hax0rs can have their way as well.
But I think I get your point. I think that the whole point of this thread is that it isn’t necessarily for the greater good of everyone concerned. I suppose we all will get used to it.
