Cheers. I closed my issue as a duplicate with a link to that one.
This is extremely unclear to me from the documentation I can find nor from the breaking-changes (which I read before update).
Initial expectation upon reading breaking changes: when it had all the inputs “valid” it would go from unknown to off/on, and then delays would “take effect” from then on. This would make sense as it would be only possible to determine any state once all inputs are valid.
Later expectation: maybe it has to wait until the delay happens, which would be very annoying, but then after about 30 minutes when my 5-10 minute delay on/off was still unknown I began questioning this too.
This morning, after testing it again, the behavior seems to be unknown → on/off appears after "all input values valid + (delay_on if true -or- delay_off if false) so like 6-11 minutes (with 5m on/10m of delays).
Still not thrilled with that but its MUCH better than I was seeing last night. No idea why…my only guess is although everything “looked” operational maybe it wasn’t REALLY done updating? May not know. All that changed is it sat overnight.
Anyone know how long its been possible for a delay to be a template?! This may drastically simplify some of my nested sensors (for things like short/long occupancy detection).
I think this should also be incorporated into any documentation improvement as a suggested way to get more immediate updates in addition to the new delay_on delay_off behavior documentation fixes (needs a lot better explanation with new unknown)
Nope. What you are seeing is the delay starting after one of your sensors changes state. This has to happen first for the template to update, then the delay starts.
If your temperatures are steady values this may take quite some time. It does not matter that the sensors have a 15 second update interval, they actually have to report a different value for the template to evaluate and kick off the delay.
Right. That there is saying it will start at unknown. And as soon as the state can be determined, it will be known and therefore start sensor-ing at on or off.
Where’s it say that the the delay on/off applies BEFORE the state is known to be on or off?
This is ambiguous, and delaying turning on/off doesn’t make sense until you already identify the current state in the first place, and then can use the current on/off condition to decide if a delay in change is appropriate.
I does not say that because that is not what is happening.
Wait, so even if the “input” sensor driving the template is showing updates every <=15 seconds the template won’t do anything until the value actually changes?
That would seem very counter-intuitive. I have a different sensor that monitors the age of the temp readings for every temp sensor (so I can tell if one stopped reporting, and force_update is set true on mqtt to ensure it always updates that timestamp) and that seems to show no unusually long delays.
But if I’m understanding, even though they report a new last-updated time if the value is equal that won’t start the template updating if the value reported is unchanged?
Example - it shows “x seconds ago” jumped back to “now” even with reporting identical value, I would expect that should count as “changed” regardless of the value reported?
That is what appears to be happening though?
If the delay is removed, it populates as soon as the sensor inputs exist to show on or off.
If the delay is set, it seems to apply the delay timers while its unknown, instead of only after its identified if the current state is on or off.
1 Like
According to the history of changes to its documentation, the first appearance of documentation for those two options is April 2021.
My detective skills may be lacking because I had the feeling those options are older than that but I can’t find evidence of them (in the history) prior to April. (It may also be due to simply failing to look in the right place. 
)
1 Like
Correct.
Hmm.
The delay in my template sensor (posted above) changing from unknown is always 10 minutes + the update interval (or less) of the sensors in the template (it is very noisy so always changes).
So the sensors update then the 10 minute delay starts. 10 minutes later the state of the template sensor changes from unknown to on or off.
I am using the new template integration rather than the legacy template platform though.
Maybe it is only an issue with the legacy template platform?
That seems like a really bad design where the state of an off-on sensor can’t be known for an indefinite amount of time even though we really actually have all the input conditions to identify if its on or off continuously refreshing but have to wait until it actually changes before we can reach a valid state.
To me this feels like it makes the template sensors mostly useless because a lot of things can be valid and should start reporting valid readings even if the value of that reading hasn’t changed.
Basically I no longer have a way to tell if any of the conditions are true or false for infrequently changing sensors without hard coding the same comparative statement in every single automation anywhere I want to perform that comparison.
So what’s the point of even having the boolean sensors if they can’t be…boolean?
If this was the case you would see the template sensor update from unknown quicker than the delay time. Not longer. So I don’t think that is happening.
yeah in my mind it should be update interval (last data heard, whether it altered the value or not) + delay time as a max duration to kick off unknown->known.
A lot of stuff can update without actually altering the value, and not everything has noise to make it “just work” anyways.
Not triggering extra if its known+value unchanged is fine. But not going unknown->known just because the value is unchanged is a problem.
Other way around?
I still don’t get why it makes sense to have a delay going from off to on, or on to off, when it isn’t yet initialized to any known value.
Thinking about that statement I made a bit more, it should not be an issue as the temperature sensors in your template become unknown after a restart too. So the first update the sensors send (even if it was the same as before the restart) should update the template. Only subsequent updates of the template require a change in state of the temperature sensors.
Temp is coming from MQTT, so maybe its a race condition? Could it be sometimes the MQTT has the data (not unknown) sooner than the template binary-sensors are initialized so it doesn’t see it change on that initial time?
Maybe that’s why last night it was having REALLY long delays but this morning its not?
One other difference, this morning I went ahead and reloaded the entire machine (not just homeassistant core) vs last night I just reloaded the core. Maybe last night MQTT got data pulled faster than templates were built, and this morning MQTT was slower starting up so it tripped unknown->value on the temperatures and triggered the update like you said?
Is there something that ensures all integrations load in the same sequence every time? Or is that random?
Do the mqtt messages have the retained flag set?
Home assistant will subscribe and receive the last message if this is the case, won’t even have to wait for a new message to be published to the broker.
It’s important to keep in mind that, in previous versions, Home Assistant made assumptions about a Template Binary Sensor’s state at startup. Without it receiving any actual information, it would claim the binary_sensor was off (at startup).
In other words, it didn’t compute the state value, based on the supplied template, but instantly claimed it was off (even though the true value might, in fact, have been on). The true value was reported only after the template was evaluated and that typically requires one of the entity’s in the template to change state. So it initially faked the binary_sensor’s state until the template was evaluated.
Now it no longer follows the ‘fake it until you make it’ philosophy and indicates unknown when it genuinely doesn’t know the value.