I am extremely happpy about the recent-ish addition of an “action” to trigger-based template sensors, in particular because the attributes of the sensors can be used to maintain state.
One seeming limitation here is that unlike scripts and actions, these trigger-based template sensor action blocks don’t support a “mode.” I think I can understand why “parallel” is not a good idea here–we’d have race conditions on the attributes, for example–but it seems like “queued” and “restart” might be doable.
Relatedly, the documentation does not seem to answer the question of what happens when a trigger fires before the action block is done handling a previous trigger. Based on my own (limited) experience so far, it looks like the closest “mode” to the actual behavior is “single” (except no warning is issued if a trigger fires before the previous trigger has been handled).
(On the second point, if it sounds like I should submit a bug–I don’t know, since the documentation as far as I can tell is ambiguous on the correct behavior–I hope someone will let me know, since I’m happy to put together a bug report with a test case.)
Thank you, Petro. I appreciate your responses to my sometimes esoteric questions.
Do you know whether there is a way to tell whether a trigger-based template sensor’s action block is processing a trigger? I am not optimistic, since I’ve noted that there is no entity_id associated with that execution. But if there is, I could conceivably use a “queued” automation to queue (spoon-feed) events for the sensor.
Alternatively, I could flip a Boolean helper at the start and end of the action block, although I think I’d incur some performance penalties and still some margin for race conditions, albeit a reduced one.
In any event, it’s WTH month, so I don’t feel bad suggesting that in an ideal world, we wouldn’t need the workaround
I think there should be ‘queued’ and ‘restart’ mode available. It’s logical, if those sensors are to reliably detect last/current state of whatever triggers them.
I have a simple reed switch radio sensor, which sends a few messages in quick succession. Luckily, their content is the same (“on” or “off”) but I can see a warning in log (“trigger already running”). If such an ignored message brought about a change in state, it would be missed. That’s why being able to queue trigger actions would make a lot of sense.
Just make a script in queued mode and call the script using script.turn_on in the action section. This makes HA fire the actions immediately without waiting causing your scripts to queue.
The limitation of this approach, I think, is that it eliminates a large benefit of the trigger-based template sensor— namely computing variables that can be accessed from the sensor definitions.
script.turn_on does let you indirectly queue the action blocks but you then may as well just use a parallel or queued automation, no? Perhaps I’m missing a piece.
script.turn_on is non-blocking. It immediately fires without waiting. When you use script.turn_on with a script that is queued, the script that you’re turning on handles the queue. Where the action section finishes immediately, i.e. it never runs into issues with ‘single’, ‘queued’, etc.
That’s right, but I think my response was less than precise. I was talking about variables in the trigger-based template’s action block.
In your example, any variables that script.abc sets are not going to be available for use in sensors defined in the trigger-based template whose action block calls script.abc. It’s also not possible to use response_variable to pass values back from the script, I can only assume, precisely because the turn_on call won’t block on script.abc (so won’t wait for it to return anything).
