If you really need it for a specific use case, it’s available.
I haven’t figured out a way to do anything with state.last_reported
events. Integrations can use it (like the Riemann sum integral already has been updated to use it) but it doesn’t appear that automations or trigger-based template sensors can do anything with it. When I was digging around in the PR’s I recall a comment that the initial implementation would be limited.
Maybe this has changed since I last looked?
FWIW, I recently tried to create an Event Trigger with event_type
set to state_reported
. I understand that it won’t allow listening to this event for all entities (at least that’s my understanding of the developer’s blog post) so I tried limiting it to one entity by adding entity_id: sensor.something
to the trigger’s event_data
. However the Automation Editor always reports an error message indicating state_reported
is invalid for event_type
.
Would you happen to know how to detect the state_reported
event? Or is it truly unavailable for use anywhere? (The automation validation knows about its existence because it’s not considering it to be the name of a custom event).
Based on this PR it seems it’s intentionally not possible to use state_reported
in an event trigger.
The statement from that PR:
Triggering on
state_reported
should instead be done by extending the functionality of state triggers.
…seems to imply there should be some upcoming improvement to state triggers to allow triggering on a “report” instead of only a state change (or attribute change) but I haven’t seen anything like that.
This WTH is so well structured, yet, it provides no information. It just defines everything by circle:
The sky is blue, and that is a problem because it is blue. - But why is that a problem?
The sky should be red. The benefit is that it would be red. - Again, what is the benefit here?
Having some real examples (instead o provided circular definitions) would really help understand what you’re trying to achieve.
If I look at thermostat example, why would the automation trigger differently based on manufacturer’s decision to report value every 1 minute, every 5 minute, every hour, or only on change?
Since I’m currently the only one who has voted for this WTH, I’ll offer my reasoning. Apologies in advance for being a bit winded and diving into the background first.
Background
HA has historically fallen on its face when it comes to dealing with repeated values. The logic was that there is no need to do anything if, for example, a temperature sensor reports 20°C every 5 minutes for an hour. No need to clutter the recorder database with useless data, and no need to waste processing time. Simply ignore those values and events and assume the first data point is still valid. An easy win for optimization!
Slowly the devs have started to understand the pitfalls of this behavior. There are edge cases where this behavior is crippling and workarounds are extremely difficult and convoluted to implement, especially for users who don’t understand why they aren’t seeing expected results to begin with. Starting last year with this architecture discussion, resulting in changes implemented in this parent PR summarized in this dev blog post, improvements are being introduced to rectify the situation.
However, the changes are not complete yet. Many of the changes enable integrations to react to repeated values, but those integrations need to be updated to implement that behavior. In addition, the final piece that core needs to implement is to allow triggering on the state_reported
event. Which, based on a PR comment from a dev, won’t be allowed via an event trigger but instead through an improvement to the state trigger (essentially suggested solution #1 from the OP). The PR for this improvement has never been created.
The last sentence is exactly why I voted for this WTH. Nearly a year ago the HA team had concluded that a change was necessary, agreed on how to implement it, but then seem to have either forgotten about it or it got put low on the priority list.
Examples
Included in those links above are some reasons why HA might want to take action on a “report” that doesn’t have a different value. Most of those examples pertain to numerical analysis using integrations (like Riemann sum or derivative or history_stats) so here are some additional examples using automations or trigger-based template sensors:
- A simple “change since last report” sensor. I have a water meter which reports a reading every 2 minutes. I’d like to have a sensor calculate the consumption over the past 2 minutes. Without some convoluted workarounds, it’s not possible for a trigger-based template sensor (or an automation that updates an input number helper) to report zero.
- A “dead device” binary template sensor. For a critical sensor, it might be desired to trigger an alert or turn on a binary sensor if no report is received from a device after a certain amount of time. For a sensor that doesn’t change very often, it can be difficult to know if it hasn’t reported or if it simply hasn’t changed. Triggering on
state_reported
would be useful here. In that scenario, a template binary_sensor with anauto_off
value specified, so that the sensor turns OFF when it hasn’t been triggered for a specified amount of time. - Triggering on attributes of buttons or events. This currently needs to be handled in conditions (or in a
choose
block), but if there were afire_on_report: true
setting, these attributes could be listed in separate state triggers each with their own trigger_id. - A trigger_based template sensor that performs numerical analysis, like implementing exponential smoothing. This requires triggering off
state_reported
events and therefore there is no possible workaround outside of creating a custom integration since only integrations currently have that capability.
Edit: added 3rd example due to user complaints from Z2M 2.0 update. Added 4th example as it is the only one without a viable workaround.
I voted for this. I don’t need it right now but I don’t see why this information exists jut cannot be used to trigger.
Random but sort of related: zigbee devices (ZHA at least but iirc z2m as well) have a ‘last seen’ attribute that as far as I can see also cannot be used as a trigger in automations.
Using a template trigger you can easily use an entity datetime to determine if it hasn’t been changed at some user prescribed interval.
Example from a live automation when the state is older than 15 minutes:
value_template: {{ ((as_timestamp(now()) - as_timestamp(states.media_player.pat_asc_fire1.last_changed))
> 900 }}
The last_changed
attribute is distinctly different from the last_reported
attribute which is what is pertinent in this thread. But to your point, it is possible to use the same template but with last_reported
instead. It works for a “sensor is dead” automation because it essentially changes the trigger to once/minute rather than triggering on the last_reported
property itself. So it can be useful in certain cases but doesn’t address this WTH.
The temperature example isn’t ideal. @mekaneck examples, like water meters or dead device detection, better illustrate the need for triggering on repeated state updates.
This is my main use case:
I use Alexa with exposed helper entities in Home Assistant to trigger automations. Here are some examples of my use cases to clarify the need for triggering automations even when a state remains unchanged:
- Heating Control: I have a toggle helper (e.g., “Heating On”) exposed to Alexa. When turned on, it triggers an automation that sets all thermostats to specific values. However, if the thermostats’ temperatures are changed by other automations (e.g., due to “Away” mode), I need to re-trigger the “Heating On” helper to reset the thermostats. Since the toggle is already “On,” the automation doesn’t trigger again.
- Timer Reset: A number helper stores the duration for a timer (e.g., 20 minutes). If I want to restart the timer with the same value (20 minutes), the automation won’t trigger because the value hasn’t changed.
- Mode Selection: A dropdown helper (e.g., “Mode” with options like “Away,” “Awake,” “Sleep”) triggers automations that adjust devices and helpers accordingly. Sometimes, I want to re-select “Awake” to reset everything to its proper state after manual changes, but this doesn’t work since the state hasn’t changed.
I currently have no satisfying solution for this issue. My workaround involves creating additional automations that reset the Alexa-exposed helper entities to their default state after each use. This ensures they can be triggered again, but it adds unnecessary complexity and feels inefficient for what should be a simple task.
Yes, the proposed solution using a template trigger can work for a dead man’s sensor, but only if the entity reliably updates its last_updated
property.
Not all entities reliably update last_updated
, especially if their integration doesn’t report unchanged states.
Don’t use a toggle then!
Use a button, or edit your automation to turn off the boolean after triggering.
Really? Is that an issue?
Don’t understand this example.
If it’s already set to 20 minutes then you can’t set it to 20 again and there shouldn’t be any need either.
Post your example as yaml because it makes no sense.
It seems to me as you have made a manual version of scenes.
That’s only because you’re using an input boolean.
Change this to a template switch and you won’t have that problem.
What do you mean by this? Are you using an input_boolean again to trigger? If yes, template switch.
That would be a template select.
I suggest you start looking into template entities which are virtual entities. They are entities that run things when you do normal service calls on the entity itself instead of actioning off the state change of an entity.
I don’t understand many of the use cases discussed but I voted for this for use in group/scene control. If you have a group or scene that is triggered by turning on one of the switches included in the group or scene then you would want the behaviour to be that the group or scene is re-sent if the switch ON paddle is pressed again even if it is already on. This would reset the group or scene if some members got out of sync from manual or programmatic changes while the group or scene was active. This is default behaviour for protocols like Insteon but having this feature option in Home Assistant would allow the same result for groups and scenes with mixed technology devices.
Yes, HA already does this.
The reason it’s not working for @Pingfragger is because he’s exposing an input boolean to voice control. When voice calls turn on again, it turns on the input boolean. But the boolean does not change state because it’s already on.
It’s also default behavior for HA. The reason it isn’t working is because OP is working off the state change of the device. Not the fact the service. This only comes from using input_xxx
helpers. It’s an oddity with them. So what you’d typically do is attach a service to the ‘turn_on’ function… to do that… you’re essentially using template entities.
If you do use booleans then the state * is a better trigger.
Mening it triggers on both on or off
I have to use an input boolean switch because it’s the only option that works with the integration I’m using (Alexa local control). A button or other entity type won’t work in this case.
For the Timer Reset example: The number helper stores a duration (e.g., 20 minutes) for a timer. If I want to restart the timer with the same value (20 minutes), the automation doesn’t trigger because the value hasn’t changed, even though the value 20 is sent again to restart the timer.
Using a template switch combined with a service call could solve this issue, however, this requires additional programming effort, whereas a new feature like “received update” would make this process significantly simpler and more user-friendly.
For Mode Selection, @Upstatemike explained it very well: sometimes you need to reapply a group or scene to reset everything, especially if manual or programmatic changes have caused devices to go out of sync. In my case I can only use an input boolean because of the integration limitations.
If a input_boolean helper is already “on” and an integration sends “turn_on” again, no action is triggered because it’s just a state update, not an explicit turn_on
service call. Is that correct?
I’ve been using Home Assistant for two weeks now after switching from another smart home system where the “received update” functionality was available. I used this feature regularly to trigger automations even when the state didn’t change, and I miss having this option in Home Assistant.
Again, the option exists with a Template a switch
. You’re running into issues because you choose a Toggle
helper.
Instead of using a Toggle
helper, use a Template a switch
. You can get what you want right this minute.
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 theon
status from the integration, even if the Template Switch is alreadyon
. - 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: ""