“When testing, make sure you do not plan events less than 15 minutes away from the current time, or your trigger might not fire.”
Ridiculous, same day calendar events have a 15 minute lag. Scan for daily on every minute. Everything else the 15 minute pull.
This is highly specific to the integration and domain used, as well as the rate limits imposed by a provider.
Do you know you can set an entity’s state from the dev tools to e.g. test an automations trigger?
OP is referring to Calendar Event triggers, so setting the entity state isn’t going to help…
The 15 minutes refresh interval can be a real hindrance not only to testing automations but also to building anything reliable based on a calendar that may have near-term changes.
I know I can also test an automation by clicking run action, but it doesn’t prove calendar works. With the amount of load I put on my iHA every
minute, scanning a couple of entries in my calendar isn’t seeming over the top.
Also, where is the 15 min limit, on the quarter hour, 30,45 and zero?
Too vague as it stands.
The attributes contain the next event, so setting the calendar entity’s state to on should then help for many cases (if you’re checking in your automation e.g. the start time, then it won’t).
Agreed. It’s generally tedious.
Which is why I didn’t suggest that.
Are you referring to local calendars in HA only, or an HA calendar that’s updated externally? If the latter, are we talking about pulling in a Google Calendar, for example?
For the former: I agree that polling it more regularly very likely has very little overhead.
For the latter, you are limited by what the service provider allows.
That’s really the point I’m trying to clarify regarding your WTH.
This might not be suitable, but I also want to point out that I’ve used calendar events myself for todos before HA had a todo integration, which I believe will trigger better (I haven’t used it).
You (too) are conflating two unrelated things:
It’s an issue with Local Calendar as well… adding a new event doesn’t force the the events to be re-read as Allen wrote in the post I linked previously.
You can force a re-read by reloading the calendar’s config entry after the event is added. But, since overlapping events can mean that the newly added, near-term event isn’t reflected in the state, there isn’t a reliable way to automate the reload just off the calendar entity.