iCalendar binding

Tags: #<Tag:0x00007f616edc2950>

As some of you already noticed, i have been building a binding for using ical-calendars as source for presence switches. Now is the time i’m sure i’ll get it done in a way it is maintainable and will be stable for daily use.

  • The good: It already works as i expect, it follows at bit KISS, it contains unit-tests for the algorithm, the iCal-implementation is encapsulated enough so a replacement is easy
  • The bad: There are some known issues (e.g. the calendar pulls first time after the configurable refreshtime, another parameter is currently ignored but planned to be implemented)
  • The ugly: It uses a 3-rd party dependency for parsing iCals as i did not want to reinvent this

So it is currently not mainline-ready. But i’m working on it. Here is the source: https://github.com/daMihe/openhab2-addons (direct: https://github.com/daMihe/openhab2-addons/tree/create-icalpresence/bundles/org.openhab.binding.icalpresence)

@so many users from this forum helping me understanding my issues: a big thank you!

2 Likes

This looks great and finally I would be able to switch from the old Caldav binding.

One question: Does the presence switch has some pattern-matching filter (like regex?). I have a calendar with lots of events in it, I want to view them all, but not to toggle the presence switch if it is not an event with a specific name for example.
The old Caldav binding seems to have a regex filter, but I failed to get it working, even with help. Would be really great if this would work on this binding.

This is currently not possible. For now, i want to release it to ensure it is usable for many people. I plan to add a filter after the first release by regular expressions or categories. But this would also cause to not be displayed.

Your plan is to only switch specific events? This could be done with a rule like this (untested, but could work):

rule "special-switch"
when
    Item presence_switch changed or
    System started
then
   if (presence_switch.state == ON) {
       if (current_event.state.toString.matches("^o[0-9]")) {
           virtual_presence.sendCommand(ON)
       }
   } else {
       virtual_presence.sendCommand(OFF)
   }
end

This requires you to set up a Switch as item called virtual_presence, which can be used for switching other items.

Some Update on state:

  • The initial feature set is complete. There is PR 6453 opened a while ago and it got already a bugfix
  • I’ve got some positive feedback about function from a user

Some Update:

  • @AndrewFG wants to contribute a triggering mechanism for event starts and events, so specific commands can be done by event.
  • As this change will do more than presence we decided to rename the binding from ‘icalpresence’ to ‘icalendar’
  • As the binding-MR was not accepted before OH 2.5 we’ll not wait before building further things

Will the 1.x caldav-personal and caldav-command functionality be built into this binding?

The binding is meant to reimplement parts of the calendar thing in openhab2/3 state of art. But there will be no ability for writing events into calendars automatically, as the way we access the calendars is simpler. The “replacement” for caldav-personal just shows if an event ist present and some details. Please take a look at the README for the current state: https://github.com/daMihe/openhab2-addons/blob/create-icalpresence/bundles/org.openhab.binding.icalendar/README.md

For caldav-command i don’t have a usecase, so i’m not fully aware of which parts will be implemented. The only thing i can assure is that the binding will not be able to modify the calendar.

1 Like

Update about the state: @AndrewFG contributed the command-trigger part using the event bus of openhab. This is cool and works. It’s built a bit like the old caldav-command-binding.

However the commit history was screwed up while integrating his changes into my merge request. So i’ve cleaned up the repository and created a new MR (simply said), see there:

The repaired repository is accessible at https://github.com/daMihe/openhab2-addons/tree/create-icalendar-squashed/bundles/org.openhab.binding.icalendar

1 Like

I have started migrating to this one. One thing I really miss, is a Title which shows the current and upcoming event title as well (current is there is something currently and upcoming if there is no current event), this was supported by the old caldav binding.

Also does someone was able to get iCloud working with this? Seems that webcal links are not supported, only http

Nice to read! webcal should be no problem - just replace webcal:// by http:// or https://, it should work and is only a hint for operating systems the URL is a calendar to open the right application AFAIK. The “hybrid” title is currently not implemented, you could solve this by implementing a virtual item filling it by reading out both in a rule.

1 Like

Thanks it works!

@damihe Thank you very much for your effort. After some days of testing the binding still runs very stable for me. Thumb up :+1:.

