WTH: The heavy usage of JINJA2 in HASS is pain in the ass / HASS need a real script engine

Month of "What the heck?!"
81

This gave me pause… are you sure? HA scripts and automations have syntax and keywords and semantics… they have variables and conditionals and loops… they are executed sequentially by an interpreter and even have limited error handling… maybe they didn’t set out to define a programming language but they’ve certainly gone and checked all the boxes so that it looks and smells like one. This is akin to arguing that “python is not a programming language, it’s a configuration for a program that tells the interpreter what to do in order to execute the program.”

That said, I absolutely understand why you want to think of it as a configuration — it’s defined by a markup language intended for configs. Does it get wrapped around the axle sometimes trying to make YAML work like a programming language? Arguably yes (see “conditions” example above, just syntactic vomit), and computer scientists may be correct to characterize it as “bizarre.” But, unlike most languages, it’s very task-specific, and as a result, can be fully written by GUI. And lucky for us, the GUI is so good now we don’t have to look at the code if we don’t want to. I don’t think there’s any argument that storing automations and scripts as YAML configs is holding back the GUI from being a powerful composition interface (and is always improving). Even cooler is that if you don’t like it, you have alternatives like Node-RED and Pyscript and AppDaemon.

This WTH title implies Jinja2 powers HA’s script engine, which couldn’t be further from the truth. Speaking as an “average” HA user I would estimate <5% of my automations and scripts have templates, mostly simple substitutions. But I have many custom-defined entities that make heavy use of Jinja2 templates. While they are daunting at first, the community has been invaluable for learning how to create these entities, and HA is so much more powerful with them.

There are a few WTHs to improve the editor UI, and assisting the user with composing (and visualizing the results of) Jinja2 templates seems like a more consistent approach with better short-term benefits than rethinking the entire scripting architecture. I would urge readers to go vote for one of those.

82

That is most definitely the hangup, at least from my perspective. Execution of a process seems like the wrong use of a configuration paradigm.

It is probably the main reason I have such a problem wrapping my head around how to structure a YAML automation.

2 Likes
83

The issue from my point of view is that you have to view it as a configuration if you want to allow users to be able to interact with it without coding. Coding is more flexible and intuitive if you know how, but impossible to configure graphically and beyond the reach of most people.

84

But using programming languages insteas of yaml would’t prevent making gui on top of them.

85

Would you expect somebody non-techy to learn a programming language to be able to create automations? It would make the barrier of entry much higher and goes against the goal of making home automation more accessible.

1 Like
86

I have the impression we are speaking different languages.

You have suggested (it’s how I understood that) that with other language than yaml/jinja it would be impossible to build automation GUI on top of it.

Coding is more flexible and intuitive if you know how, but impossible to configure graphically and beyond the reach of most people.

I’m answering, that there is no such limitation. You can have GUI (automation editor) on top of any language.

On top of that, I’m not the only one confident that learning the basics of regular programming language (in contrast to yaml/jinja) is easier for beginners because it has cleaner syntax and is less error-prone.

1 Like
87

Yeah I misunderstood you and thought you were saying the opposite, apologies.

I’m not talking specifically about YAML or Jinja, but about having a configuration layer which abstracts the details of the underlying code. How else would you suggest to add a GUI on top of a programming language?

YAML/Jinja is not meant for beginners, and the aim should be that it is not necessary for most things so that people who will never learn a programming language can still configure automations. The vast majority of people will learn neither YAML nor how to program.

88

That simply isn’t true. Just compare what I wrote above directed at you the last time you made the claim that JS was easier. Jinja is clean when you use it the intended way, which is utilizing filters. It’s very easy to learn in comparison to any full blown language. You’re continuously speaking from your prior experience using JS.

I have no idea how you could think this (which requires lambda functions):

var result = jsObjects.filter(obj => {
  return obj.category === "A"
}).filter(obj => {
  return obj.value >= 10
})
return result;

is easier than

{{ jsObjects 
     | selectattr('category', 'eq', 'A')
     | selectattr('value', '>=', 10) 
     | list }}

