Extend template shorthand notation syntax

Feature Requests
1

Hi there!
I have a quick suggestion and want to see whether people agree with this idea or not.
The docs suggest this syntax:

conditions:
  - "{{ (state_attr('device_tracker.iphone', 'battery_level')|int) > 50 }}"
  - condition: state
    entity_id: alarm_control_panel.home
    state: armed_away
  - "{{ is_state('device_tracker.iphone', 'away') }}"

So far, so good.
However, I think it’d be cute to be allowed to use this syntax too

conditions:
  - condition: "{{ (state_attr('device_tracker.iphone', 'battery_level')|int) > 50 }}"
  - condition: state
    entity_id: alarm_control_panel.home
    state: armed_away
  - condition: "{{ is_state('device_tracker.iphone', 'away') }}"

because that is the syntax of condition actions already:

actions:
  - delay "01:00:00"
  - condition: "{{ is_state('device_tracker.iphone', 'away') }}"
  - delay "01:00:00"
  ...

Less things to memorize and more ‘consistent’ syntax.
Let me know what you think. :yum:

2

Actually, the shorthand notation for a Template Condition has been around for a long time, much longer than the shorthand condition notation used in an action. It was only introduced in the current release (2022.2). It needs the leading condition: key because without it there’s no context for the YAML processor.

In contrast, the condition key is superfluous, for shorthand notation, when used in an automation’s condition because the context is understood.

BTW, there’s a syntax error in your example; delay is a key so it should be followed by a colon.

1 Like
3

Yes, I am aware. My suggestion isn’t because I think the logic is flawed, but rather to make the syntax easier to memorize and make it more consistent from a user point of view.
Keep in mind I’m only suggesting an extension of supported notations, not a complete overhaul. That’s why I think supporting a superfluous yaml key would be benefitial if it helps usability.

yes, that missing colon was because I rushed it :grinning_face_with_smiling_eyes:

4

In the quest for consistency, it makes shorthand notation less shorthand.

I feel it’s superfluous because the context is already established by the leading conditions key as shown in this choose example from one of my automations:

Screenshot from 2022-02-15 14-10-01
Screenshot from 2022-02-15 14-10-01777×136 17.3 KB

Your proposal permits adding it to every line (containing a shorthand Template Condition), even though the conditions key has already established it contains nothing but conditions.

In other words, this isn’t enough:

cats:
- persian
- siamese
- tabby

but should also allow for:

cats:
- cat: persian
- cat: siamese
- cat: tabby

and only because elsewhere this is permitted:

- dog: alsatian
- bird: jay
- cat: siamese
- color: red

Anyway, you’re certainly free to suggest it. It remains to be seen if a volunteer developer accepts the challenge to implement it and to convince the core development team to accept it.

5

Yes, thank you for your explanation, I am aware. :sweat_smile:
Exactly, that’s why I am posting, to see if anyone agrees.