Hey all!
Quick question regarding templating, how can I use a condition to check against trigger.event.data.service_data.transition, but only if it exists and is less than 45?
I’ve run into trouble using < in the condition, so this is what I’ve got now:
trigger is a variable. When you wrap it in quotes as you have in your example it no longer functions as a variable because you have effectively converted it into a string without any of the information it previously contained. You cannot compare different data types (string vs. integer) with <…
Leave the quotes off the variables and get rid of the extraneous ‘if’.
{% if trigger.event.data.service_data.transition is defined
and trigger.event.data.service_data.transition < 45 %}
Thanks very much for your insight, I appreciate the explanation. It probably shows but I definitely feel like I’m lacking a fundamental understanding of python. I should have mentioned I essentially try all the code I write both with and without quotes
Your explanation helped though thanks.
Unfortunately your code didn’t produce the expected results, so I might expand a bit on my problem in the hopes it’s because I’m approaching it wrong.
I wrote out a wall of text explaining my approach and with my automation, but as I was writing something clicked and I figured out why it wasn’t working. The condition code now looks like this:
condition:
- condition: template
value_template: |
{% if trigger.event.data.service_data.transition is defined and trigger.event.data.service_data.transition < 44 %}
True
{% elif trigger.event.data.service_data.transition is not defined %}
True
{% else %}
False
{% endif %}
And successfully allows me to filter out the state changes triggered by adaptive lighting and isolate the events that actually turn on a light without throwing an error if the light switch doesn’t support a transition time.
In the interest of clarity I’d like to ask about using trigger.event.data.service_data.transition instead of states() format. The docs have a ton of warnings suggesting to use the latter as preference.
My code cleaned up really quickly once I dropped the states() approach and started working, so am I just misunderstanding the use-case? Is that just for state based triggers and not event triggers?
I’m sure there are others on here that could explain this more accurately… My understanding is that, compared to the state object method, the states() style functions perform a set of checks to guard against specific errors that can occur when the state object doesn’t exist. This is mostly an issue during startup. Automation trigger variables don’t exist at startup, they are created when the automation is triggered, so they are not prone to cause errors in the same way.
Other places where templating is used such as when configuring sensors or using the template platform to define an automation’s trigger need to be constructed using the states() style functions because they are instantiated during startup.
then the following template represents a misunderstanding of the purpose of the state_attr() function (even if the quotes are removed from the trigger variable):
trigger is not an entity, it’s the name of a variable that is defined when an automation’s trigger is triggered. The trigger variable is an object containing information about the trigger. What kind of information it contains depends on the trigger type.
I didn’t log in for a few days but have been templating more and did realised a distinction, although I’m still finding it a bit of a gotcha as some things seem to be attributes and others not without it being clear in the ui.
I’m currently working on the assumption something is a state unless it doesn’t work, in which case I try it as a state_attr
I’m also definitely trying to run before I walk a bit. I know I don’t have my head around some basics I should probably understand outside of context and “that seemed to work”
