Cool! How many of them are user interface related?
Pretty much all of them, in one way or another.
most of them.
I know I’m late to this thread, and unfortunately missed the month of WTH to be able to post individual parts of this as their own thing, but I figured I’d share here since it’s been stuck in my head and it’s a fine example of the frustrations a new user can face.
I’m a developer by profession, and I’ve used HA before, I’m returning after many years away (at least 5 years). Obviously it’s improved a TON in that time, especially in how easy it is to join new devices.
(I was writing a novel, but I’ll give the condensed version)
- I built an Automation with the UI, it worked great, but I realized I’d be duplicating this for every single lightswitch and need to go through and update all the entity references, and that maintaining it if I ever needed to make changes would be a headache
- I decided to rebuild it as a Script, which also has a UI, allowing me to rebuild my automation in the exact same way as I did using the Automation interface (so… why isn’t there a “convert Automation to Script” option?)
- The Script also includes a UI to define Fields which work as input parameters for the script, but there’s no way to select these Fields in any of the UI components (so… why even provide a UI for creating these Fields? If I can only use them by editing YAML, having a UI to define them is just confusing)
- Even if you crack open the YAML generated by the UI components, many of the most fundamental components (such as the “state condition”) don’t support providing a dynamic Field value as the entity ID, instead you have to use a “template condition”, with a template that compares the state (so… if any state condition could be rewritten as a template condition with an is_state() check, why doesn’t the UI just generate the “template condition” instead?)
- Additionally, this process is where run into a frustrating knowledge gap… the UI generates a bunch of YAML that uses Device_IDs, but as we all eventually learn, you should avoid using Device_IDs (so… why is the UI for so many actions generating YAML that uses Device_ID instead of Entity_ID?) [I know this is it’s own giant can of worms, but it is something that stands out in particular when trying to “translate” the UI-generated YAML into an appropriate “Field-capable YAML”
I’m sure this issue is just a growing pain because I jumped back in at a point where the UI tools were polished enough to FEEL like they provided everything I needed, when the reality is that behind the scenes a lot of stuff is still being built for that final 20% of functionality. I know from experience that nothing is ever as simple as “just do this”, so my above comments are not intended as criticism or instructions for the developers, but rather capturing the frustration I felt when my perception of what I expected the tool be able to do did not match the experience of what I had to do to make it work (which is, I think, the fundamental idea that this thread was originally trying to convey).
That said, once I adjusted my understanding of “the state of the tooling”, I was able to build what I needed, and when I ran into an issue where I had a confusing gap in my knowledge, the community was extremely helpful and responsive to help me figure it out.
P.S. because no list of perceived problems would be complete without a pie-in-the-sky “simple sounding, but probably impossible” wish: It would sure be great if every single trigger/condition/action would treat a “hard coded” entity (e.g. light.light_livingroom) the same as a field variable (e.g. lightField). I’m sure there are technical reasons behind the scenes it doesn’t work this way, but it would be amazing if that reference to “what entity should this use” could be resolved as-needed, and not have the painful separation of some things that support dynamic entities, and some that will only work with hard-coded entities.
If you run the script from the dashboard, there’s a pop up with UI to fill the fields. So it’s there at least for this purpose, completely in UI. I know this is different use case than yours, just providing an explanation why the fields are even in UI in the first place, AFAIK.
Sure, you can use the UI to make fields that show up in a pop up and you can fill them in, but what does that accomplish? Those values get piped into your script as Fields and then… nothing, there’s no way to actually USE those values in any of the UI components in the Script editor, you have to write YAML to be able to do anything with the provided values.
I agree that it (ultimately) makes sense to have the UI to define the fields, because they are a well-defined object that is intended to provide a UI for users when configuring the calling the script from an automation. I’m just calling out that end-users will likely find it confusing that they can use the UI to build the “Light Selection Form” and they can use the UI to build the “Turn on this specific light”, but there is currently no way to use the UI to say “Turn on the light the user selected in the Light Selection Field”.
Ahhh, that’s what you meant. Ok, you are right. I have forgotten that I used yaml for that.
Those elements are available though. Are you using script.turn_on or calling the script directly?
here’s a script I made using fields in the UI
You can use the UI to:
- Define the Fields for a script
- Configure the values for that script when calling it
However you CAN’T (currently) use the UI to:
- Use the values provided in the Fields as entities in the conditions/actions within that Script
In other words, using the UI, I can build a script that takes “Light_To_Turn_On” as a Field, and the user can select a light from the list, but unless I write YAML in my script, nothing in that script can do anything with the “Light_To_Turn_On” field, it just disappears into the void, because none of the UI components have any way of selecting the Field as a choice (currently).
They aren’t entities, you use them as variables through templates.
There’s a WTH to make swapping between templates and the UI easier without going to yaml. If that’s what you’re talking about.
HA is multiple years away from anything remotely close to that.
Yeah, that’s probably at the core of what I’m discussing… like, in my mind a “variable that points to an entity” should be able to used in all the places you currently use “entity” for purposes of building stuff with the UI. Right now there’s a nice UI to let me define a Field to accept selection of an Entity when calling the script, and a nice UI to let me select an Entity for a Condition or an Action within that script, but there’s no UI to allow me to select “the entity that was provided in this Field” as a value in UI of the Condition or Action.
(EDIT: And as a developer, I know that this is often a VERY tricky knot, so this is from the perspective of “how I as an end user would like it to work”, and not “here’s one simple fix to make it better”)
It doesn’t point to an entity though. It’s a local variable, that is only usable in templates and it’s not stored under the hood (which is a separate WTH).
I think a problem you’re having right now is understanding what an entity is. And yes, that’s a steep learning curve.
An entity is something that is represented in the state machine (hopefully you’ve built one of these before, or used one in your line of work). Where the fields in the script are local variables only, they have no representation outside the script.
Anyways, I think what you’re really asking for is the ability to use variables in fields that the variable contents would be allowed to go in.
I.e. The selector used for the variable/field would determine which other fields you could assign it to and it would just build the template for you. Keeping in mind that only some fields accept templates.
I think you’re very much right, there are some huge gaps in my knowledge, and unfortunately a lot of the terms HA uses are already overloaded in my brain with their own definitions that don’t necessarily match how HA uses them.
Thank you for providing some clarification on that difference… I think part of my struggle is also that the YAML only defines the configuration, it’s not actually the “execution”, (i.e. if it was just a matter of “step through the YAML file and execute each step”, then the sort of substitution I was suggesting would be fairly easy) so while the difference between:
condition: state
entity_id: light.light_hallway
state: off
and:
condition: template
value_template: "{{ is_state(var_lightswitch, 'off') }}"
is trivial in YAML, the reality of how they execute behind the scenes is significant.
(In which case, having UI to generate template-based YAML would be one solution, but obviously that’s just creating an entirely separate set of UI components to maintain)
Yes, I think that’s probably the solution that I’m looking for which would make the process feel smoother.
And then perhaps the “deeper” solution over time would be to increase the number of places templates could be used, or have the UI for some components adjust the underlying approach as needed (the simplest example I keep coming back to is having the “State Condition” swapped for “Template Condition with is_state()” when the user selects a Field variable for that condition…)
Thanks for sharing your perspective. I knew these things on the surface but they had not really landed yet, and hearing them from someone who has just found out helps me. I think I am starting to understand why I sometimes don’t understand what I’m doing when writing automations… I still think I am writing the code.
Just a sidenote to address your having to repeat automations and ending up making a script: You might want to look at automation blueprints.