Currently, Home Assistant does not provide a way to reliably trigger automations when an entity’s state is updated but remains the same (e.g., on → on or off → off). This limitation is particularly problematic for integrations or API calls that send the same state repeatedly without causing an actual state change.
Examples of the issue:
Input Booleans:
An input_boolean remains on, but an integration or automation explicitly sets it to on again. No trigger is fired.
Sensors:
A temperature sensor reports the same value repeatedly (e.g., 20°C), but no automation is triggered because the state does not change.
Integrations and APIs:
An external integration updates a device’s state (e.g., home → home), but this does not trigger any automation in Home Assistant.
Why this is a problem:
State triggers (platform: state): Only fire when the state changes (e.g., off → on or on → off). They do not react to repeated updates of the same state.
Event triggers (state_changed): Only fire when there is an actual change in the state. Updates with the same value are ignored.
Call service triggers (call_service): Only work when a service like turn_on or turn_off is explicitly called. Direct updates from integrations are ignored.
This limitation forces users to create complex workarounds, such as using AppDaemon, dummy entities, or polling mechanisms, which can be inefficient and difficult to maintain.
Suggested Solution:
Introduce a feature that allows automations to trigger on state updates, even if the state remains unchanged. This could be implemented in several ways:
Option in the state trigger:
Add a new parameter like trigger_on_update: true, which ensures that the trigger fires even when the state remains the same.Example:
trigger:
- platform: state
entity_id: input_boolean.example
trigger_on_update: true
New trigger type (state_update):
Create a new trigger type specifically for detecting updates to an entity’s state, regardless of whether the value changes.
Enhancement of state_changed events:
Extend the existing state_changed event to include an option for triggering on updates with identical states.
Benefits:strong text
Flexibility: Automations can reliably react to all relevant events, including repeated updates from integrations or APIs.
Simplicity: Eliminates the need for complex workarounds like dummy entities or external tools like AppDaemon.
Consistency: Ensures that Home Assistant handles all types of entity updates in a predictable manner.
Example Use Cases:
Smart Home Control:
A light switch remains on, but sending another on command should still trigger an automation (e.g., refreshing a scene).
Sensor Updates:
A temperature sensor repeatedly reports 20°C, and an automation should be triggered each time this happens.
API Integrations:
An external system sends repeated updates for a device’s state (e.g., home → home), and these updates need to be processed by automations.
Why this matters:
This feature would close a significant gap in Home Assistant’s current automation capabilities, making it easier for users to handle real-world scenarios where repeated updates are common. It would also reduce reliance on external tools and simplify automation design.
I’m not sure I understand any of your examples.
Sure the light on to on kind of makes sense.
But the temperature sensor, why does an automation need to run on every state change? (Which also implies on how to create this automation).
What is the real world application for this?
Same thing with the device tracker?
Why do you want to load your system so much extra work? All your automations will be running constantly.
I agree with @Hellis81 here. I don’t really understand why you would want your examples. Why would you want to know if a thermostat reported a new temperature if it doesn’t change?
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.
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 an auto_off value specified, so that the sensor turns OFF when it hasn’t been triggered for a specified amount of time.
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.
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.
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.
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.
