Adding logic and templating to UI of automations / templates

Feature Requests
1

I’ve been using Home Assistant for quite some time now and really like the project.

I’ve seen Home Assistant evolve, and noticed often a new feature is first available for configuration via YAML and later is also configurable via the ui. Which is totally understandable, cause that way of working leads to a working version and from that yaml-only point, work can be done on creating a gui (graphical user interface). The gui seems to me as favourable way to edit settings and options, than with yaml. Although there is still a choice to use yaml if prefered.

At least, that’s what I think is the thought behind it by the largest contributing developers / NabuCasa. I think their goal is to do as much as possible via the GUI ultimately, but also have working versions to build further from. Correct me if see this wrong.

So I’ve seen a lot of developement in the UI of stuff first only being able to do via yaml and now also via the ui.

And many times I see a form of hybrid with both yaml or scripting that is editable via the UI. That if a user needs something specific done, that’s currently not possible via the UI, the user is able to do that. Probably this will always be the case, as it is unlikely that an UI can be created that can achieve the same as being done via scripting. But the presence of both options, UI and code, makes it great software for all types of users.

An example of something that’s ‘hybrid’ at the moment is setting a template sensor via the UI.

afbeelding
afbeelding601×689 22 KB

It is possible to set Name, select the measuring unit from a list of possible values, same for device class and status class.

However for the state template it is still needed to type code. And that’s what this feature request is: it would be a great adddition to Home Assistant if a part of the templating can be done via the UI.

I understand that it is impossible to incorperate everything that can be achieved with scripting in the UI. However I am thinking of the easier stuff like being able to select attributes of a entity and doing simple logic like sum, retract divide, larger then, smaller then. That would already be a great improvement.

For instance “when binary sensor A last change is before binary sensor B last change, return true”
or “retract 1,5 from the value of Temperature sensor X”

So my feature request is to make some of the functionality currently only achievable via code also available via the UI. Personally I think that will be an upgrade where users that aren’t able to code can benefit from.

This can be applied not only on template sensors as above but also within automations where templates are involved.

2

This was mentioned in one of the release party YouTube videos. It is unlikely to happen as templating is such a powerful tool that it is a mammoth task to implement via the GUI.

Some simple options were included (like summing two sensors) and more simple ones may be implemented, but beyond that you will have to use jinja templates.

1 Like
3

Alright, do you happen to know from which release that release party it was? Or maybe an estimate?

4

2023.9 introduced template sensors from the UI so the comment would be in that one.

https://www.home-assistant.io/blog/2023/09/06/release-20239/#template-sensors-from-the-ui

YouTube is blocked where I am so can’t find a cue up the video for you, sorry.

1 Like
5

On a related note, if there’s no escaping jinja, then could we at least have a template eval window so we can see the results of the template (a small version of Developer Tools → Templates)

It would be great to have this in both the Template Sensor UI and as Blueprint/Fields selector.

Edit: Adding an explanation.
The journey to crafting a complex template is not straight forward.

It will help a ton to just be able to do

 {{ states['something']  }} 
{{ state_attr('something', 'someAttr') | int }}

and see exactly what it is, just like in Jupyter notebook or a repl. That’s the exact purpose of Developer Tools → Templates today, but it could be made more convenient in my opinion.

This is also great as a field or selector because today, we have text selectors, but if you throw in templates, it tells at you and tells you to use yaml.

I think it could be done better just by showing the same eval window as the developer tools.

This also makes complex blueprints (like the one in my profile :wink:) more user friendly in advanced use cases.

Edit 2:
The only tricky part I can think of is, in context of automation, templates using trigger data can’t be rendered as they won’t be available at the point of template creation, only at runtime.

1 Like
6

That’s a good idea.

7

Thanks for sending the release version. I just looked it up and scrolled trough the video (see below), they talk about the introduction of the template sensor in the helpers part of the UI from 35:20.

The adding of template sensor to the list of available helpers in the UI was a big step forward.

However I didn’t hear Paulus, @balloob, talk about implementing things to the UI that right now can only be achieved with jinja. He does say that, for the introduced template helper, they chose to make one field available as a code field in which templating code can be added. A preview of the output of the code is displayed in the UI.

That’s right, with the Min/Max Helper. I actually never used it, just always have used templating. But good that it can be done via the UI. However that might be something I consider a slight problem with helpers, that it creates a new entity. If I use templating within within an automation I don’t have to create a new entity. Keeping things cleaner and within one screen. Helpers I see more for something that’s reused a lot.