Condition shorthand syntax recommendation

Configuration
1

It’s not clear which condition syntax is the preferred from HA’s side - if any is.

Take a look at these two that express the same logic:

Syntax 1 (long format):

- choose:
    - conditions:
        - condition: and
          conditions:
            - condition: or
              conditions:
                - condition: template
                  value_template: "{{ 1 == 1 }}"
                - condition: template
                  value_template: "{{ 2 == 2 }}"
            - condition: template
              value_template: "{{ 3 == 3 }}"

Syntax 2 (shorthand form)

- choose:
  - conditions:
      - and:
          - or:
              - "{{ 1 == 1 }}"
              - "{{ 2 == 2 }}"
          - "{{ 3 == 3 }}"

The shorthand form in Syntax 2 is unbelievably simple compared to the long form in Syntax 1. It’s almost enjoyable to read. (I said “amost”, okay? :smiley: )

The long format reminds me of having to look at abstract syntax trees for the code I am writing in other programming languages. It’s understandable that the extra metadata needs to exist at some level between the user and the machine, but it should mostly be hidden from the average user. Support could exist for the cases where that extra flexibility of expression is needed - just as the option to write iline assembler instructions in C++.

However, the automation editor keeps rewriting shorthand to long form, which is quite annoying.

Should I take that as a hint that the core team prefers the long form syntax?

2

You could make it even shorter, with all of the conditions as one template. Then the visual editor won’t be able to expand it back out into that extremely long form again, but you lose the ability to see what each part of the expression evaluated to in the traces.

But yeah I also prefer the shorthand format, and absolutely hate the excessive default indentation of lists. For this reason I write all automations from scratch in separate files which will not be butchered by HASS.

3

Also as conditions are AND logic by default you can shorten it even further:

- choose:
  - conditions:
      - "{{ 3 == 3 }}"
      - or:
          - "{{ 1 == 1 }}"
          - "{{ 2 == 2 }}"
4

Density is not the goal, but clarity and comprehension is.

I like that the operators are clearly stated, but your example is still interesting as I was not aware - thanks :slight_smile:

5

Thats a clever workaround to hide it from the parser and avoid it getting serialized back into the longform format.

I haven’t thought too long about it, but could there be a performance penalty in terms of parsing when running the operations as templates rather than direct operations? I am not sure when and how often the automation is parsed and into what intermediate format (if any) before it’s executed. Might have a look in the source …

6

It’s not a “workaround”, it’s a recognized option for people who prefer to compose their automations in YAML with a text editor (as opposed to using the Automation Editor). I’ve been doing this since I started in 2018.

No.

Shorthand versions were created for the convenience of people who prefer to create automations in YAML with a text editor.

For people who use the Automation Editor in Visual mode, the YAML code’s appearance is moot; they’re unlikely to be reviewing their automation in YAML mode.

The designers of the Automation Editor gave it strict formatting guidelines which favor the standard, verbose format (as opposed to the optional, shorthand format). If you use the Automation Editor in YAML mode to manually compose something in shorthand format, it gets converted to longhand.

For that reason (and several others like YAML comments aren’t supported) people who are comfortable composing in YAML don’t use the Automation Editor. I have been using Visual Studio Code with the Home Assistant Config Helper plug-in.

7

You are right, but there is another group of users.

There is a somewhat large group of non-programmers scouring these forums, looking for blueprints or automation snippets that they can use to wire up the solution they need. They are stuck somewhere in between where they will probably want to convert as much as they can into something that can be tangibly viewed in the editor, while being forced to mix it with snippets they find here. I feel that we lose them by not going all in on making the simple representation the first-choice in all situations. Fine to have the fulll representation supported for edge-cases.

8

By “simple representation” you’re referring to the shorthand version that employs templates and templating isn’t always the simplest choice for the “non-programmers” group you mentioned.