I created a Template Switch, and here’s what I observed:
The actions defined in the switch (e.g., action on turn_on) are executed when the Template Switch receives the on status from the integration, even if the Template Switch is already on.
However, if I use the Template Switch as a trigger for an automation, the automation does not fire.
To work around this, I manually trigger my automation (test_alexa) in the turn_on and turn_off actions of the Template Switch using:
action: automation.trigger
metadata: {}
data:
skip_condition: false #I also tried true, no different behavior
target:
entity_id: automation.test_alexa
But this leads to strange behavior. When the Template Switch changes from off to on, the automation incorrectly evaluates the condition for off. Only when I send the on status to the Template Switch again does it evaluate the correct condition (on). I added a 3-second delay, but it didn’t help. Every time the switch state changes, the automation initially evaluates the wrong condition on the first state change.
Where could this issue come from?
Is using a Template Switch the best way to handle this, or is there a simpler and more user-friendly solution?
You put the actions that the automation would do in the template switch action on section. You don’t use the automation at all. Or you make a script and call the script.
The automation inside the template is not an option because it would make the logic harder to manage and maintain. I have complex automations and want to be able to disable them when needed without affecting the Template Switch functionality.
I replaced the automation with a script and added it to the Template Switch, but it shows exactly the same behavior. On the first state change, the conditions in the script are evaluated incorrectly.
alias: Test Alexa Schalter Script
sequence:
- delay:
hours: 0
minutes: 0
seconds: 5
milliseconds: 0
- choose:
- conditions:
- condition: state
entity_id: switch.testschalter
state: "on"
sequence:
- data:
message: Template switch ON
action: notify.persistent_notification
- conditions:
- condition: state
entity_id: switch.testschalter
state: "off"
sequence:
- data:
message: Template switch OFF
action: notify.persistent_notification
mode: single
description: ""
I implemented the code, and it now works reliably — thank you for that!
The reason I originally used an automation is that I don’t want to rely solely on the Template Switch as a trigger; I also want to include other triggers. For that, I would need to create additional automations for those triggers, which would then call the same script. Is that correct?
This approach works, but it involves more effort compared to introducing a new trigger for automations, like a “received update” trigger.
Am I the only one who finds this a bit less user-friendly, or do you think such a new trigger would be a worthwhile suggestion?
I doubt a on → on trigger would ever happen because so many people used to fight those in the early days of home assistant. In the early days, everyone worked really hard to suppress triggers that shouldn’t have happened when an same state trigger occurred.
Thank you for the insight! I can understand why suppressing unnecessary triggers was important in the early days to avoid unwanted behavior. However, I think there are now valid use cases where a same-state trigger (on → on) could be beneficial, especially with more complex setups like mine.
Perhaps it could be implemented as an optional feature that users can enable for specific automations if needed. This way, it wouldn’t interfere with existing setups but would provide more flexibility for those who require it. What do you think?
This case has always been here from day one. Check my post history from 2018 solving this problem using a template switch.
EDIT: I’m having trouble finding the post…
EDIT: Ok found it
It covered alot of topics, but the reason I created those activity switches was specifically for utterances via alexa. So that regardless of the state of the switch she would still fire the action.
This is what template switches are for, they are made so you can replicate a physical switch device. Where an input boolean is more like a helper that lets you store an on/off true/false state.
You’re probably not the “only one” but you are likely in the minority by far. I believe you are being biased by your past patterns from your old software, which Home Assistant is not. My advice is to embrace the patterns that are proven and tested within Home Assistant and compensate for any historical bias from other software. I came from 20 years of HomeSeer, which had significantly different automation functions and keywords and no looping at all. You learn to get past it.
I’ve followed the arguments for triggering on “same-state” with interest, but honestly I find them mostly contrived. The only reasonable one I’ve seen is related to calculating advanced statistics, which also seems like a feature that frustrates a minority of users.
I frequently marvel at the request to provide functionality that at least on the surface seems to be easily manageable by conditions.
Outside of some special case administrative “nice to haves” I really don’t see why you need to disable automations in day-to-day usage. Isn’t that functionality basically the same as a hidden entity and hard-coded condition anyway?
I’ve added a 3rd and 4th example to my post above.
I will admit I haven’t been able to find an example yet that cannot be worked around unless it pertains to numerical analysis. It is absolutely necessary to trigger off state_reported events for proper numerical analysis but usually this is done by an integration rather than an automation or template sensor.
The other examples (1-3) are simply methods that users typically think are more logical to implement instead of the existing alternatives.
What happens when manufacturer of your device updates firmware and starts reporting every 1 minute? Or every 5 minutes? Because you want consumption over last 2 minutes, right? Wouldn’t it then be better to have a automation to run every 2 minutes? Of course you’d have to store last state in some helper, but at least you have total control over the computation. What if the firmware update changes to report state every 30 seconds, and you’d think it’s a consumption over 2-minute window? Not great I guess…
I quite still don’t see why would anyone want to let that time-window-size decision up on the manufacturer? The manufacturer decides to report every 1 minute, so my check will tun every 1 minute? Then, with firmware update, they “optimize” it to 5 minute, so my check changes to 5 minutes? And then, finally, they hire some actual developer and not a baker, so the reporting changes to “only when state changes, but max 1 hour”, so my “inactive device check” changes again for whatever the manufacturer wills?
I don’t know, but to me it seems much more logical for me to decide whether I want to check once a day, or once an hour, and list all devices that didn’t report in last day/hour and notify me about it (=unresponsive device). Let’s say every morning at 7am get a notification with list of all devices that didn’t report in last 24 hours? Or get that list evert hour if I want? But who decides that, me, or random device manufacturer?
Again, being able to trigger on last_reported might be valid request, but for most cases it’s just wrong point of view on what you actually want.
In this case it’s an ESP and I am responsible for the firmware, so not an issue. I am trying to get the change between each reading, and if I could get the device to read & report faster I would.
To be frank, the correct way to implement the behavior I want is to update the derivative integration so that it triggers on the state_reported event. I know for a fact that a PR for that improvement would be accepted; it just hasn’t been done by anyone yet. And I’m not smart enough to do it myself, so having a template sensor trigger off the last report is technically a workaround, but I’m unable to implement that either.
A 2-minute time pattern trigger is an even less optimal workaround. The trigger could be up to 2 minutes delayed from the report since they are not synchronized.
The workaround that works best is to use 2 triggers: one for state changes, and one for state changes using for: with 2 minutes and 1 second, so that it can update to 0 when no state change is detected for over 2 minutes. If I’m able to improve my device and get update rates e.g. every 1 minute, I’ll have to go back and remember to update my template sensor. So, it’s still a workaround, but admittedly not bad.
I agree with your point on not wanting to rely on random update intervals that a user may not control and could change at any point. But that isn’t what I’m doing here.
Most often, the ability to trigger off state_reported events is desirable as a “more optimal workaround” while waiting for an integration to get updated to enable that behavior.
It was the whole reason for the implementation of the state_reported event and addition of the last_reported property to entities. The PR for this exact change was already accepted and merged for the Riemann sum integration.
But how would we tell apart an “active” report (as a result of a button click) from a passive one (value passively reported by device, or returning to on after being unavailable)
I’m no expert on how “normal” buttons and events work, but I would have expected that, if they need to transition to unavailable for any reason, that the next possible state can only either be unknown or a new current timestamp (due to a new press of the button or a new occurrence of the event).
Having a button or event transition its state from unavailable to an old timestamp seems like bad behavior. Though I did play around with a template button, and it can be configured to do exactly that. Though I’m hoping that is unique to that type of entity, and probably is a bug. When the availability goes from false → true I think the state should go to unknown and not revert to its previous state. I’m happy to be corrected if that is not true.
I also don’t think it’s possible for a button or event to re-report a previous state. The state timestamp is assigned by HA, not by the device. So it’s not possible for the device to report its old timestamp because it never sent it in the first place. It can send the event (or button press), or not.