[SOLVED] Bad TRIGGER for VALARM, skipping!

We are using the calendar functionality (with Nextcloud) to decide on call forwarding successfully. Now we had the use case of implementing a wake-up call which seems to be pretty straight forward but…
It does not work as expected - it throws an error and does not work at all. We are running 18.3.0 with CalDAV. The configuration is

[91]
type = caldav
url = https://<domain>/remote.php/dav/calendars/<uuid>/<user>/
user = <username>
secret = <most secure password ever>
refresh = 5
timeframe = 60
channel = SIP/XXXX
app=Playback
appdata=wakeup-call

The calendar event is:

BEGIN:VEVENT
CREATED:20210419T142719Z
DTSTAMP:20210419T142739Z
LAST-MODIFIED:20210419T142739Z
SEQUENCE:2
UID:670870a5-dcf8-4f6a-936e-0b3369b6472c
DTSTART;TZID=Europe/Berlin:20210419T163000
DTEND;TZID=Europe/Berlin:20210419T163500
SUMMARY:WUC
BEGIN:VALARM
ACTION:DISPLAY
TRIGGER;RELATED=START:PT0S
END:VALARM
END:VEVENT

When the event should trigger a call the following error arises:

res_calendar_caldav.c:452 caldav_add_event: Bad TRIGGER for VALARM, skipping!

Even enabling debug on the calendar and caldav module does not provide any information regarding this failure. Has anybody got a clue? Thanks in advance.

Have you tried playing with the TRIGGER line, by omitting the trigger relation of setting the offset to something like -1 minute?

In the past I’ve repeatedly seen programs that sometimes have difficulties with the some iCalendar specs.

Not yet. I have to provide the calendar data manually then.
So if this works does it mean it is an asterisk bug or do I have to raise a Nextcloud ticket? I am not familiar with the CalDAV RFC.

Good question. I personally would patch the Asterisk sources and then see if others are interested in the patch.

Seems to be the way to go. I’ll might have look.
One funny thing occurs. Suddenly - kind of 1 or 2 hours later - the phone rings and gives me the wake up call. At that point no event is written into the calendar and I am not fiddling with the asterisk.
At first glance the source of conflict seems to be within the system caldav library as the function is referenced in res_calendar_caldav.h.
If coffee is endless and nights available I dig into it …

If it is exactly 1 or 2 hours then it could be a timezone issue. The timestamps above use either explicity UTC time or Europe/Berlin, i.e. +2.

I can see the point and it is worth checking. I do remember the call did not happen exactly half past (as the original event date) but two minutes past. This may be a normal delay in terms of processing. Anyway, give me one or two days to check and I‘ll report.
If that’s the case (UTC/TZ) I consider it as a bug because our call forward calendar entries do work timely correct.

I finally made it. The main cause of confusion was the fact that the trigger label of the event section does not seem to accept relative time declarations (at least by the calendar module). After I used a full time specification for the alarm trigger label all goes as wanted. Thanks for you help!