Hi,
I’m only a week or two into using HA and love it.
I’ve been struggling to access the “sensor_state” data of a Wemo Maker within an Automation trigger.
I’m already successfully using a template to get to the sensor_state within a Condition in one automation, but can’t get to the sensor_state within a trigger of another automation.
Here’s the one that works. It will only open the garage if the sensor says it’s currently closed (sensor - off);
First off you should really only ever use a template trigger if there is no other way around it. Because this template will get rendered for EVERY state change of EVERY entity_id. So if another state changes while the sensor state of your sensor (switch.garage_door.attributes.sensor_state) is still on it will fire multiple times.
Furthermore why does your switch have an attribute called sensor state? Shouldn’t that be a sensor on his own?
But to your problem:
You could also try is_state_attr like in my multiline example.
I have had multiple instance where it was only possible to get templates to work by using multiline…in your case this would look like this:
For some reason, when the wemo maker is scanned by HA on startup, it’s relay switch appears as a switch, and the the sensor interface (a part of the wemo maker) appears as an attribute of the switch. I don’t know if it’s possible to manually configure it to be a seperate sensor within HA though…
I’ve input your code and that has done the trick. Now to make the conditions work…
And if everything has been tested to work correctly with a newly created template sensor, you can decide too hide that template sensor (if wanted) by using the customization options to set hidden: true for the entity_id of the template sensor. Same for the physical sensor if needed.
Otherwise your dash will get cluttered with all these kind of (virtual) devices.
This is an old thread but it’s been passed around the chat a lot lately.
It’s referenced to not use a template trigger unless absolutely forced too - So I’m wondering about specifics. We can minimize quite a lot of our automation by being able to render the trigger dynamically, so I don’t fully understand why we wouldn’t.
It’s even mentioned in automation-trigger entirely.
Use Case:
Why not trigger a lights ‘off’ functionality if it’s on. Why make a lights on, and a light off automation - Assuming they both do the exact same thing.
Another:
Using MQTT to ‘remember’ which input source something was at. I’d want it to trigger every time an attribute of that entity changed, which I can’t find any way to do without a dynamic template.
Would love to see specifics as to why templating is bad, or how bad it is to know how much I should be avoiding it.
Second: I built my automation based on the template sensor changing state. As you can see I’m turning my LIFX light to RED when my front gate is open and then turning it off when the Gate is closed.
automation 1:
alias: Turn LIFX to RED when Front Gate is Open
trigger:
platform: state
entity_id: sensor.front_gate_reed
state: 'off'
action:
service: light.turn_on
entity_id: light.courtyard
data:
color_name: red
brightness: 255
automation 2:
alias: Turn LIFX off when Front Gate is Closed
trigger:
platform: state
entity_id: sensor.front_gate_reed
state: 'on'
action:
service: light.turn_off
entity_id: light.courtyard
data:
transition: 3