-
-
Notifications
You must be signed in to change notification settings - Fork 28.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Google Calendar calendar
entity delayed in changing state
#101431
Comments
Hey there @allenporter, mind taking a look at this issue as it has been labeled with an integration ( Code owner commandsCode owners of
(message by CodeOwnersMention) google documentation |
@bachya TY for the report -- appreciate the detail here. Can you turn up debug for |
I may be seeing this on one of my dev instances as well... Will also try to get debug data myself. |
Ran another test today with an 8-8:30am event today: Once again, the Interestingly, this time, the simple automation ran, apparently at the correct time? DEBUG-level logs for
|
The interesting part is
So it's definitely scheduling the alarms at the right times but either it's not called or it's not detecting the state correctly when it is called. It's then fixed on the next fetch. |
Would there be any race condition based on when the next event occurs? This quasi-successful run was for an event more than 30 minutes away, but I think the initial test was 5-10 minutes away... Not sure if that matters. |
The way I expect this to work is:
So the alarms can be cancelled. We never see the |
Ah so the issue is the update function calls |
Unfortunately, this is still occurring with 2023.10.1. Scheduled a new test event this morning: ...and state changes were once again delayed: DEBUG-level logs for
It does appear that the automation trigger issue has been addressed: |
calendar
entity (a) delayed in changing state and (b) fails as triggercalendar
entity delayed in changing state
FWIW nothing changed here for automation triggers. Maybe the only thing i want to mention, just in case, is that the integration only refreshes data from the server every 15 minutes so if you change something on the server side it needs to be updated/refreshed before it will fire. I can see in your example:
But then the alarm at If you capture this again it would be also helpful to have I'll keep looking on my own test instance for this... |
I'm not sure what to do besides add more logging. I can see this happening where it triggers a few minutes behind on my test docker instance, but in my local developer build instance it always runs fine. I'm adding some debugging like what I have locally. |
Ah, good reminder—it's entirely possible that in some circumstances, I created an event that was 2-3 minutes away... |
I have seen this happening in a development environment and with the added extra debugging it seems like it's still just not firing the alarms at all when it should. The alarm at
So it scheduled an alarm for From the diagnostics, the timezones look all fine:
|
Found the issue while talking over with bdraco, its because there is a shared mutable list class var so the alarms for calendars are clobbering each other. I wasn't able to reproduce locally since i only had one local calendar. |
The problem
I have a Google Calendar that I use for a guest entry automation. The associated
calendar
entity in HASS is consistently late in changing state; as an example, here's an event that is scheduled from 4:35pm to 5:05pm:State changes are 5-6 minutes behind:
Additionally, these state changes do not appear to trigger a simple automation:
In this scenario, even with late state changes, no persistent notifications are created:
What version of Home Assistant Core has the issue?
core-2023.10.0
What was the last working version of Home Assistant Core?
N/A
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Google Calendar
Link to integration documentation on our website
https://www.home-assistant.io/integrations/google/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
Unfortunately, debug-level logging doesn't show much:
Additional information
No response
The text was updated successfully, but these errors were encountered: