The calDAV Binding is now officially available. With this you can automate tasks which will be triggered over an calendar (calDAV). You can query events from your calendars to show them in your favourite ui and never miss events. The binding is already tested over ~6 month, as well by other users.
Great news! Any idea when it will be available as a Debian package? Or do we have to wait for 1.8.0 for this?
Thx. A really important building block.
Really cool ! Thanks a lot.
Could you test the binding in an OH2 installation as well? I would love to mark it “OH2 compatible”
I think I just discovered an error in the new binding. (Build from the sources 2 days ago) After one or two days the calendar events stop working. After a restart of Openhab they work again for some time then the error occurs again. I found the following error in the log:
2015-12-08 18:00:00.255 [ERROR] [o.caldav.internal.job.EventJob:55 ]- error executing event job
java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
at java.util.ArrayList.rangeCheck(ArrayList.java:635) ~[na:1.7.0_60]
at java.util.ArrayList.get(ArrayList.java:411) ~[na:1.7.0_60]
at org.openhab.io.caldav.internal.job.EventJob.execute(EventJob.java:33) ~[na:na]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz-all-2.1.7.jar:na]
at org.quartz.simpl.SimpleThreadPool$WorkerThread.run(SimpleThreadPool.java:557) [quartz-all-2.1.7.jar:na]
I’ve uploaded a zip file containing all .ics files to my Dropbox: https://www.dropbox.com/s/pi6lpkqq2c25v7w/ics.zip?dl=0
Can you please fix this bug?
Thanks for the log fragment. Could you please open up an issue over at github so this can be properly tracked?
I’m keenly interested in using this binding to control my Z-wave thermostat, but I can’t seem to get it to work at all.
I have org.openhab.binding.caldav-command-1.8.0-SNAPSHOT.jar, org.openhab.binding.caldav-personal-1.8.0-SNAPSHOT.jar, and org.openhab.persistence.caldav-1.8.0-SNAPSHOT.jar in my addons folder. I’ve configured logging in logback.xml. When I restart OpenHAB the log is created but nothing is written to it. It seems like the binding is not loading.
What am I doing wrong?
Please post your config (openhab_default.xml and items configuration) and the log snippet.
Sorry, I just got it working. I had an old snapshot version of org.openhab.io.caldav-1.8.0 installed. I replaced it with a more recent one I found on another thread and it works now.
Thanks for the quick reply,
@querdenker2k Many thanks for this binding!
I’ve got the basic commands coming through properly from my Baikal caldav calendar (and events being executed correctly) but I’m a bit unclear as to how to use the caldav persistence. In my log file I can see:
2016-01-01 12:54:25.399 [DEBUG] [o.p.c.internal.CaldavActivator] - calDAV persistence bundle has been started.
2016-01-01 12:56:14.411 [TRACE] [p.c.i.CaldavPersistenceService] - persisting item: Light_GF_Playroom_Ceiling_1 (Type=SwitchItem, State=ON)
2016-01-01 12:56:14.412 [DEBUG] [p.c.i.CaldavPersistenceService] - creating new event
2016-01-01 12:56:14.431 [DEBUG] [p.c.i.CaldavPersistenceService] - new event for persistence created: org.openhab.io.caldav.CalDavEvent@bb4d37ee
The logs seem to be saying that the caldav persistence is working. However, when I check my calendar itself, I don’t see any entries corresponding to these events. Where are these being stored and is there any way to automatically use these for presence simulation (i.e. in the way that the gcal binding does presence simulation by persisting all events into the calendar 14 days forward)?
Are there any logs of “CalDavLoaderImpl” after this?
Can you post your config? especially the persistence config.
Using for presense simulation is currently not possible. But shouldn’t be a problem if needed.
There are “CalDavLoaderImpl” entries, but I am not sure whether they are related to persistence or to the other caldav functionality. Here are the last few log entries from the binding (there is nothing else after these lines):
2016-01-01 21:27:37.223 [TRACE] [.i.c.internal.CalDavLoaderImpl] - loading event: cpnpaul9-hsy8-oteh-b3qw-8y0adwrhxf2i:Control Playroom Lights 2
2016-01-01 21:27:37.223 [TRACE] [.i.c.internal.CalDavLoaderImpl] - start is with known timezone: Europe/London
2016-01-01 21:27:37.224 [TRACE] [.i.c.internal.CalDavLoaderImpl] - adding event: cpnpaul9-hsy8-oteh-b3qw-8y0adwrhxf2i(Control Playroom Lights firstname.lastname@example.org/15:48-01.01.2016/15:49)
2016-01-01 21:27:37.229 [DEBUG] [o.o.b.c.internal.CalDavBinding] - calendar reloaded: openhab
2016-01-01 21:27:37.229 [TRACE] [.i.c.internal.CalDavLoaderImpl] - quering events for filter: CalDavQuery [calendarIds=[openhab], from=2016-01-01T21:27:37.229Z, to=null, sort=ASCENDING]
2016-01-01 21:27:37.229 [DEBUG] [.i.c.internal.CalDavLoaderImpl] - return event list for CalDavQuery [calendarIds=[openhab], from=2016-01-01T21:27:37.229Z, to=null, sort=ASCENDING] with 0 entries
2016-01-01 21:27:37.230 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_NextEvent_Time2, setting to UNDEF
2016-01-01 21:27:37.231 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_NextEvent_Time1, setting to UNDEF
2016-01-01 21:27:37.231 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_NextEvent_Name1, setting to UNDEF
2016-01-01 21:27:37.232 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_CurrentEvent_Time0, setting to UNDEF
2016-01-01 21:27:37.233 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_AllEvents, setting to UNDEF
2016-01-01 21:27:37.233 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_NextEvent_Name2, setting to UNDEF
2016-01-01 21:27:37.233 [DEBUG] [o.o.b.c.internal.CalDavBinding] - no event found for Cal_CurrentEvent_Name0, setting to UNDEF
2016-01-01 21:27:37.234 [TRACE] [.i.c.internal.CalDavLoaderImpl] - quering events for filter: CalDavQuery [calendarIds=[openhab], from=2016-01-01T21:27:37.234Z, to=null, sort=null]
2016-01-01 21:27:37.234 [DEBUG] [.i.c.internal.CalDavLoaderImpl] - return event list for CalDavQuery [calendarIds=[openhab], from=2016-01-01T21:27:37.234Z, to=null, sort=null] with 0 entries
2016-01-01 21:27:37.234 [TRACE] [.i.c.internal.CalDavLoaderImpl] - ------------ list 1 -------------
2016-01-01 21:27:37.234 [TRACE] [.i.c.internal.CalDavLoaderImpl] - cpnpaul9-hsy8-oteh-b3qw-8y0adwrhxf2i(Control Playroom Lights email@example.com/15:48-01.01.2016/15:49)
2016-01-01 21:27:37.234 [TRACE] [.i.c.internal.CalDavLoaderImpl] - ------------ list end ---------
2016-01-01 21:35:41.282 [TRACE] [p.c.i.CaldavPersistenceService] - persisting item: Light_GF_Hallway (Type=DimmerItem, State=35)
2016-01-01 21:35:41.282 [DEBUG] [p.c.i.CaldavPersistenceService] - creating new event
2016-01-01 21:35:41.282 [DEBUG] [p.c.i.CaldavPersistenceService] - new event for persistence created: org.openhab.io.caldav.CalDavEvent@f0489978
(Prior to the above logs is a detailed vCard for a test calendar entry I had).
openhab.cfg config section is as follows:
caldav.persist file contains just the following:
default = everyChange
PresenceSimulationGroup* : strategy = everyChange
It would be great if the binding could automatically cater for presence simulation based on historical persistence data in the same way that the GCal binding used to do.
Sorry, persistence isn’t documented yet, i will update the wiki.
You need these entries:
# calendar where the events should be created inside
# duration of a created event (in minutes)
Great, thanks. I will try that.
Is there any chance you could put in the presence simulation mechanism into the binding at some point?
EDIT: Works perfectly! For the presence simulation, given that the persistence data is already in the command format, a simple solution may be to have a parameter that allows the persistence data to be saved a fixed number of days in the future. Thanks again for this binding and your fast support!
This is untested, but feel free to test it.
########################### calDAV Persistence Service ##################################
# Every item which is stored, results in an event entry in the defined calendar
# Calendar ID, which is defined in calDAV IO section
# Default duration for an calendar entry is 5 minutes
# For Switch-, Contact- and Percent-Items it is possible to create events,
# with the correct duration for e. g. Switch ON to Switch OFF, otherwise every item change
# will result in a new single calendar entry.
# Used to create current occuring events in the future. (for presence simulation)
# Default is 0
#caldav-persistence:futureOffset=<offset in days>
Wow - thanks for the quick turn around! I’ll start testing it as soon as I get back home.
Is there a specific item name that we need to use to stop/start the simulation commands from taking effect when the home is occupied? i.e.similar to the caldav-command type DISABLED that you already have for individual items, but that can be used to disable/enable all items in one go?
Ok for start/stop simulation you can use this. You can use the DISABLED to toggle on Item-Groups.
Thanks. One thing I’m seeing with the version you released yesterday is that the futureOffset may not be working correctly, or at least I may not be understanding it.
At the moment, it seems as if the entries are still going in into today’s date but are being extended to the 14 days of the futureOffset value. E.g. the parameters in the openhab.cfg are:
This gives calendar entries for today (I deleted the calendar and started with a new one after updating the binding yesterday). Those lights that haven’t gone off yet since the morning have been extended for the 14 days, e.g. Light_GF_Living_Reading:
I also tried with
singleEvents=true, but all this did was again create entries in today’s diary but this time, every single entries had a duration of 14 days regardless of how long the light was actually on for in real life.
Anyway, I will try the new build and see how that goes.