Why do Calendar triggers no longer have an entity_id?

A few weeks ago (one or two HA releases) I tested an earlier version of the following code. For calendar events the entity id was that of the calendar and the state was on or off depending whether there was an active event.

Now (since release 2024.2.2 I think, certainly 2024.3.1) it takes the new branch (introduced by necessity) that shows the entity id as undefined.

Why has this change been made??

     - service: >
          {{ "notify." + local_logging_service_name }}
          title: Calendar Switch Y1
          message: >-
            {% if trigger.id is undefined %}
              {{ log_message_preamble + " Run manually." }} 
            {% elif trigger.entity_id is undefined %}
              {{ log_message_preamble + " Triggered by: " + trigger.id | string + " (no entity id)" }}
            {% else %} 
              {{ log_message_preamble + " Triggered by: " + trigger.id | string + " from '" + state_attr(trigger.entity_id, 'friendly_name') + "', state = " + states(trigger.entity_id) }}
            {% endif %}

Hi Andy, I’m not using triggers in YAML but I still was able to add trigger ID’s a few days ago to calendar triggers so I guess it also must be possible to use them in YAML.

Have you checked the docs or conducted a search on the forum on this?

Of course, but I am not talking about trigger.id – the trigger index or id set by the user as described in Automation Trigger. That works fine. It is always defined except when the automation is run manually by pressing ‘run’ in the UI.

My question is about the attribute trigger.entity_id that the system passes in the trigger object in many but not all cases. It can be used to respond to the triggering device (for example one of a list in a template) or to fetch other attributes such as the friendly name of the triggering entity.

By experiment (with the code quoted above in an automation with several different triggers), I found that I had to put in a test for its existence before using it because not all platforms supply it.

I find that trigger.entity_id is is supplied by climate, binary_sensor and timers, but not by startup (which makes sense) or by (local) calendar. In an earlier version of the OS, calendar did provide a trigger.entity_id (the entity of the calendar) but has now stopped doing so. I just wonder why.

The documentation Automation trigger variables confirms that trigger.entity_id is available for numeric state, template, and zone, triggers but not calendar – so this is not a bug. My question, put another way, is why not (any more) for calendar?