Using attribute as trigger for automation

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 }}
1 Like

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

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

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

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.

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') }}"
1 Like

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

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” :slightly_smiling_face:

That one :wink:
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 :slight_smile:

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

Thanks for all the replies and suggestions.
I tried 123/Taras suggestion, but it has never triggered (2 days now where that time has occurred and the curfew has been implemented) any ideas why?

Edit: my formatting was different, have ensured it matches yours and will try again. Cheers for the help again

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

It’s possible to do every seconds update?

The template employs the now() function which causes the template to be evaluated every minute; now() cannot be forced to evaluate every second.

For more information about how frequently a template is evaluated, refer to: Rate Limiting Updates

1 Like

Yes, thanks, I’ve already understood this.

You can make a template binary_sensor that evaluates every second and use that as the trigger.

template:
- trigger:
  - platform: time_pattern
    seconds: "/1"
  binary_sensor:
  - name: Lock
    unique_id: lock_time
    state: >
      {{ (now().time()|string)[:5] == state_attr('sensor.cat_flap_cat_flap', 'lock_time') }}
1 Like

I’ve input.number for Google speakers volume control like this:

    - alias: "Google Mini Hall Volume Control"
      trigger:
      - platform: state
        entity_id: input_number.google_mini_hall_volume_control
      action:
      - service: media_player.volume_set
        data_template:
          entity_id: media_player.google_mini_hall
          volume_level: "{{ trigger.to_state.state }}"

And my question was about volume sync when it changed outside of HA. For this case I made something like this:

    - alias: "Google Mini Hall Volume Sync"
      initial_state: false
      trigger:
      - platform: state
        entity_id: media_player.google_mini_hall
      condition:
      - condition: template
        value_template: "{{ not is_state_attr('media_player.google_mini_hall', 'volume_level', states('input_number.google_mini_hall_volume_control') | int / 100) }}"
      action:
      - service: input_number.set_value
        entity_id: input_number.google_mini_hall_volume_control
        data_template:
          value: "{{ state_attr('media_player.google_mini_hall','volume_level') | float(0) | round(1) }}"

It’s work like a charm but, I noticed a problem when third-party automations are triggered, when, for example, a group speakers is used that includes the current speaker and the volume of this group changes before the TTS message - the current speaker falls out at 0% volume. Until I got to the solution, and currently I had disabled automation above.