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

Month of "What the heck?!"
21

It is used to configure the automation integration.

You seem to have this incorrect assumption that yaml is used as the language for the automation “program”. It is not. Automation is an integration written in Python that accepts options you can configure with yaml. The options provided by the integration (triggers, conditions and actions) do not provide the underlying logic. That is all python. Take the choose action as an example, it looks like you are writing a program branch in yaml, but the action is provided by the integration, all you are doing is providing options for it in yaml (configuring it). You are configuring a pre-defined action that the integration provides, not writing a program.

2 Likes
22

That will always be required regardless what language is choosed, it’s required by yaml not jinja.

Here’s the limitations in jinja in comparison to python:

  1. Loop scope. You can’t increment things without using namespace. The good news is, if you actually spend time learning jinja (or ansible), you won’t need loops. Take time to learn filters and how to apply them. They are generators.

  2. You can’t modify memory, only create. This means dictionaries and lists are immutable.

    You can get around lists by using namespace or list addition.

    {% set x = ['a'] %}
{% set y = x + ['b'] %}

    You can get around dicts by creating new dictionaries from existing ones.

    **kwargs

    {% set newdict = dict(x=4, **other_dict) %}

    use from_keys

    # The list of tuple should be [(key, value), ...]
{% set x = dict.from_keys(list_of_key_value_pairs) %}

  3. No in-line for loops. But you can do inline if statements: x if 1==1 else y

  4. the is None test in python is equal to is none in jinja.

  5. You have to designate statement lines ({% %}), output lines ({{ }}), and comment lines ({# #}), and control your whitespace with -'s to remove leading whitespace ({%-) or trailing whitespace (-%})

With all that being said, if you learn what a filter is and what a test is, Jinja is really easy. Use vscode to save on typing {{ and {% double side as it will autofill for you.

If you want Jinja tutorials, look for ansible tutorials. ansible is an extended version of Jinja, and it’s widely in IT.

Lastly, I maintain quite a bit of templates across HA. Regardless how many votes this gets, I will fight tooth and nail to keep Jinja. That doesn’t mean something else can be added, but replacing jinja is out of the question.

3 Likes
23

If you have broken fingers, you’re doing something very wrong. :wink:

I have been writing templates for myself, and for literally hundreds of other users, for over six years and have no complaints about Jinja’s syntax. It’s just something you learn (and it’s fairly easy as far scripting languages go).

  • together with the correct indentation of the YAML config file it will get unreadable and you often have syntax errors (its hard to find them)

If your preference is to compose automations directly in YAML (which is a choice and not recommended for new users), I suggest using a text editor with a YAML checker. For example, the VS Code Addon which also comes with Config Helper.

  • Jinja has many limitations … no good variable / object handling ( or it’s not documented well ??? or they won’t work with HASS) everything what is a little bit more dynamic won’t work…

Your comment leads me to believe you’re not entirely familiar with Jinja2. Home Assistant’s documentation provides an introduction to Jinja2, along with Home Assistant’s extensions to Jinja2, and a link to Jinja2’s complete documentation (because Jinja2 is a separate open-source software project … like python).

1 Like
24

We are drifting from the original subject and getting toward academic discussion, Tom. C++ source code could be also interpreted as a “configuration” for a compiler.

I agree that in HA, yaml/jinja provides configuration data to automation integration.
Maybe it’s the whole deep point of debate.
HA is trying to achieve functionality reserved for programming languages with use of configuration files.
See control blocks like ifs loops etc or code reusability (very limited in HA, limited to jinja templates afaik). Some of those features were not existing not so long ago. Some still don’t exist. because as you said: it has to be programmed into the integration that interprets those data.

I’m not saying it doesn’t work. It’s just not natural, it’s obfuscated by a combination of yaml and jinja syntaxes. By its nature, it cannot be as readable as other programming programming languages.
Moreover, it creates own dialect, used no more outside of HA. Which also doesn’t help learning that.

In other words, HA uses tools for purposes they haven’t been created for.

We can spend endless hours with counterargumentation. But people are saying it’s utterly complicated. And I understand them.

1 Like
25

It has worked very well for years and has made the transition to providing a GUI extremely easy for the developers. And thus easy for the end users too.

26

Yes. And still remains complicated once user need to go beyond what GUI provides.
I am not saying that the GUI is unreadable like hell. At least on big monitors. Probably mobile devices benefit from this design more.

27

It is still being developed. Come up with a concrete practical improvement rather than these “philosophical” ones and ask for it to be implemented.

28

I did it ones, then petro shoot me down.

29

it’s arguably way more readable if you learn filters.

with a list of dictionaries:

 [
    { id: 1, category: 'A', value: 10 },
    { id: 2, category: 'B', value: 20 },
    { id: 3, category: 'A', value: 15 },
    { id: 4, category: 'B', value: 5 },
]

in js getting a list of categories for example"a"

var result = objArray.map(a => a.category);

in jinja, almost identical

set result = objArray | map(attribute='category')

or filtering in js

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

in jinja

set result = objArray | selectattr('category', 'eq', 'A')

what’s better? They both do the same thing with slightly different syntax. Just because you are familiar with one over the other does not make it better for the task at hand.

1 Like
30

:roll_eyes:

31

I shot down what?

32

You asked me (as a moderator) to not continue about alternative I proposed.

33

I asked everyone to stop talking about node red

34

The OP’s comments imply a lack of familiarity with the subject matter. It’s an identifiable theme in WTH posts, especially the ones that are hyperbolic.

3 Likes
35

yes, afterwards.
Your first action was a private message with an order to stop talking about NR.

36

I suppose that all users reporting issues with understanding yaml|jinja might fall into the same category. Pushback is natural reaction if one has to cope with things that look complex by a glance. At the same time the same users are familiar with programming languages… so it’s not because they are stupid or lazy. They are likely comparing experienced complexity ang give you feedback.

Nobody is saying automation doesn’t work.
What users report is that the entry investment si too high.
If someone asks for an alternative we can give one of many. usually the one we are comfortable with. They must not be perfect ones either. But I feel this subject will be back again and again every year.

37

And the push is to move away from needing to use Yaml at all. It will still be optional for everyone who likes it. That’s what’s mind bending about these Yaml too hard posts, HA is actively making YAML optional everywhere. We are already doing it, so why keep mentioning that Yaml is hard?

This is the first jinja one this WTH, and just like the last WTH and the one before it, it will likely get few votes. 10 votes does not mean “everyone dislikes it”. If it was the most voted WTH that would be a different story.

38

Moving towards what? UI? (Just curious…)

39

Yes UI.

And moving to Node Red is not an example of suggesting an improvement to the editor. It is substituting the editor completely.

4 Likes
40

Indeed, though I suspect he was actually suggesting that we switch to a editor similar to the one in Node-RED, which would, at least for me, reduce the usability of Home Assistant for what it was originally designed to be; an automation platform.

1 Like