Local Calendar feature request 5 - Recognise overlapping events

[AndySymons]

Couple of days? Your tutoring must have been good because I did it in a couple of hours!

The relevant code is the following fragment, which 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]

UPDATE 25-Feb: the code above is streamlined to one template line per variable, and a default is added to stop warnings in the error log file when there are no events.

For the full code see Heating X2 blueprint

Nice!

[123 (Taras)]

It’s the custom of this community to assign the Solution tag to the first post that answers/solves the original question/problem.

Despite first having to be convinced your FR wasn’t necessary and was already achievable, receiving numerous detailed explanations on how to do it, including a tutorial on how to handle a response_variable, you ultimately chose to mark your own post as the Solution.

You may wish to familiarize yourself with guideline 21 in the FAQ.

[AndySymons]

@123

It’s the custom of this community to assign the Solution tag to the first post that answers/solves the original question/problem.

The guidance says
Continuing the discussion from How to help us help you - or How to ask a good question:

@Tinkerer

Somebody’s answer solved it!

Fantastic!

Now, before you go… please take the time to mark that as the answer, you do that by selecting the three dots under the post:

Then select the check box:

Don’t forget too while you’re down there to click the heart to like the post, as a way of saying thank you.

I solved the overlapping events problem with a lot of help from you, a little from Drew, and some from Allenporter on what tuned out to be a related issue on Githubi. The final code took a fair bit of experimentation and further research once you had set me on the right track. I found List of Builtin Filters particularly useful.

I transferred the code to my context (in an automation, using local variables), streamlined the code (using first and last filters), used two calendar.get_events calls for current and future events, and added the default filter to eliminate warnings in the log file when there are no events.

Your help was invaluable and I am happy to acknowledge that formally if there is a means of doing so beyond ‘liking’ your postings. For a reader of the thread, however, the actual solution to the problem is in the posting that I indicated.

I can only tick one posting as the ‘solution’. Which one do you propose?

BTW I am not convinced that my FR wasn’t necessary. It was made in good faith based on the existing documentation and would still be a much simpler solution if adopted.

[123 (Taras)]

@AndySymons

Which one do you propose?

This one:

Local Calendar feature request 5 - Recognise overlapping events

I believe that’s how an All Day event is handled now. It starts at 00:00 and runs until the end of the day. It effectively monopolizes the “current” calendar event all day long. All of the scheduling situations you described is why it’s not recommended to reference the “current” calendar event’s state and attributes. Ostensibly, it’s supposed to display the current scheduled event but that only works for the most simplest of calendar schedules (no All Day event with other events, no overlapp…

Because it spells out what is the recommended way of currently achieving the FR’s goal.

@123

The simplest solution is to avoid referencing the “current” calendar event and use the Calendar Trigger and/or get_events service call as needed. That’s what the author recommends.

The majority of the topic is me tutoring you on how to implement it, including fundamentals like how a dictionary can be represented and how to access the keys and values of the dictionary within a response_variable.