I tried doing a google search but couldn’t find a concrete answer, so apologies if this is documented somewhere.
If one is using one of the built-in triggers, such as sun.elevation_crossed_threshold or sun.sunset, how often are these triggers checked in the background? A natural assumption would be once every minute, but one shouldn’t assume when it comes to home automation.
There’s no particular immediate use-case/issue, but I am an engineer and I’ve seen issues in the past where race conditions where encountered due to not knowing the internal system interrupt timings.
So when one has an automation that tuns on the porch light at sunset, how often is the internal check to change the value/state of the sunset entity? The answer could anything from milliseconds to a minute.
Well as sunset only happens once a day, chances are the sunset entity will only change once a day. There is no need to check every second as the entity changing is what causes the trigger.
From a quick test using a basic State trigger limited to the elevation attribute, it looks like elevation is likely recalculated on restart and then every 4 minutes…
Thanks, that’s very interesting.. and unexpected. So technically that means for that particular entity there is only a resolution of 4 minutes. But somehow I suspect there might be a config change somewhere that allows that frequency to be altered.
I just wish this kind of stuff was documented somewhere.
I think the HA state machine runs at a max resolution of 1 second, so nothing can trigger faster than once per second, keeping in mind that many changes are ignored it they’ll have no effect.
I don’t necessarily disagree with your statement… but I think you’re missing my question. Yes, it happens once a day… but how does HA know when it happened? There has to be a system interrupt that happens in order to update the entity’s state (true or false). My default suspicion is checked every minute.
Based on the Task description for improvements to the new triggers, it seems like the solar-event based triggers may be pre-calculating the time for the next event then setting a time based trigger listener in the background.
Yep, that makes total sense, from my past experience with other home automation platforms, things like sunrise and sunset are calculated/updated just after midnight then used for subsequent automation conditions or triggers throughout that day. Based on the link you provided, it seems there can be offsets down to the seconds level, so that coincides with @parautenbach statement that HA probably has resolution as low as 1 second intervals if needed.
I have a sunset trigger and it fires earlier each day (since we have passed the summer solstice in the northern hemisphere), it also fires with second precision (each day it’s earlier by a handful of seconds).
I am not really worried enough to try to confirm the accuracy of the sunset time in HA - its still light when the sun goes down, so I just put a few lights on.
Logically there would seem to be two useful patterns for determining sun events:
Poll once per day for the events that occur that day (in high latitudes sometimes there aren’t any events).
Poll for the next event after the previous event occurred.
Given the frequency of sun events, I don’t see a major problem with either implementation.
With respect to the level of precision of the internal scheduler (for time based triggers) in HA.
I haven’t read the code (and frankly the only definitive answer for any particular version of any software is the code for that version).
However it wouldn’t seem to make much sense to me to use granularity finer than 1 second - for most use cases I can think of in “Home Automation”.
That said automations and scripts can contain “delay” statements and those can be expressed in milliseconds - which does have some use cases - such as waiting for a device to initialize before sending additional commands. It’s not clear to me if the wait inside a script uses the same scheduling mechanism as the triggers that start automations.
Additionally I have used some recursive triggers (Trigger based templates) and those are only recalculated once per minute - I suspect that is a defensive measure to prevent infinite loops, but it is worth noting that the protection exists.
Have a read at this, its even more interesting. And on your race condition concern, there is no need for worry, machine state is in memory and you can rely on state changes when you want.
