Caldav peronal event sheduled only at reload

Add-ons Bindings
1

I tried to use the caldav binding with an caldavPersonal Switch item:

Switch CalUrlaub “Kalender Urlaub” (gKalender)
{ caldavPersonal=“calendar:mathias type:PRESENCE filter-name:’.Urlaub.’” }

The corresponding events are recognized, but the Switch receives the update only with an reload.

Debug log:

20:29:26.222 [DEBUG] [o.o.b.c.internal.CalDavBinding:203 ] - calendar reloaded: mathias
20:29:26.238 [DEBUG] [.i.c.internal.CalDavLoaderImpl:548 ] - return event list for CalDavQuery [calendarIds=[mathias], from=2016-11-06T20:29:26.238+01:00, to=null, sort=ASCENDING, filterName=.Urlaub.] with 1 entries
20:35:00.005 [INFO ] [o.caldav.internal.job.EventJob:55 ] - event BEGIN for: 7088d2dd-6954-40fe-824b-aa99a6a1bc7c(Test Urlaub@06.11.2016/20:35-06.11.2016/21:35)
…
20:39:24.533 [DEBUG] [o.o.b.c.internal.CalDavBinding:203 ] - calendar reloaded: mathias
20:39:24.533 [DEBUG] [.i.c.internal.CalDavLoaderImpl:548 ] - return event list for CalDavQuery [calendarIds=[mathias], from=2016-11-06T20:39:24.533+01:00, to=null, sort=ASCENDING, filterName=.Urlaub.] with 1 entries

The event starts at 20:35, but the Switch does not change to ON, it changes to ON after the reload as 20:39.

Here are the correspoding lines from event.log:

2016-11-06 20:29:26 - CalUrlaub received command OFF
2016-11-06 20:39:24 - CalUrlaub received command ON

I used only one calendar in this minimal test example and an reload intervall with 15 minutes. I tried to increase the number of quartz threads, but the behaviour ist the same.

Is there any workarround to update the script right at the start time of the event?

My workarround is to use a 15 minute reload intervall this is quite OK for the presence settings.

Thanks

Mathias

2

@MathiasMoog: I suffer from exactly the same problem, see CalDAV personal: Switch item ON only during server reload, but on time for OFF

Were you able to solve it? Thanks a lot!

3

Dear Tobi,

my post was quite old, but it seems, that the behaviour is the same. In 2016 I used an openHAB Version 1. The migration to Version 2 (at the moment 2.4) does not change the behaviour.
I had a look in my last log files. The behaviour ist excactly as you noted. It is switched to ON with the first reload after the event started. OFF is recognized immediately.

At the moment I use the CalDAV personal only for switching to and from vacations. My reload time is 30 minutes, and it does not matter if the vacations start some minutes later.

My calendar comes from an owncloud sever running on the same Raspberry PI as openHAB.

I’m sorry, but I never took the time to have a closer look on this behaviour.

Best regards

Mathias

4

Dear Mathias,

thanks for the reply after all this time. It is really helpful to see others have the same issue, so it is not a dumb mistake on my side. Up to now I only received feedback from people telling me the switch works for them.

So the issue is unresolved since three years? Is the binding even still maintained?

5

@MathiasMoog What is your setup? I use:

  • Raspberry Pi 3B plus
  • OH milestone (2.4 release currently)
  • GMX as calendar provider
  • Bindings installed: Only CalDAV personal for the tests
6

@Tobi77 My Setup is similar to yours. An Raspberry 3 running openHAB 2.4. Only the Caldav server differs. I use owncloud. But that should not matter.
I had a short look on the source code. It is an old binding from version 1. As far as I checked, there had been no essencial changed since end 2017.
Did you write the bug report https://github.com/openhab/openhab1-addons/issues/5744 ?

7

Yes, that is my hope to find someone who can care for it…

If you can contribute some details, please post them there as well. Thanks!

8

@Tobi77 I had a look on the source code and proposed a fix, see my comment in your bug report. Please check it.

9

@MathiasMoog Thanks, great initiative!
I am no programmer, so I cannot test github code. But as you already give a hint, maybe someone will be able to resolve this without too much effort, and pave the way to pull it to the next release… :slight_smile:

10

@MathiasMoog: Seems to be resolved in your patch :slight_smile:

See the Github discussion #5744. Can you make a pull request?

11

@MathiasMoog: In the GitHub thread https://github.com/openhab/openhab1-addons/issues/5744#issuecomment-459962287, @namraccr asks for additional logging data to understand some strange effects. Would it be possible you support the process? That would be great. Thanks!