WTH Trigger on state updates without state changes

Month of "What the heck?!"
9

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:

  1. 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.
  2. 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.
  3. Triggering on attributes of buttons or events. This currently needs to be handled in conditions (or in a choose block), but if there were a fire_on_report: true setting, these attributes could be listed in separate state triggers each with their own trigger_id.
  4. 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.

4 Likes