Preferenced format value_template?

Configuration
1

hi,

up to now many of my automations had condition value_templates based on state:

  - condition: state
    entity_id: input_boolean.notify_presence
    state: 'on'

this is a way to write the same (i believe), which at least has my visual preference.

  - condition: template
    value_template: >
      {{ is_state('input_boolean.notify_presence', 'on')}}

Added to that, it seems less error prone or more robust. Probably impossible, but still: would there be ay preferenced way of doing this?

same for:

  - condition: template
    value_template: >
      {{ trigger.to_state.state is not none and
         trigger.from_state.state is not none and
         trigger.to_state.state is in ['home','not_home'] and
         trigger.to_state.state is not trigger.from_state.state }}

or

  - condition: template
    value_template: >
      {{ trigger.to_state.state != none and
         trigger.from_state.state != none and
         trigger.to_state.state is in ['home','not_home'] and
         trigger.to_state.state != trigger.from_state.state }}

thx

2

Yes

Not really, it’s the same.

Do whatever you like, both ways of writing this are identical. The startup may take a nanosecond longer on the value template because it has to parse the string.

That can only be in a condition or action because it’s using the trigger object. I’m not even sure why you have the condition like this? There may be a way to check out the trigger type instead of this to_state != None and so forth.

3

thanks, if been struggling a bit, but am getting closer, thanks to the config checker… (not)
think it should be:

  - condition: template
    value_template: >
      {{ trigger.to_state.state is not none and
         trigger.from_state.state is not none and
         trigger.to_state.state == 'not_home' and
         trigger.to_state.state != not trigger.from_state.state }}

at least thats what passes now.

not sure about this:
can i use a condition value_template like this, without stating from: and to: in the trigger? Somehow this seems related, thought is was possible, but some of my templates give me a hard time.

this seems alright (at the moment) and has most uncertainties in it :wink:

  - alias: Presence Tracking
    id: 'Presence Tracking'
    trigger:
      - platform: state
        entity_id:
          - device_tracker.iphone
          - device_tracker.telefoon
    condition:
      - condition: template
        value_template: >
          {{ trigger.to_state.state is not none and
             trigger.from_state.state is not none and
             trigger.to_state.state is in ['home','not_home'] and
             trigger.to_state.state != trigger.from_state.state }}
      - condition: template
        value_template: >
          {{ (now() - trigger.from_state.last_changed).total_seconds() > 120 }}
      - condition: template
        value_template: >
          {{ is_state('input_boolean.notify_presence', 'on')}}
    action:
      service: notify.m
      data_template:
        title: 'Presence Tracking:'
        message: >-
          {% if trigger.to_state.state == 'not_home' %}
            {{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}}
          {% elif trigger.from_state.state == 'not_home' %}
            {{ trigger.to_state.attributes.friendly_name }} arrived at {{trigger.to_state.state}}
          {% else %}
            {{ trigger.to_state.attributes.friendly_name }} left {{trigger.from_state.state}} and arrived at {{trigger.to_state.state}}
          {% endif %}

btw found the error typo… at last, after having to disable all my automations and checking them 1 by 1…

        value_template: >
          {{ trigger.to_state.state is not none and
             trigger.from_state.state is not none and
             trigger.to_state.state is in ['home','not_home'] and
             trigger.to_state.state != not trigger.from_state.state }}
4

forgot to answer you, sorry.
main reason was to prevent the automation from triggering too often, and on wrong triggers (attribute changes trigger the platform: state too, and these phones change attributes very often, apparently especially the iPhones, which disconnect from wifi for battery saving policy.