Using attribute as trigger for automation

[trondat (Trond)]

Solved it by building a template sensor for the attribute set temperature and used a state trigger on that sensor.

When I change the set temperature on the thermostat , the sensor changes and triggers the automation.

[tom_l]

Dammit! That was my first reply but I edited it because I did not think this trigger would work:

    trigger:
       platform: state
       entity_id: sensor.thermostat_room1_setting

Thought you would have to use a numeric_state trigger.

[Mariusthvdb (Marius)]

@tom_l

EDIT: nope that wont work either. Needs to be numeric state platform for a sensor.

why would you say that?
I have this related automation, based on the state changes of all my energy sensors, and works just fine. I’ve disabled it because it senses the change on all of my sensors, and it gets triggered too often… My example below is using the platform: event, event_type: state_changed.

Using trigger: state should result in the same effect?

creating a trigger state for only one sensor should just work?
has the OP tried it?

- alias: 'Activate Map sensors actueel'
  id: 'Activate Map sensors actueel'
  initial_state: 'off'
  trigger:
    platform: event
    event_type: state_changed
    event_data:
      domain: sensor
  condition:
    condition: template
    value_template: >
      {{ trigger.event.data.entity_id.endswith('actueel')}}
  action:
    service: python_script.map_sensors_actueel

only thing one could add is a condition for the state to change more than 1 degree, or half a degree, and not trigger on other attributes of the entity_id (trigger: state also triggers on attribute changes, so have to filter these out if not desired.)

[tom_l]

@Mariusthvdb

why would you say that?

Because I’m an idiot. I’ve been making nothing but mistakes today.

[123 (Taras)]

@trondat

Solved it by building a template sensor for the attribute

VDRainer had provided this solution:

@VDRainer

make a template sensor from your climate attribute

In fairness, it should be VDRainer’s post that is marked as the ‘Solution’.

[pnbruckner (Phil)]

Hey, all. You could do this with just an automation. E.g.:

  - alias: 'Set thermostat room1'
    trigger:
      platform: state
      entity_id: climate.aneks_room1
    condition:
      condition: template
      value_template: >
        {{ trigger.from_state and
           trigger.to_state.attributes.temperature !=
           trigger.from_state.attributes.temperature }}
    action:
      service: notify.pushbullet
      data:
        message: Thermostat is changed

[realthk]

Thanks, it works fine!
I wasn’t sure, because trigger is on the thermostat state which remains “heat” during a temperature setting change, so I would expect no trigger - but it works, indeed…
Could you explain why? State trigger platform perhaps includes all attributes also, not only the main state of an entity?

[AhmadK (akasma74)]

@realthk

State trigger platform perhaps includes all attributes also, not only the main state of an entity?

I believe that’s correct - ANY change of ANY attribute will trigger the state automation even if its state string remains the same. That’s why state objects have last_changed and last_updated attributes.

Actually, it’s literally there:

If only entity_id is given trigger will activate for all state changes, even if only state attributes change.

[Tomahawk]

I can’t wrap my head around why you have to use “trigger.from_state” in the template. Why?
Just want to learn the logic.

      value_template: >
        {{ trigger.from_state and
           trigger.to_state.attributes.temperature !=
           trigger.from_state.attributes.temperature }}

[petro]

That’s verifying that from_state exists because at startup the automation will fire but won’t have a from_state

[Mariusthvdb (Marius)]

@Tomahawk

value_template: >
        {{ trigger.from_state and
           trigger.to_state.attributes.temperature !=
           trigger.from_state.attributes.temperature }}

since that dialog, using this now everywhere where needed:

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

as a default condition to rule them all…

which would translate here to at least do:

  value_template: >
    {{ trigger.from_state is not none and
       trigger.to_state.attributes.temperature !=
       trigger.from_state.attributes.temperature }}

[elRadix]

thank you, works perfect
now i know how to use for other use case

[Tuttle (Tom)]

Hi, sorry to resurrect an old thread, but trying to use a attribute from a device to act as an Automation trigger.

When I go to attributes for my Cat Flap (sensor.cat_flap_cat_flap) under
“Control:”
It shows the following:

curfew:
enabled: true
lock_time: '17:20'
unlock_time: '07:41'
locking: 0
fast_polling: true

That curfew time is adjusted elsewhere in another stand alone app. We change it according to sunset, work schedules etc.
Want I need is the lock_time value to be the trigger for my automation I’m building. So when it hits (in this case) 17:20, I want it to fire as a trigger.

How would I include this into my automation? (this trigger will then ensure the cats’ status is set to “inside” 5mins after this variable time.)

Thanks

[Tuttle (Tom)]

This is my current automation YAML, but I’ve currently just picked the latest possible time we’d ever lock the catflap, and added a few mins (which means, right now, it’s changing their status to “home” well after the flap lock curfew time):

description: ''
trigger:
  - platform: time
    at: '19:01:00'
condition: []
action:
  - service: sureha.set_pet_location
    data:
      pet_id: 'YYYYY'
      where: Inside
  - service: sureha.set_pet_location
    data:
      pet_id: 'XXXXX'
      where: Inside
mode: single

[koying (Chris B)]

Not exceptionally bright, but nothing better comes to mind right now.

Any trigger on sensor.cat_flap_cat_flap will only fire when the sensor actually changes, which will be rare if I understand correctly, and quite surely won’t on, e.g., 17:20

trigger:
  - platform: time_pattern
    minutes: "/1"
condition:
  - condition: template
    value_template: '{{ as_timestamp(now()) | timestamp_custom("%H:%M", True)  == state_attr("sensor.cat_flap_cat_flap", "lock_time") }}'

EDIT:
You could:

• Trigger on lock_time
• Position an input_datetime
• Specify that input_datetime in an at:

That would be more efficient than the time_pattern, but more cumbersome and needs 2 automations.

[123 (Taras)]

Instead of a Time Pattern Trigger, use a Template Trigger employing the template in your existing Template Condition (and eliminate the Template Condition). It will be evaluated every minute, on the minute, because it contains now().

trigger:
  - platform: template
    value_template: "{{ (now().time()|string)[:5] == state_attr('sensor.cat_flap_cat_flap', 'lock_time') }}"

[koying (Chris B)]

Are there advantages to use your “implicit” syntax rather than the “explicit” one?

[123 (Taras)]

Are you referring to the use of the Template Trigger vs Time Pattern Trigger or how the template derives the current time as a string?

For the former, the rationale is “code simplification” and for the latter it’s just “my preference”. I won’t make any claims about improved performance because (for either of them) the differences are probably measured in microseconds.

tl;dr
“more compact”

[koying (Chris B)]

@123

Template Trigger vs Time Pattern Trigger

That one
Ok. Yeah, I’m juggling with tons of stuff, so I’ll definitely have forgotten about “It will be evaluated every minute, on the minute, because it contains now().” in no time, so I prefer “explicit” to “compact” myself

[123 (Taras)]

@koying

I prefer “explicit” to “compact” myself

Why do I now imagine you avoid using a “compact” Time Trigger in favor of an “explicit” Time Pattern Trigger with Template Condition?