That is what I’m trying to explain (perhaps not good enough);
binary_sensor.hue_motion_sensor_1_motion is the physical Hue Motion Detector. It works as expected and changes state from ‘off’ to ‘on’ immediately when I make a motion in front of it. Then the state ‘on’ is active for perhaps 10 seconds after motion is stopped. I check this from both the Frontend and dev-state.
If I do this motion in front of the sensor between the scan_interval (by the way, setting it to 5 seconds within the sensor didn’t make any change), and the Hue changes back to ‘off’ before next scan_interval, nothing more happens.
If I make sure the Hue keep the state to ‘on’ until next cycle of scan_interval (which is actually the issue I’ trying to resolve), the sensor.siste_24_timer_motion seems to be activated and then the binary_sensor.motion_siste_24t is changing state to ‘on’ and the automation will work.
Can you please open the “more info” for the three entities we’re talking about and see what the history graphs look like for each of them?
EDIT: I understand what you’re saying. I’m trying to help figure out why it’s not working as expected. If I could see those three history graphs it would definitely help.
EDIT 2: I’m also curious why you say changing the scan_interval didn’t make any change. And also, how do you know when you’re “between the scan_interval”?
First regarding your edit 2 - actually guessing as I’m using stopwatch and do testing to see how long it takes from Hue state is ‘on’ until binary_sensor change state to ‘on’
EDIT: Do I totally misunderstand how the history_stats is working??
EDIT 2: Hue image is not the binary_sensor but a sensor I made to change the name of states
Following images are taken within seconds after each other where I activated the Hue for a few seconds:
Well maybe it’s me that doesn’t understand. I can’t say that I’ve used history_stats much, and I haven’t reviewed the code in detail. I’m just going off what the docs say and what I would expect it does.
FYI, once you have these “more info” windows open, if you click on the “title bar” they will expand to the full width of the browser. I often do that to be able to see the detail more easily.
It’s hard to say from looking at these pictures, but they would seem to imply the first one went on for a short time 15 seconds ago, whereas the last two haven’t changed in the last 50+ minutes. Is that right?
Hmm, maybe I put you on to a bad path. It seemed reasonable based on my expectations of how history_stats worked.
Okie, I will make two tests with bigger images.
Test one will be ‘keep the Hue Sensor open for approx 15 secods’
Test two will be ‘keep the Hue Sensor open until binary_sensor change state’
Second test, made motion on Hue until binary_sensor was triggered (and at the same time the history_stats changed from ‘0.00h’ to ‘0.01h’ like shown in first image from Frondend). Sorry for my native language but I assume you get the icons
This time it took approx 24 seconds from Hue was activated to ‘on’ until the two other sensors changed state (so there is no clear 30 second rule proving that it depends where in the scan_interval cycle the motion is detected - and the scan_interval inside platform: history_stats of 5 does obviously no change to the scan interval).
motion_siste_24t:
friendly_name: Motion siste 24t
value_template: >
{{ not is_state_attr('sensor.siste_24_timer_motion', 'value', '0m') }}
The problem is that the state of the history_stats sensor is rounded to 2 decimal places, so it effectively can’t show very short ‘on’ times. However, the sensor also has a value attribute that shows more detail. Unfortunately it’s not a simple float, but rather a “pretty” version of the time. Suffice it to say, if the actual value is zero, then the value attribute will be '0m'.
No, wait! Argh!!! Alas, it throws away seconds, so if it was 59 seconds, it will still show '0m'.
What if we changed it to seconds? This history_stat is not to be show’n anyway?
Though, will this impact the scan_interval which I still think is an issue?
Again, the scan_interval is just how often it updates itself (i.e., queries the database.) It really has nothing to do with how close togeterh the state_changed events it’s reading out of the database are. The only effect you would see is how soon it updates after the “input” entity_id updates.
The bottom line is, it calculates how long the input entity_id has been in the specified (‘on’) state during the specified period. It then sets its state, and its value attribute, accordingly. That’s when the problem occurs. It never “outputs” the raw value, it only shows it rounded to 2 places, and in the funky “pretty” version (in the value attribute), which, unfortunately, throws away fractional minutes.
You could use it, but it would take modifying it, e.g., to add another attribute that is the full precision, float value. But…
!