Cool! How many of them are user interface related?
Pretty much all of them, in one way or another.
most of them.
tip: see <rc.home-assistant.io>
Edit: corrected url, thanks Isabella
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.