It’s not a “mix of terms”; they’re two different concepts and are explained in the Glossary.
2 Likes
The devs seems to be trying to make it easier for none needs, but the move to more GUI options have a big downside.
GUI options needs to be programmed for all the possible combinations that are allowed, so either the devs kill themself with maintenance of the GUI or the have to kill features. Killing features will mean a move closer to Google, Amazon, Apple and Samsung and eventually a HA Clone will spin out and leave the original in a state of not being as user friendly as the ones mentioned above and not being as versatile as the new HA spin off.
HA is winning at the moment, because the possibilities makes it keep up with the evolution.
2 Likes
I disagree that GUIs impose too many limitations. If you design GUI based building blocks that can be used in a general way then there is no more limitation than you have with a script or markup language. When creating an automation for example if you select IF, THEN, AND, OR, etc, from a dropdown it does not limit your logic but it DOES prevent mistakes or the need to learn indents, curly braces, and obscure syntax rules.
1 Like
I disagree that templating is currently only needed for things that are really “out there”. I would argue it is used for too many simple and basic things that should be in the GUI. I don’t feel my example above about needing templating to insert entity values into TTS messages is some fringe situation. I do it easily in Homeseer without leaving the GUI and have been for years and years so it is clearly a standard thing on other platforms.
1 Like
I think you may gain more traction by creating WTHs for these things specifically. Find a thing that is very simple and basic and should be in the GUI and call that thing out.
There is a lot of work going into improving Home Assistant’s user experience while preserving it’s power. Specific improvements will go a lot further than a general sentiment that easy things are too hard to do.
5 Likes
In my view, that’s only a part of the issue. I guarantee you that even if you had a UI that supported everything that YAML does, you’ll still hear: “This is too hard.” The reason is that some people come with very convoluted logic or just try to do very complex things that they are not up to. I can tell you this from reading the forum for years. I see many requests for more standard, built-in functionality.
8 Likes
If you don’t want to use YAML and need more than the GUI provides, there’s also Node-Red as an alternative.
Thanks to the good integration with the HA-Nodes, you can click together quite complex automations without programmer skills (but you can get nerdy and write JavaScript in a function node if you want.)
I myself still use it for everything that can’t be solved in the GUI, even that I’m a software developer.
Simply can’t stand the YAML based „coding“.
(I mean this is a config syntax e.g. FOR programming languages like Python.
Adding coding-like syntax again in here, always felt crazy to me and I had no motivation to take a deeper look at it after I’ve explored the Node-Red Addon.
Here, I can lift the heavy stuff in a - for me - well known language like JavaScript)
1 Like
GUI options needs to be programmed for all the possible combinations that are allowed, so either the devs kill themself with maintenance of the GUI or the have to kill features.
I don’t think this is necessarily true. Automations and scripts are already configurable from the GUI with feature parity to YAML. UI will always be more work, but there is always the option of having both.
many simple and basic things that should be in the GUI. I don’t feel my example above about needing templating to insert entity values into TTS messages is some fringe situation
I think then creating a specific WTH for it might make sense. It’s not on the level of having a motion activated light but it’s also something which more people will use if it’s easy to implement. I would say voice in general still needs some polish regarding UX, it is still relatively cumbersome to set up.
1 Like
One of the things that surprises me on user friendlyness (the lack of) is there seems no uniformity in all parts.
This is clearly a part of the problem with these terms, maybe some clearer explanation is needed somewhere in the UI.
- Addons are separate applications from HA, that you can install from inside HA. They are mostly not maintained by HA, it is just an easier way of installing external apps, think of it like an app store for HAOS. Each developer of their apps will do things their own way and there is no way to enforce UI uniformity.
- Integrations are like plugins inside Home Assistant. They are developed by the community, and can either be given officially (in which case they are guaranteed to work well), or obtained from other sources like HACS, which is not guaranteed and they can pretty much break your system if you decide to use them.
I also think a separate WTH would be good.
This one is so generic, what should be the feature that a Dev thinks „Ah right, I’ll implement it“?
But a „Let us use device names / values / attributes in GUI automations“ might be easier to get. And it also might get more votes (and therefore visibility) as more people might like the idea instead of a complex „rant“ 
1 Like
I was with you on the NR suggestion, but not that last part.
Config as code/structured text beats everything in my view for one simple reason, even if it’s not the simplest for everyone: You can version control and review changes.
I treat my HA like a production system. I don’t just make live changes. I review and test them, and for that you need to track your changes.
And I personally don’t like the fiddling in UIs: It’s too slow and tedious for me. It’s like people that only use a mouse and know no keyboard shortcuts. It just kills me watching them struggle.
3 Likes
I think the problem is not using an Xbox 360 Kinect.
Thanks all for the suggestions, luckily I did discover the python and pyscript implementation, but found out way too late that I didn’t need a workaround to get the results back from a function because no outside return was permitted, but a ‘response_variable’ in my YAML code (which sadly the LLM says only entails a empty object, but the notify file does show the contents… )
Moving on, so for me the key items I take from this are:
1-UI more geared towards an answer/solution to a question “What would you like to do/achieve” and take users through those steps.
2-YAML implementation that helps the (new) user intuitively use it
1
Looking at the script (or automation) interface, especially the ‘Action’ list might really benefit from a revamp. If the ‘Actions’ could be altered into the answer to “What would you like to do / achieve?”. The initial UI interface probably might also benefit from example data (greyed out) that would explain more what is expected with the different fields.
2
Perhaps the YAML could get colored background in order to see what belongs to what, it could definitely help to get a proper error message that means something in order to fix it.
Also when jumping from the UI to the YAML, why not have it give you all the needed items prefilled with example data?
Lastly, I think the biggest frustration might occur, because of when you get stuck and search in the documentation, and when this doesn’t help, on the internet, you quickly find dozens of ‘workarounds’ or solutions that might have been needed / worked in the past. And this will throw you in the rabbit hole.
To prevent this, I think at first it would be helpful to get better error-messages, pointing to possible solutions, for example in the YAML editing, "Wrong variable ‘value’ used, this item expects a variable ‘message’.
Taking it even further, and this is what I caught myself doing, pasting error messages into ChatGPT, it would explain to me what the error message meant…ohh and it was able to correctly indent my YAML.
I can only think of what an internal Home Assistant -trained AI could mean to help in this. (When an error occurs have an AI-popup-screen display with the meaning of the error and a list of (directions in) possible solutions).
BTW ActionScript really was far from an Abomination (but I can understand this is true in the eyes of a programmer ), it meant non-programmers were able to create the most amazing content!
Absolutely. One needs templating all the time, because quite a few integrations just foreward “raw” data to HA and you need to format them yourself.
Like e.g. to simply convert a wind direction from degrees to human readable text (north, northwest, west, etc.) there is no other way than writing some advanced mapping in YAML, that is by no means acessible to anyone who does not code on a regular basis.
This is not a simple task in any programming language.
So how is this supposed to work without programming?
Specifically now, explain in a syntax how this should work
There was a lengthy and heated discussion in this WTH about why a lot of people here think this is an important technical distinction even though from an non-techie users perspective it makes no sense.
1 Like
I agree with OP in general. It’s worth to say, it’s not only HA. It’s a common problem of a lot software development teams and their products.
It’s proven that developers tends to create user-facing part of system in a way exactly reflecting software internal structure or processes.
It comes from several facts:
- they are not users of their software
- they know well how their sw does work under the hood so they feel no need to make user-facing behavior different
- they have no knowledge or imagination about ouside of their desk (ie designing systems working with local time only or hard linking date format with a language)
- there are no user-journy analysts in dev teams
The most common example are front edit forms and their workflow follows exactly relational database model used by the system.
Let’s look at Hacs current GUI. One page with filters next to useless.
Another example is mentioned NodeRed. To make it working you need NodeRed extended with HA nodes (add-on), NR custom extension , available in hacs, and integration running.
End-user really don’t want to cope with all dependencies.
Speaking add-ons. This issue comes back again and again with every WTH. Users often don’t understand the difference between addon and integration or custom integration. And guess what… HA devs did nothing to this situation.
While I understand the differences I agree that at least naming is confusing. At the end I can imagine installing and maintaining all extensions from single page.
In a lot if cases making interfacing with a user must not be expensive or complex. In others might need additional effort. But if we stand on user site and look from user POV, it hard to jot agree that HA has a huge room for improvement.
1 Like
Thats exactly what I’m saying. I don’t know how this works or even what you mean by “Syntax” in this case. I’m not a developer.
All I’m saying is that as it currently is, you buy e.g. an Ecowitt Weather station and on the Ecowitt App you get human readable wind directions along with a nice animated compass. But on HA you can’t get human readable wind directions without coding in YAML and a compass would require a custom card from HACS that is not easy to set up either.
From a non-techie users perspective this is not and never will be understandable.
2 Likes
THIS exactly - and it makes said software basically unusable for people who have no understanding of software structures and coding.
As a non-developer coming to this forum can be extremely frustrating because some people just tell you that not knowing software / coding is the problem aka. “RTFM” and to “just learn YAML”.
3 Likes