Local Calendar timing issues -- event trigger, on-off state, and event details not synchronous

[AndySymons]

The problem

At the start of an event I expect the following to happen at the same time

• Event start trigger
• Calendar state change to 'on' (unless there was a previous consecutive event)
• Details of the new event can be read in the calendar attributes

Similarly, at the end of an event I expect the following to happen at the same time

• Event end trigger
• Calendar state change to 'off' (unless there is a following consecutive event)
• Details of the NEXT event can be read in the calendar attributes (this is current behaviour but this issue is about the timing)

The issue is that these actually do NOT happen at the same time. The event start/end triggers occur at the correct time and details are available in the trigger attributes, but I measured a typical 4 seconds lag before the calendar state change to on/off and by experimentation I found that sometimes, 30 seconds after the event has started the details of that event are still not in the calendar attributes - they are blank or still set for the previous contiguous event.

The trigger attributes are correct but I need repeated access to the information throughout the duration of the event, and storing it myself in helpers or a file is unnecessarily complicated -- I originally made a working solution with 4 helpers per calendar but that makes for an over-complicated blueprint and system when there are several calendars. My current workaround is to poll the calendar every minute, but that is inaccurate and not very efficient.

The fix I am looking for is that event start, state change, and availability of the event details in calendar attributes all happen at exactly the times that the event is scheduled. These times are known in advance so the necessary processing time can be planned in advance.

What version of Home Assistant Core has the issue?

24.02.2

What was the last working version of Home Assistant Core?

None. I believe this issue has always been there since Local Calendar was introduced.

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Local Calendar

Link to integration documentation on our website

No response

Diagnostics information

None available. My figures were obtained fro traces during testing.
I guess one would have to create a custom automation that writes a log file to measure exact timings over a period of time.

Example YAML snippet

Not applicable

Anything in the logs that might be useful for us?

Not applicable

Additional information

I discovered this while testing the Heating X2 blueprint

[home-assistant]

Hey there @allenporter, mind taking a look at this issue as it has been labeled with an integration (local_calendar) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of local_calendar can trigger bot actions by commenting:

• @home-assistant close Closes the issue.
• @home-assistant rename Awesome new title Renames the issue.
• @home-assistant reopen Reopen the issue.
• @home-assistant unassign local_calendar Removes the current integration label and assignees on the issue, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

local_calendar documentation
local_calendar source
_{^{(message by IssueLinks)}}

[allenporter]

Event triggers were added because you can't do what you want with state attributes and it doesn't handle cases like overlapping or multiple concurrent events at once. Event triggers should be used instead of the state, and not combined together.

You can query the calendar using the get events service call if you need additional upcoming events, and parse the results with service responses.

[allenporter]

Note the guidance on https://www.home-assistant.io/integrations/calendar which says to use triggers instead of state, and it describes the get events service for more detail.

[AndySymons]

Thanks. I cannot use the trigger event data for the reasons explained in post 1.

I am already using the event triggers to trigger the automation, not the on/off state, but I do test the on/off state to discover whether there is any active event. That is in practice less problematic because there is little chance I would do that within the 4 second lag, but there is a small theoretical chance of an incorrect result.

To read the data of the current event (by my definition), I could probably use the calendar.get_events service call to return all active events from now until 1 second in the future then sort the response data to pick the one that started latest? Would that do what I am looking for? I would have to try it out to check.

I could also use that instead of calendar state to determine if there are any events at all.

I am not sure that invalidates my issue because it is a lot more complicated than just reading the calendar attributes. It feels more like a workaround. Is there a good reason for the lags between the event start, the change of state, and the availability of the event details in the calendar attributes?

[allenporter]

I did not recommend using state changes at all because they don't cover all the cases, don't handle overlapping events such as all day events, or concurrent events. They can't both reflect an end event and a start event at the same time. Triggers are implemented differently so they can handle all the cases correctly. Triggers can represent events that state changes cannot.

I think you should acknowledge that what you are doing is very advanced and embrace the advanced APIs of querying events on the calendar that have no caveats.

[AndySymons]

@allenporter "I think you should acknowledge that what you are doing is very advanced..."

-- Er .... if you like (!), but I have a genuine need and I think I am exploiting the power of Local Calendar demonstrating how this marvellous innovation can be used to schedule temperatures for a heating system. I have 18 calendars, one for each room.

If you think the state and calendar attribute should not be used you should say so in the documentation, with a relevant warning on the limitations. It took me a long while to figure it out!
Better still, deprecate them and document what you actually recommend -- which I now understand to be the use of the service calendar.get_events?

With a lot of help of the Home Assistant Community forum I have come up with what appears to be a robust solution for my requirement based only on calendar event start and end triggers and the calendar.get_event service.

My requirement is get the currently active event that started last and the next event. I also need to test in each case whether there are any.

The solution is summarised in the following code, which is from Heating X2 blueprint

It appears at the start of the automation, so runs whatever the trigger is (start_event, end_event and several others).

variables:
  local_room_calendar: !input room_calendar 

action:
## -------------------------------------------------------------------------------------------------
## ACTIONS[0-2] -- FETCH THE CURRENT AND NEXT EVENTS FROM THE CALENDAR
## Current event is the one that started last
## -------------------------------------------------------------------------------------------------
  - service: calendar.get_events
    target:
      entity_id: !input room_calendar
    data:
      duration:
        hours: 0
        minutes: 0
        seconds: 1
    response_variable: active_events

  - service: calendar.get_events
    target:
      entity_id: !input room_calendar
    data:
      duration:
        hours: 24
        minutes: 0
        seconds: 0
    response_variable: future_events

  - variables:
      any_event_active: >
        {{ active_events[local_room_calendar].events | count > 0 }}
      current_event: >
        {{ active_events[local_room_calendar].events | sort(attribute ='start') | list | last | default("") }}
      any_future_event: >
        {{ future_events[local_room_calendar].events | count > 0 }}
      next_event: >
        {{ future_events[local_room_calendar].events | sort(attribute ='start') | list | first | default ("") }} 

The rest of the automation uses the four variables I set.

• any_event_active and any_future_event are booleans used in condition templates.

Other templates refer to

current_event.summary
current_event.start
current_event.end
current_event.description

... and similarly for next_event

I have the required temperature in the description between two hashes, so that is extracted as

current_event.description.split('#')[1]

[allenporter]

If you think the state and calendar attribute should not be used you should say so in the documentation, with a relevant warning on the limitations. It took me a long while to figure it out! Better still, deprecate them and document what you actually recommend -- which I now understand to be the use of the service calendar.get_events?

See the documentation at https://www.home-assistant.io/integrations/calendar/ which does not document state. It calls out the limitations and only documents how to use the trigger and get events service. A calendar entity has a state and attributes representing the next event (only). A calendar trigger is much more flexible, has fewer limitations, and is recommended for automations instead of using the entity state.. The state and attributes do not appear in the documentation at all.

For context, a couple years ago only the state existed and it didn't really work for handling cases users needed for automations. I added the trigger and get events service to be able to support these more complex cases. (e.g. being able to determine things about future events like "do i need my car today")

Thanks for sharing your solution. Closing this issue since continuing discussion in the community forums is the right place.