Using trigger in a value_template condition

#1

This one is driving me nuts… I’m trying to set up an automation that sends a notification whenever the state of a person changes. I want to avoid using from: or to: conditions because I am using zones and there are multiple possible states the person can take. I’ve tried the following:

- alias: 'Nick changed zone'
  trigger:
    platform: state
    entity_id: person.nick
  condition:
    condition: template
    value_template: "{{ trigger.from_state.state != trigger.to_state.state }}"
  action:
    service: notify.mobile_app_nicks_iphone
    data_template:
      message: "Nick is now {{ states.person.nick.state }}. (Previously: {{ trigger.from_state.state }})"
      data:
        push:
          sound: default

and variants like it, but I consistently get an error reporting

ERROR (MainThread) [homeassistant.helpers.service] Error rendering data template: UndefinedError: 'trigger' is undefined

The error message seems to suggest that I shouldn’t use the trigger object in a value_template condition.

The automation works if I leave out the condition, but then I get notifications even when not moving, because the person object receives attribute updates from time to time.

Hoping someone can help!

Thanks,

Nick

#2

I doubt so.
Try changing your condition to something like

{{ trigger.from_state.state != trigger.to_state.state if defined(trigger) else false }}
#3

Just to cover the basics, how are you testing this automation?

If you trigger it manually, from the Services page, the trigger object will be undefined, therefore the action’s data_template will fail.

#4

Don’t think he’s testing it from the Services page because

but who knows…

#5

Hi all - I appreciate your replies. You are of course spot on - I was testing the automation by manually triggering it - not from the services page, but by clicking the automation in the GUI and hitting the “trigger” button.

After posting, I gave up, left home, and was surprised to receive a notification proving that the automation worked just fine.

As you say - and for anyone else who gets baffled by this error - testing from the Services page, or by hitting “trigger” on the automation’s details pane, won’t work because the trigger object is not available to the condition block.

What is quite strange is that I use the trigger object in both the condition and the resulting action. Manually triggering the automation errors out if the trigger object is used in a condition but works just fine if used in an action.

#6

I see you are one of the few special forum members who, curiously, choose to mark their own post as the “solution”, despite the fact someone else offered it to them.

How strange this forum would be if all posts marked as “solutions” would come, paradoxically, from the people who didn’t know the solution in the first place. :man_shrugging:

For future reference, see point #21:

#7

Dude, with the greatest respect, I expressed my thanks and appreciation to the input you and others provided. I actually did mark your response as a solution before realising that it wasn’t quite right. In fact, using the trigger object in an action's data_template does work if invoked from the Services page. It was using the trigger object in a condition's value_template that caused the problem.

#8

Your assertion is easy to prove false.

If you use the Services page to trigger an automation with the automation.trigger service, it will skip the automation’s trigger and condition (if any) and exclusively evaluate the action. As a result, if the action refers to the trigger object, it will be undefined.

It is easy to demonstrate this behavior.

Add this automation and click Reload Automations. You don’t even need to create the input_boolean.

- alias: 'example 1'
  trigger:
    - platform: state
      entity_id: input_boolean.toggler
  action:
    - service: syslog.write
      data_template:
        message: "Previous state {{trigger.from_state.state}}"
        level: warning

Execute it from the Services page using the automation.trigger service.

Screenshot%20from%202019-05-30%2023-19-34

It will produce the following error message:
Screenshot%20from%202019-05-30%2023-20-50

That’s because the trigger object doesn’t exist.

Add an impossible condition to the automation, such as the one shown below. Click Reload Automations.

- alias: 'example 1'
  trigger:
    - platform: state
      entity_id: input_boolean.toggler
  condition:
    condition: template
    value_template: "{{false}}"
  action:
    - service: syslog.write
      data_template:
        message: "Previous state {{trigger.from_state.state}}"
        level: warning

Regardless of the input_boolean’s state, the condition is permanently false therefore the action will never be executed by the input_boolean’s state-changes. However, if you use automation.trigger, it will skip trigger and condition, execute the action, and ultimately produce an error message indicating trigger is undefined.

#9

Yeah, it can be pretty confusing for some to even presume that when triggered manually, an automation bypasses any trigger and condition sections and an action section is executed straight away, but it’s impossible to do otherwise if you think about it.
And because of that all trigger bits are most likely undefined and therefore the practical use of such manual testing is very limited (but still valid for some automations that do not rely on triggers)
Maybe it’s a good idea to update docs to reflect that?

#10

Have you taken a moment to carry out the simple experiment I offered that proves your assertion is false?

Contrary to what you stated, a trigger object does not exist if an automation is triggered from the Services page using the automation.trigger service. Any reference to the trigger object within the action will fail to contain a value. It’s important to know an automation’s behavior differs depending on how it is activated.