So what you seem to be saying is that if I created a WTH thread and said “I want HA to read my mind and be able to create complex automations that would allow me to travel faster than the speed of light with no effort on my part” then no one can push back at all on that since it wouldn’t be in the spirit of WTH because we should be able to ask for anything at all?
Of course that is an extreme example but we can all agree that there is some middle ground where someone can say “that sure would be nice but it really isn’t feasible for the following reasons…”
Just because you may agree with the WTH or some portion of it I don’t think that gives you the right to say who should or shouldn’t be a part of the conversation. If you don’t ever want to hear any disagreements I’m sure there are places you can go for that echo chamber effect.
and if there are real limitations that fall under my “EPF” model and you don’t want to put any effort into learning something that could be complex to better yourself and your ultimate HA experience then maybe…just maybe…HA isn’t right for you.
Or just accept your limitations and only do the basic easy stuff.
After skimming this topic, as an IT professional of over 3 decades, I certainly sympathize with the OP.
HA has has been one of the steepest learning curves of my “career” which ranges from AS400 to Nortel to reinstalling Adobe Reader to building customer hardware for production lines to managing AD.
The reason is simply, in my opinion, YAML is not an appropriate language to write programs in.
YAML is (yet another) markup language. Designed for defining properties, configs, etc. For that, it works well.
Hacking it to represent an automation language has made it unwieldy, hard to understand and required more and more workarounds to achieve what is easily done any deterministic programming language.
I would love it if my automations looked like:
If kitchen_temperature_sensor.state > 30 Then
kitchen_warning_light.turn_on
End If
Somewhat like VBScript but any scripting language is fine…and it could easily be ANY scripting language due to the ability to plug interpreters into the engine.
There is a big difference between making general simple thing simpler.
But there is no way you can make the complex enough simple that you don’t need to read the documentations.
Because let’s face it if the syntax states() is too har then you have not opened the first page of the documentations.
This is the worlds most advanced home automation software.
Far exceeding the paid alternatives and I would even argue it’s more advanced than some windows softwares people pay big money on.
WTH is to fix things yes.
But at least come with something. You can’t just come here an complain with nothing.
Sadly too many WTH topics are of things that exist or not thought through enough.
Syntaxes will always be needed for advanced things like converting wind direction. There is no way around it
If you want a fancy remote, then sure HAs basic features will cover you, but the advanced features need advanced syntaxes.
None of us here was born with yaml as their native language
I’m not trying to pick on you at all but TBH, even if it was like that then someone would still complain that they shouldn’t have to know that they needed to put “.state” in it or to know they needed to add ENDIF at the end.
and what the heck is that “>” thing supposed to be? Or what’s with the “.” and “_”? it looks like just a gobbldy gook bunch of symbols to me.
/sarcasm.
YAML isn’t that hard.
every programming language that exists has some required structure/syntax. There’s a reason it’s called a “language”.
YAML is no different. the only thing that makes yaml complicated at all is the indentation. But once you figure that part out it’s really pretty easy. and there are tools you can use to help get the indentations correct.
That snippet you posted is fine in vbscript but what about mixing variables and strings.
All of the sudden you need to "temperature is " & temp & " degrees".
But that’s a syntax and way too hard for those who don’t read the documentations.
I guess what I was trying to communicate is that YAML is very counter-intuitive for an automation language because it was never designed to be used that way.
YAML is a markup language, not a programming language.
Using YAML to write automations makes as much sense as using JavaScript to define a configuration.
YAML itself isn’t that hard as long as one remembers that it is white space sensitive. Using it as a programming language is where the problems begin.
You are making wrong assumptions.
The fact that something is complex under the hood doesn’t mean it must be complex for the end user or maintainer.
There are multiple real-life examples from network protocols (you obviously are using, having no idea how complex those things are on certain levels of implementation) through automotive systems allowing cars to drive without a driver input ending with AI-powered tools. People uses mobile-phones which are proper computers. having no idea about operating systems, how CPU works etc.
HA is not user-friendly in certain areas. Not that it cannot be because of complexity. It’s because those areas are not developed to make them more accessible.
And I completely agree with AaronCake: yaml is not a programming language. never was and will never be. Using it as the language cannot bring anything good. Not that this is the only area deserving an upgrade.
Yeah, and strangely enough, it gets mixed up with YAML support all over the place. In some cases, you can’t even access the underlying ‘code’ (yaml) because it’s internally converted to JSON and stored somewhere in a database or directory that users can’t get to. It’s pretty much impossible to remember where and why this happens.
And if you’re trying to do something more complex, it’s basically impossible to create any decent structure with YAML’s ‘bracket escape coding’. People say, ‘Just use add-on x, y, or z, and you’re good to go.’ But hey, just so you know, you’re on your own because it’s an unsupported add-on.
Honestly, that wind example is just weird. I just checked, the weather card I use is doing exactly that. It takes the weather bearing from the weather service and displays is as letters. Just as I would expect this to work. Now the problem is this is a custom card and the default forecast card doesn’t do this. It’s simply a missing feature there.
Yes. And that was done for the exact reason that people are asking for in this thread…to make HA more user friendly. And ironically that is now being used to show how non-user-friendly HA is.
That is 100% not true.
I have almost 400 automations and many many sensors that I’ve created exclusively in yaml. Many of them are fairly complex.
in fact if you need to do anything very complex it’s pretty hard (if not impossible) to do those things via the UI. Which is why most advanced users use the UI very little and generally stick with yaml. And we don’t want yaml config to be removed because we know that we would be severely limited if that were to happen.
But most users aren’t doing anything very complex with those examples. they are just doing basic outcome driven functions specified by the manufacturer.
if they wanted to use those things to do more advanced and/or complex things then they would then need to get further into the documentation and learn the advanced stuff.
I challenge you to create an android or iphone app using just the basic tools provided by android or apple for the standard user without learning how the underlying code works.
Not sure what the alternative here would be though. Raw coding is way less user friendly and much less configurable through UI. At some point, you need to be able to save the logic of what you are doing in a data-driven format, this could be YAML or some other format, otherwise would we expect users to code their own automations in Python? What is a solid alternative?
On a more general note:
I sympathize with people asking for more user friendliness, but as somebody who has had to work on user-facing systems to simplify complicated logic - it’s often really, really hard. Not only do you need to wrestle with technical issues but balance different needs, expectations and preferences from different users who already have their own way of doing things. I’d just ask to keep in mind that this is state of the art software being provided for free, competing against closed alternatives which do not offer anywhere near as much customization, so it might be reasonable to temper your expectations because it is often not as simple as it seems from the outside.
You’re just proving my point: Understanding the difference between an OS such as Windows and the applications that runs on it by the layperson is learnt behaviour. You make it to be obvious, but it’s only because you know it. Remember, my point was about add-ons and people expecting add-ons to be packaged and basically owned by HA (that’s not feasible or sensible). HA is to an OS as add-ons are to applications.
I think you may be missing a key point by making this a simple “easy but limited” vs “hard but powerful” argument. The point is not that Home Assistant is too hard overall but that it makes it pointlessly hard to do some very simple things.
As you point out, developers don’t care about that because nothing is particularly hard to them. New users and folks moving over from another platform on the other hand might accept a steep learning curve to get new functionality not available on their previous system but are going to get frustrated when extremely simple things they are already used to doing turn into some convoluted, time consuming, process in HA.
