While i am really neither familar with Jinja2 nor Blueprint, i am really proud where came already - but now i am stuck with my Trigger Template.
Can somebody, who speaks Jinja2 fluent help me out with a tasty Line of working Code?
Because my Blueprint-Selector can contain multiple entities i want to check several Things for, i need to expand it. With that Line i got it working to trigger to the first entity with matching value:
value_template: >
{% if expand(triggerentities) | selectattr('state', '==', 'on') | list | count > 0 %}
But (of course), it doesnât trigger again when a second entity comes in - as it still is >0.
It only triggers again after the Count went down to 0 before.
How can i make the Template trigger everytime the count changes and is higher than 0?
Or is there an other, better Way, to check for that via Template?
Because of the Goal of the Blueprint and their (really annoying limitations), and after trying so much with other Blueprint-Selectors, i came to the Conclusio it needs to be a Value Template
Really hope there is a Solution and some wise Jinja2-Master helps me out with that
If your goal is to trigger the automation when any entity, in the variable triggerentities changes state, you canât use a Template Trigger (for the reason you have already discovered).
A State Trigger is designed to trigger when any entity, in a given list of entities, changes its state. However a State Trigger doesnât support templating of its entity_id option, only an explicit list of entity_ids.
tl;dr
Thereâs no trigger, other than a State Trigger, that monitors a list of entities, and triggers when any entity in the list changes its state.
NOTE
You may wish to examine Blueprint examples created by others to see how they handle this requirement.
Thank you so much! Really appreciate your Support!
For a couple of Days i am going through a lot of BP, Docs, Trial and Error with plain scripts⌠And ended up giving Templates a Shot, since by using State-Selector / Numeric Selectors i ran into other Limitations i had to learn after hours of trying
In the End for sure one needs to kinda learn that Language with its conventions truely. You canât learn a Language ânot really because i only want to write one Book and then iâm doneâ
But i feel like âYay only one piece of puzzle missing then it can be finnishedâ
Topic:
Dirty Idea: Might it work to filter out entities that got changed the last 3 secs? Wouldnât the Template by that (after 3 secs) go down to 0 again, and be ready to change again to >0 if another entity kicks in?
If so, would you mind helping me tailoring that condition? Sure it should have something to do with selectattr /last_changed / now
If you would need to research as well a lot, no worries! I will make that somehow, too But just not anytime soon - it is just that id love to have a working Base, that i can continue withâŚ
I suggested something along those lines for someone who wanted to trigger when a group (of lights) changed state and then determine which group member had changed state. However, that solution required the use of a Template Sensor (and cannot be used in a Template Trigger).
Not sure what you mean here. If the template is counts the number of entities that are on, and performs the calculation every time an entity turns on, why would the calculationâs result change 3 seconds later?
Well - i donât know if that would be possible anyhow. The Idea would be:
Count every Entity that is on AND last changed is less than 3 Seconds ago.
Obviously wrong Syntax, but just to get the Idea:
{% if expand(triggerentities) | selectattr(âstateâ, â==â, âonâ) | selectattr(âlast_changedâ, â<â, âas_timestamp(now()) -3â) | list | count > 0 %}
I would know how to add the AND to the if-Statement. But of course then it would only evaluate the Result of the if-Statement.
There would need to be a possibility to narrow that expression inside itself down, only to count the entities if they are on AND not older than some seconds, so that the statement would only be true for a couple of Seconds.
The value of last_changed is the time when the entityâs state changed. That template is evaluated a few microseconds after the entityâs state changes. In other words, the time difference between when the entityâs state changes and its last_changed is updated is far less than 1 second.
Given those facts, how do you propose the value of the entityâs last_changed can be more than 3 seconds older than when its state changes?
Mhmm⌠i am not sure if i understand that correctly.
I want to trigger, whenever one of the entities in Scope renders ON.
But with the initial Template from above, it only triggers when the first entity changes to ON.
It doesnât fire when a second entity comes in (Because of count > 0). But i want the Automation to run again if another entity matches the condition, while the first entity might still be On.
Let me try a more concrete Example - maybe i am totally off the Track??
In the Variable triggerentities are 10 entities, all OFF.
Now the sensor.entity1 renders State == ON. Briefly afterwards the second condition (now > last_changed - 3) renders true as well. Now all If-Conditions are met, the Trigger fires the Automation.
Briefly after that, the second Condition (now > last_changed - 3) renders false again. The State of sensor.entity1 might keep State == ON.
But the whole If-Template went false again.
Now sensor.entity2 renders State == ON. And briefly afterwards the second condition (now > last_changed - 3) renders true as well. Now all Conditions are met again, the Trigger fires the Automation again.
The Challenge is, that both conditions must get checked for every entity in the variable.
Does that somehow make sense, or am i getting something totally wrong?
After the template is evaluated, nothing happens until the next time the sensorâs state changes. The template doesnt ârenderâ anything until a sensor changes state and causes the template to be evaluated.
Who damn, now i got it - good you havenât read my first reply
In your first Reply you already quoted:
âThe trigger will fire if the state change caused the template to render âtrueâ when it was previously âfalseââ
I just looked at the âconditionsâ inside the expanded argument, and thought the template permanently gets evaluated against all arguments.
Too bad
Now i really have to rethink the whole Project. Template Sensor is not really practially working Oh my, in this âProjectâ i already encountered so many Limitations, that most probably have their reasons, but are really frustrating to find out after HoursâŚ
I might trigger on every State Change, and then evaluate later in the Conditions or in the If-Statement.
(trigger.entity_id). I would have loved to avoid that, as depending on the Sensor it might trigger quite often, as well as flooding the TracelineâŚ