Overlapping Events issue

[stevenbuehner]

I have an issue with the "status" attribute, when there are multiple overlapping events.

My Setup in the Calendar is Event 1:

• Title: Test1
• Duration start_time: '2022-11-16 10:00:00', end_time: '2022-11-16 12:10:00'
• all_day: false

Event 2:

• Title: Test2
• Duration start_time: '2022-11-16 12:00:00', end_time: '2022-11-16 12:30:00'
• all_day: false

So there are two overlapping events. I expect the status of the entity to be "on" the whole time between 10:00 and 12:30. But this does not seem to work.

Here is what I expected and what happened:

• [x] 11:00 expect status "on" -> status is on (event attribute shows "Test1")
• [x] 12:00 expect status "on" -> status is on (event attribute shows only "Test1", although "Test2" could be available)
• [x] 12:10 expect status "on" -> status is on (event attribute shows only "Test1", although "Test2" could be available)
• [ ] 12:11 expect status "on" -> status is off (event attribute still shows "Test1" and seems to ignore "Test2")
• [ ] 12:13 expect status "on" -> status is off (event attribute still shows "Test1" and seems to ignore "Test2")
• [ ] 12:17 expect status "on" -> status is off (event attribute still shows "Test1" and seems to ignore "Test2")
• [x] 12:30 expect status "on" -> status is on (event attribute finally shows "Test2")

At 12:11

At 12:13

At 12:17

At 12:30

[franc6]

This is just a quick note to say that I probably won't get to this for another couple of weeks. I think your expectations match mine, so I'm calling it a bug. I should note, too, that the 'on' status doesn't seem to update as I expect with the built-in "caldav" platform, too, so there's a small chance I'll re-classify this as an HA bug. For now, though, I'm assuming it's a bug in my code.

[stevenbuehner]

Thank you for your quick note. That is very welcome 👍 . And thank you for looking into the problem ... :-)

[franc6]

After doing some more testing, I think the calendar platform is behaving properly, and that the issue is caused by the throttling built into the platform (update is called only once every 15 minutes, the same as for the built-in calendar platforms). If update had been called between 12:02pm and 12:10pm, you would see exactly the behavior above, because the calendar entity really doesn't know there was something new after your first event, and wouldn't know until update had been called again. In which case, it should have given correct results at about 12:25pm, and possibly as early as 12:18pm. If update had been called after 12:10pm, it would also have given correct results at 12:11pm, 12:13pm and 12:17pm.

You can test my theory with an appropriate set of events, turning on debug logging for the ics_calendar platform, and then checking the events more frequently. With the debug logging enabled, you can see exactly when update was called, and therefore be able to predict when the entity will show the correct or an old event. I was able to reproduce the problem in exactly this manner. Assuming I'm correct about what you saw, the problem should be taken up with HA first. If I see HA change its update throttling, I'll modify the platform to match.

[stevenbuehner]

Thank you for investigating the issue so deeply and reproducing the problem on your end. What you say sounds reasonable and explains the experienced outcome.