caldavCommand triggers at right time, but no command to item

Hello,

I have setup caldavCommand, to the point where it really reads and syncs my calendar events at the right time. E.g. it logs to openhab.log:

2017-11-04 15:55:00.002 [INFO ] [nhab.io.caldav.internal.job.EventJob] - event BEGIN for: C73732B1-4FFC-4AA0-82FC-1125BB213CAE(openhab test@04.11.2017/15:55-04.11.2017/15:57)
2017-11-04 15:57:00.002 [INFO ] [nhab.io.caldav.internal.job.EventJob] - event END for: C73732B1-4FFC-4AA0-82FC-1125BB213CAE(openhab test@04.11.2017/15:55-04.11.2017/15:57)

So I assume there is no problem with the basic caldav connection and sync. Still I do not get the switch “Fritz_Esszimmer_Switch” turned ON or OFF (i.e. nothing is logged in events.log).
This is my ics entry as I find it replicated by the binding:

BEGIN:VCALENDAR
CALSCALE:GREGORIAN
PRODID:-//Apple Inc.//iOS 11.0.3//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
DTSTART:19810329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
TZNAME:MESZ
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
END:DAYLIGHT
BEGIN:STANDARD
DTSTART:19961027T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
TZNAME:MEZ
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20171104T105552Z
DESCRIPTION:BEGIN:Fritz_Esszimmer_Switch:ON\nEND:Fritz_Esszimmer_Switch:O
 FF\n
DTEND;TZID=Europe/Berlin:20171104T155700
DTSTAMP:20171104T145304Z
DTSTART;TZID=Europe/Berlin:20171104T155500
LAST-MODIFIED:20171104T145304Z
SEQUENCE:11
SUMMARY:openhab test
TRANSP:OPAQUE
UID:C73732B1-4FFC-4AA0-82FC-1125BB213CAE
URL;VALUE=URI:
BEGIN:VALARM
ACTION:NONE
TRIGGER;VALUE=DATE-TIME:19760401T005545Z
END:VALARM
END:VEVENT
END:VCALENDAR

Is this ics entry looking like it should? At least for my eyes the DESCRIPTION looks as expected.

Or do I have to go to the item file where Fritz_Esszimmer_Switch is declared and add something?
This is the caldavCommand v1 binding running on a very recent openhabianpi 2.1.0-1.

Any clues?

Kind regards,
Michael

Maybe somebody could confirm that it SHOULD work.

I am really quite desparate about this. I tried

  • different item type (Number, Switch)
  • different values (raw, quoted)
  • item names quoted
  • BEGIN/END command in SUMMARY field or in DESCRIPTION field
  • iPhone as calendar editor
  • Outlook as calendar editor

It is frustrating that:

  • the calendar entries are really copied to /var/lib/openhab2/etc/caldav/mycalendarname/SomeFilename.ics on my openHABianpi system
  • every BEGIN/END is logged to openhab.log at exactly the right minute
  • but still no value changes and nothing appears in events.log

I must be missing something really obvious, because all others having problems with caldavCommand binding reported success as sson as they got the entries synchronized.

Confirmed :sunglasses:

Unfortunately I have no idea how your problem could be solved. It all looks okay.

Here is one ics from my working setup for Test_Switch, maybe you could compare it with yours:

BEGIN:VCALENDAR
PRODID:-//Mozilla.org/NONSGML Mozilla Calendar V1.1//EN
VERSION:2.0
BEGIN:VTIMEZONE
TZID:Europe/Berlin
BEGIN:DAYLIGHT
TZOFFSETFROM:+0100
TZOFFSETTO:+0200
TZNAME:CEST
DTSTART:19700329T020000
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=-1SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0200
TZOFFSETTO:+0100
TZNAME:CET
DTSTART:19701025T030000
RRULE:FREQ=YEARLY;BYMONTH=10;BYDAY=-1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
CREATED:20171105T204207Z
LAST-MODIFIED:20171106T121317Z
DTSTAMP:20171106T121317Z
UID:febf6811-3090-4db7-a009-dfb0d7c5c6de
SUMMARY:test5
STATUS:CONFIRMED
DTSTART;TZID=Europe/Berlin:20171106T132000
DTEND;TZID=Europe/Berlin:20171106T133000
CLASS:PUBLIC
SEQUENCE:7
DESCRIPTION:BEGIN:Test_Switch:ON\nEND:Test_Switch:OFF
X-MOZ-GENERATION:6
END:VEVENT
END:VCALENDAR

items:

Switch Test_Switch <switch> (gRestore)
Switch Test_Switch_value {caldavCommand="itemName:Test_Switch type:VALUE"}
DateTime Test_Switch_date {caldavCommand="itemName:Test_Switch type:DATE"}
Switch Test_Switch_disable {caldavCommand="itemName:Test_Switch type:DISABLE"}

(Only the first one is really needed, the others are optional)

sitemap:

Text item=Test_Switch_value label="Next command [%s]"
Text item=Test_Switch_date label="Date/Time next command [%1$td.%1$tm., %1$tH:%1$tM]"
Switch item=Test_Switch_disable	label="Disable Test_Switch commands"
Switch item=Test_Switch label="caldav Test Switch"

nextCloud setup:

caldavCommand.cfg:

caldavCommand:readCalendars=openhab_command

caldavio.cfg:

caldavio:openhab_command:url=https://mydomain.de/remote.php/dav/calendars/test/ohcommand
caldavio:openhab_command:username=username
caldavio:openhab_command:password=password
caldavio:openhab_command:reloadInterval=5 //for testing
caldavio:openhab_command:preloadTime=5 //for testing
caldavio:timeZone=Europe/Berlin

Calendar entry:

BEGIN:Test_Switch:ON
END:Test_Switch:OFF
1 Like

Thank you for your help. The one difference I can see is that your item is a virtual one (not bound otherwise) whereas my switch has an existing binding to homegear.
But then again: I checked with a virtual Number item as well, which doesn’t have any binding.

Is there something special behind your gRestore group? Or is this just a group controlling the last-value persistence?

And my caldavCommand.cfg is:

caldavCommand:readCalendars=caldavio:openhabBaikal

That I would have to use that prefix was stated in some thread about migration from OH1 to OH2.
I assumed that I had no issues at that level of configuration because the entries are scheduled at the right time. But maybe I should give it a try w/o that prefix.

UPDATE:

That really is the solution. The “caldavio:” prefix in my caldavCommand.cfg was ill-guided. Deleting it solves the problem. My fault was that I assumed when the *.ics entries from my calendar are synced and EventJobs are scheduled at the right time, then the readCalendar statement would be right, i.e. because it points to the right calendar. But it seems EventJobs are already scheduled if the caldavio.cfg alone is configured. Strange.

1 Like

Correct

Yepp. You have found your problem :grinning:

Also make sure your config in caldavio.cfg matches:

caldavio:openhabBaikal:

1 Like

Thank you; see the update on my previous post.

Arrrgh I can’t believe it took me this long to understand that the calendar name in caldavCommand:readCalendars=blah has to match caldavio:blah:

I thought readCalendars referred to the actual calendar names inside the caldav server, so i had “owncloud” in one file and “openhab” in the other. No wonder it never worked!

Thanks for the clarification, now that I look at the documentation again it makes perfect sense but maybe it should be clarified that we are referring to the caldavio instance name by calling the variable in the example something else than calendar-id :wink:

1 Like