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.
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.
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.
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.)
Because I’m an idiot. I’ve been making nothing but mistakes today.
VDRainer had provided this solution:
In fairness, it should be VDRainer’s post that is marked as the ‘Solution’.
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
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?
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.
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 }}
That’s verifying that from_state exists because at startup the automation will fire but won’t have a from_state
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 }}
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:
lock_time
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') }}"
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”
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
Why do I now imagine you avoid using a “compact” Time Trigger in favor of an “explicit” Time Pattern Trigger with Template Condition?