It was possible for me to migrate my complete setup in less than 10 minutes from openHAB 1 binding version. Yes, I am missing some information which was available before (e.g. event description or location) but during migration I realized that I do not need it. Time to get rid of some payload from my prod system.

One thing I would love to have in the future would be a way to retrieve more than one upcoming event. Additionally a trigger channel dispatching START / END of events opens flexibility regarding usage of profiles or rule triggers.

Another question: How does the bindings behave if there are multiple events starting at the same time? I am observing a waste collection calendar - which is published by the local community council - and in summer sometimes two different garbage cans are collected on the same day.

For the event trigger part, the binding will process all events in the calendar whose START resp. END time lies in the window between the time when a poll was last executed and the time when the current poll is being executed. So in other words neither multiple simultaneous events, nor multiple staggered events, will be lost.

@cweitkamp Christoph I have vaguely heard about “triggers” but I have never actually used them (or coded them) so => perhaps you can be a bit more specific about what you are looking for?

EDIT: to be more specific, let us say that at time T there are X events containing Command Tags that BEGIN/END in the time window around T; and since each of the X events might contain multiple BEGIN/END tags, then there are Y BEGIN Command Tags and Z END Command Tags in total. So I could image the binding could do one of the following three (four) things…

a) Send 1 trigger message

  • call once: triggerChannel(CHANNEL_EVENT_TRIGGER, "BEGIN" resp. "END");

b) Send X trigger messages

  • call X times: triggerChannel(CHANNEL_EVENT_TRIGGER, "BEGIN" resp. "END");

c) Send Y + Z trigger messages

  • call Y times: triggerChannel(CHANNEL_EVENT_TRIGGER, "BEGIN");
  • call Z times: triggerChannel(CHANNEL_EVENT_TRIGGER, "END");

d) Send something completely different

  • if so, please advise

Thanks for your feedback and of course thanks for your work on the binding too.

For explanation: My idea was to have a trigger channel to emit events like START or END at the beginning or at the end of an calendar event - similar to the existing channel current_presence toggling between ON and OFF. Why? A state channel always has to be linked to an item. This way its state changes (or updates) can be used to trigger a rule. We could omit the item by using channel based triggers. Additionally a trigger channel could be triggered twice (or even more often) if we have two calendar events starting at the same time.

But after your evaluation and the more I am thinking about it the less I am sure if we really need it. I wanted to trigger a rule by it which probably will do some stuff. Most of it can be done by defining command tags inside the event description in an even more flexible way. A rule would only be appropriate if a simple or complex calculation will be needed to perform stuff.

One more situation came to my mind in which a trigger channel could be useful: for reminders. This way one could e.g. play a sound via openHAB as notification.

@cweitkamp many thanks for the feedback; I believe it would be rather simple to send trigger channel messages (indeed I already wrote some code); however it is probably better to wait for some clarity about the exact requirements before I create a PR for this; …

hi,

i’m getting an error on the calendar that i want to use: handshake_failure
its my local trash calendar: https://inzamelkalender.hvcgroep.nl/ical/0505200000073214

icalendar.internal.handler.PullJob] - Response for calendar request could not be retrieved. Error message is: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure

is there something to check? (current openhab setup)

thank you

Hi Richard,

the message is a bit unspecific, there are many reasons why a handshake failure may occur. Some possible: TLS-version-skew, no cipher overlap, Packet loss…

The certificate itself looks good and the error message should be different if something is wrong with the certificate.

Please try to turn on debugging for finding out what’s happening there in detail.

Yeah, I got the same problem. It’s two garbage pick-ups in one day.
Furthermore the question: What is “currend” (always = today?) or “next” (always = tomorrow?).
Furthermore a search for a certain day would be interesting. Is there an appointment on a certain day?

Thanks!
Thomas

Current is whatever calendar event is currently active. The one whose start time has last passed and whose end time has not yet come.

And Next is whatever calendar event would next become Current (according to the definition above).

And if you use command triggers in the events then it will handle as many garbage collections as you want. The related item can be triggered whenever a calendar item become Current and has a BEGIN command in it. If more than one event becomes Current at the same time, then the BEGIN commands of all of them will be activated. Ditto for the END commands when all of the events become no longer current…

2 Likes