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
