History Stat doesn't update until state change?

Configuration
1

I have a history stat configured to tell me if there’s been a car seen in the last 30 seconds (I use this to determine if I’m leaving the house or coming back).

The stat is:

- platform: history_stats
  name: front_yard_vehicle_detected_recently_count
  entity_id: binary_sensor.front_yard_vehicle_detected
  state: "On"
  type: count
  duration: "00:00:30"
  end: "{{ now() }}"

For some reason, the stat doesn’t update right away until the Vehicle Detected binary sensor falls from On to Off: here is the example:

image
image1096×616 33.5 KB

But this doesn’t always happen! See this example, where the history stat worked properly and immediately went high (to 1) as soon as the vehicle_detection sensor went to On:

image
image1044×623 35.2 KB

Any thoughts on why this is the case? Or if there’s a better way to immediately signal/check if, in this case, a vehicle has been detected in the last 30 seconds?

Thanks a lot.

2

i don’t know much about the history stats, but to achieve your original intent, would something like this help you achieve your goals?

3

History_stats aren’t great with accurate time intervals, especially when they are short. I would expect the history_stats sensor to be updated when the source sensor is updated, and also every minute after any update due to the presence of now() and the fact that the rendering of now() is rate-limited to once/minute.

So I would expect (and have replicated) the behavior of the history_stats sensor, using type: count method, with end: "{{ now() }}" to change from 0 to 1 after whichever occurs first:

  • the source sensor has turned back to OFF after having been ON for at least 2 seconds
  • a period of 1 minute has elapsed after the source sensor turned OFF after it was ON for less than 2 seconds (this bullet only applies if duration: is >= 1 minute)
  • the source sensor has been ON for 1 minute

To figure out when the history_stats sensor will change from 1 back to zero, you have to take the configured duration and round it up to the next whole minute.

As you can tell, this doesn’t align with what would be expected if you weren’t familiar with the inner workings of HA. Your first graph aligns with the explanation listed above.

However, your second graph doesn’t, and I was unable to come up with a scenario where that can happen. I’d be curious if anything odd happened with the source sensor at that time, like if it rapidly changed ON/OFF/ON, or briefly went to unavailable, or something else. But normally, I wouldn’t expect that to happen.

Anyway, you probably don’t care at all about anything I wrote above. You just want to know how to make it work. If your goal is to know whether the motion sensor was in the ON state at any time within the previous 30 seconds, the answer is a template binary_sensor with a delay_off setting of 30 seconds.

You’ll have to configure it in YAML; the template sensor helper in the UI does not support this option.

4

This is awesome and thank you SO much for the full explanation. Often it’s hard to really figure out how or why things quite happen without a bit more of the color about what’s happening behind the scenes, so this is really terrific. Thanks for taking the time.

I’m afraid I don’t have any thoughts about what odd thing might have happened in the second graph – if it helps, it’s a vehicle_detection sensor from Unifi Protect; in the Protect app sometimes the vehicle detection “box overlay” blinks a bit, which makes me think maybe the detection bounces – but I haven’t really tried to track any “integration events” (not sure if that’s the right wording?) to figure out what specifically is coming into HA. If you’re interested in following up and really trying to duplicate and can help me a bit figure out what to watch for, I’m happy to try to duplicate the test again.

Thanks again!

5

No problem. For the second graph, if you wouldn’t mind looking at your logbook (should be on the sidebar beneath history) and taking a screen capture of what you see. Look at only the entity binary_sensor.front_yard_vehicle_detected and at that same time range (May 26, 5:05pm to 5:10pm)

6

Alas, doesn’t look like anything special:

image
image1828×620 41.6 KB

Trigger (no pun intended) any thoughts?

7

Hmm. Nope. But thanks for taking the time to look at it.

I’m not smart enough to be able to understand all the source code so I’m only throwing darts, but I wonder if there’s a race condition in the history_stats sensor. Since it will update upon a source sensor change, if that source goes from OFF → ON, the code will be checking if the source has been ON at any time in the past ‘X’ duration, and since it just now turned ON, I wonder if occasionally the timing is such that the new ON state makes the code satisfy that condition.

My uninformed opinion is that the count should always increment at the time the source has charged to satisfy the condition, as opposed to the observed behavior of it not incrementing until the next update. To me it seems like you captured a rare instance of it working correctly.

But I digress. I’m putting this in the category labeled “I still don’t understand it, but the level of effort required for further evaluation exceeds my level of curiosity” :grin:

8

ha! Yes, I know that feeling. To close the loop, thanks for the help - I made this sensor:

- binary_sensor:
    - name: "test_template32"
      delay_off: 00:00:30
      state: >
        {{ is_state('binary_sensor.front_yard_vehicle_detected', 'on') }}

and it seems to be working great. I got a little confused last night because it didn’t work “after the fact” (I was trying to create a new template sensor last night and set a delay_off prior to an ‘on’ state early yesterday, from before the sensor was created, and that didn’t work. It was only when i actually drove the car into the driveway this morning that I saw what I expected).

Thanks again.

1 Like