The concepts in the JS version require a much higher level of coding to understand.

Even comparing to python, jinja is easier because it’s more explicit

return [v for v in jsObjects if v.category == 'A' and v.value >= 10]
3 Likes
89

Such a language is extended with the system specific methods allowing certain operations. The language might be also limited to not allow some constructs not possible to execute in this environment. But the rest of the language remains the same. And must not be “programmed” to provide basic control blocks.

The vast majority of people will learn neither YAML nor how to program.
While it’s true, the author of the OP, obviously has already faced the need to learn it.

A single example doesn’t make justice. yes, it looks nice. This one.
We can start giving an infinite number of snippets to prove the other is wrong, but it doesn’t make sense if people already say that learning other languages was easier for them.

BTW JS is not the only one. There are many powerful tools, for example Lua.

90

It’s just you saying that. Any normal programmer will be able to pick up any language with ease.

We are talking about users here. A full fleshed out language will always be harder than a markdown style language, which is what Jinja is.

EDIT: lua is not easier than jinja… I think you’re being extremely bias with your coding history.

91

I would agree with that if we wouldn’t have been talking about THE combination of yaml/jijna2. This mix (concept and syntax wise) makes it so obfuscated that in my opinion makes other languages easier to learn.

Any normal programmer will be able to pick up any language with ease.

Any programmer can learn any language - true. But still some of languages will be harder to learn than others. Starting from different syntax, through enforced formatting ending with concepts and libraries.

I personally don’t like syntax based on delimiting (thus Python, yaml). So yeah. I’m biased. But on the other side, I learned so many languages that I have a feeling I can generalize an investment needed to learn them.

92

I don’t really follow what you’re saying here in relation to a GUI, from what I can understand you’re saying the programming language should have some API to interact with the home automation devices, but this still requires programming. How would this work with a GUI to eg. program a motion activated light?

93

The topic is JINJA, not Jinja and yaml.

WTH: The heavy usage of JINJA2 in HASS is pain in the ass / HASS need a real script engine

Why does Home Assistant still use JINJA2 templates so often?

Jinja2 templates are difficult to understand, difficult to read and difficult to maintain, especially for people without a developer background.

It would make much more sense to use real languages like Python instead of templates, especially for template sensors, which is a real pain in the ass.

Jinja is great when I mix dynamic content and static content, for example on Lovelace !
But not for Scripts, not for filling own sensors dynamicaly and so on…

In regards to this WTH, OP wants to replace jinja. Which provides no net gain with any of the languages mentioned outside Jinja.

  1. Jinja is built into python with it’s own extenable library.
  2. By default, it’s restricted, nothing else needs to be added to the library.
  3. It’s relatively easy to use.

Any other language would require us to build something into python, then maintain and restrict it. All for what? Something that’s equally as difficult (or more) as Jinja.

1 Like
94

Yes OP mentions Jinja2, but Jinja2 cannot exist (in HA’s automation for end-user) without yaml. Actually, as you mentioned, it doesn’t make sense to talk about Jinja alone.

If OP indeed complains only about Jinja2 alone, then I completely agree with you.

95

That’s not true. Jinja can exist anywhere a string can be input. Template helpers store jinja in JSON for example.

96

I edited my previous post a bit

97

Still doesn’t change my statement. We could completely remove yaml and keep jinja and it would still work the same way.

98

In automations?
Why do we use mixture of yaml + jinja2 then?

99

We use jinja in automations to access things from the state machine and add complex logic in areas when it makes sense.

Jinja is also used in other areas outside automations to do the same thing.

Yaml is not required for any of this.

Again to restate what I’ve said above:

Yaml is just a configuration for the automation.

100

I’m not saying the opposite.
What I think, however, the OP complains about the mix of yaml and jinja when coping with automation (regardless he has mentioned jinja2 only). It’s because I myself think that this mix is unfortunate.
Also at the one side yaml provides “configuration” on the other one it provides the ability to make control blocks in automation. Which control blocks are considered programming prototypes.

At the same time, I agree with you, that considering a replacement for jinja2 alone doesn’t make sense.