The calendar UI and data source is refreshed whenever it changes plus every minute. Google calendar syncs down the state of calendar every 15 minutes by comparison.
The automation trigger logic for all calendars reads events within a 15 minute window to find the next in upcoming events to fire. It doesn’t reread the events in that window once it has read them, since calendars rarely change. If you are testing an automation, then reloading automations should rerun the trigger initialization which should read any new calendar data (the local calendar will already be fresh to be ready again)
I created a simple automation to post a persistent_notification when a calendar event occurred.
At 10:00 AM, I scheduled a local calendar event at 10:10 AM.
At 10:10 AM, the automation wasn’t triggered by the recently scheduled event.
(NOTE: Times are approximate; I don’t recall the exact hour and minute the event was created but the scheduled event time was less than 15 minutes away)
I repeated the experiment by scheduling the event to occur 20 minutes in the future. The automation triggered for this event. This led me to believe calendar polling is involved.
Based on your explanation, it would seem that I had created the calendar event after the most recent 15-minute polling cycle, therefore it was blind to the event I had just created (and so the automation didn’t trigger at the scheduled time).
Unless I have misunderstood your explanation, the guideline is that one should not attempt to schedule an event in the very near future, like under 15-20 minutes from the time the event is created, because it risks being missed by the polling cycle.
Yes. If you create an event within 15 minutes from now and expect an automation to fire you’ll need to reload the automation (e.g. manually or via service). The common case for calendar based home automations is you set up the calendar and don’t change it so there is a balance here of unnecessary work constantly checking for changes (and there are none), with the option to reload if you want it to refresh faster.
The automation was created using the Automation Editor. Upon clicking its Save button it automatically checks the automation for syntax errors and, if none found, it executes Reload Automations to load the newly created/modified automation.
Shouldn’t this have satisfied the requirement you mentioned?
reloading automations should rerun the trigger initialization which should read any new calendar data (the local calendar will already be fresh to be ready again)
Or does the manner in which the Automation Editor reloads the automation somehow escape the notice of the mechanism that collects calendar events?
Are you sure reloading automations still works? Because I used that in another workaround, but that stopped working the minute they implemented the feature that only changed automations get reloaded and unchanged ones keep running.
I repeated the test, paying close attention to the order of steps:
At 15:54, create calendar event scheduled for 16:00.
Immediately modify and save my existing automation thereby initiating a reload.
At 15:55, create another calendar event scheduled for 15:57.
At 15:57, the scheduled event didn’t trigger the automation. This is expected behavior; this event was created after the automation was reloaded and too soon for the polling cycle.
At 16:00, the scheduled event triggered the automation. This confirms what you explained; reloading automations initiates a refresh of calendar events.