Local calendar feature request 4 – Add custom event fields

Feature Requests
1

I use local calendars for scheduling the temperature I want to set in each room using my blueprint Heating X.

For heating control automations, simply turning the heating on or off is not sufficient – I want to specify the target temperature as well. In my blueprint I deployed a ‘trick’ of writing the temperature in the description between two hashes, then writing a template to extract it. That works fine, but it would have been much easier if I could have defined my own calendar event field ‘temperature’ (with type numeric, floating point, 1 decimal place).

I would then like to read it with a statement like

{{ state_attr('calendar.living_room_heating_schedule', 'temperature' }}

Of course, temperature is not a special case. Such a feature could be used to set lighting to a specific colour (RGB), irrigate a specific zone in the garden, or set a camera to a specific angle.

My feature request therefore is to provide a facility to add custom fields to calendar events alongside the generic Summary (name), Event start, Event end, and Description, with types similar to those of ‘input_’ helpers (text, number, datetime, dropdown), for values corresponding to the states used by all platforms (light, climate, camera, media_player, etc.).

This would raise the game of scheduling stuff by calendar to a whole new level :grinning:

2

Remember to vote for your suggestions! :wink:

3

Done (for all four)

4

Home Assistant’s Local Calendar complies with the iCalendar standard. It’s unclear to me if it supports custom fields.

Currently, you can use Summary to pass a JSON payload like:

{ "temperature": 20.5, "humidity": 42 }

Given an automation with a Calendar Trigger, you can reference the contents of Summary like this:

{% set x = trigger.calendar_event.summary | from_json %}
{{ x.temperature }}, {{ x.humidity }}
1 Like
5

That is a very interesting alternative that I did not know about. Can the same be done with the Description field?

My feature request still stands as a more user friendly and robust approach. The iCalendar standard apparently supports private software extensions, a.k.a. plug-ins, that might offer a technical solution to the request.

6

Yes; any text field.

1 Like
7

I confirm this is possible and is my current workaround. However, it does require some template programming skill. I have developed code that extracts a number from between two hashes in the description field, checks if there is a number at all and whether is it within bounds, and corrects the step size. See the Heating X2 blueprint

However, it would be a lot easier to specify a temperature (or any other attribute) with an event, and would be open to more HA users, if a calendar attribute could be created in a way analogous to HA helpers. No separation character would be needed (the hashes in my case), the type would be fixed (a number in my case), the upper and lower bounds and the step size could be set as usual, the description field would be free for its intended purpose.

My request therefore stands!

8

JSON a mature, widely used standard and Home Assistant supports it. It’s easier to validate than custom data-seralization techniques because the tools are built-in.

Having said that, if all you need to do is pass one or two values then JSON may introduce more overhead than is necessary for the task.

Either way, the point was that what your FR requests is already possible using the Description field.

A calendar event conforms to a standard supported by several calendar integrations. Therefore unless that standard supports the addition of “freeform” fields, you can’t simply add them because it will break calendar integrations. In contrast, the Description field is part of the standard and so is supported by all calendar integrations.

9

Good arguments and I admit the feasibility because that is what I am doing – well, I use jinja inside templates, but that is much the same.

My case is that it could be simpler and more robust, but I leave it to others to comment whether there is a demand.

It is not uncommon for calendars to support the addition of custom fields, so there is no need to break any standard. E.g. Google does it with an add-on.