MMM-CalendarExt3 not syncing automatically with icloud

sdetweil

@lightfixer2000 I try not to use services anymore as pm2 can launch anything, like my installer sets up for MagicMirror.

see the pm2 --help

lightfixer2000

@sdetweil Thanks. I have pm2 installed and it runs MMM at boot up. According to the timer file the first fetch is after 2 mins of program start. I still don’t see any update to the ics file.
I will read pm2 help is a config or something else with pm2 I should be using?

sdetweil

@lightfixer2000 pm2 start xxx

xxx can be a bash script
or an executable

if you the bash script the you can ha e multile commands and logic

pm2’s job is to start and run things and keep them running

MMRIZE

@lightfixer2000
I’m not using vdirsyncer to get iCloud or Google private/family calendars as iCal. So I have no idea.
Instead I use MMM-CalDAV. Sorry.

lightfixer2000

@MMRIZE Hi thanks for the heads up on CalDAV. Is this also a program which can deal privately with iCloud calendars? Rather than Vdirsyncer? Thanks.

lightfixer2000

Update. So I have removed Vdirsyncer and installed MMM-CalDAV.
I have two calendars running, the standard calendar which I have set to UK Holidays and our shared icloud family calendar.
CalDav is accessing my shared family icloud calendar. I see timed single events ok and even events spread over a couple of days. But, it is still not showing repeating weekly events. You see the initial start date/event and that is all.
Having read quite a few posts on missing events I have tried several suggestions to no effect. Checking the family ics file I see the data there. However, there is no RRULE listing associated with these events.
Also should there be further data on the URL VALUE? I have not deleted anything, but its blank. Is this because CalDAV is handling the URL?
Here is part of the shared ics file. I’ve deleted UID in case this unique to me.

BEGIN:VEVENT
DTSTAMP:20240411T163851Z
CREATED:20240410T140919Z
DTSTAMP:20240411T112142Z
LAST-MODIFIED:20240411T112141Z
SEQUENCE:3
SUMMARY:Testing….
UID:******
URL;VALUE=URI:
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
X-APPLE-CREATOR-TEAM-IDENTITY:0000000000
TRANSP:OPAQUE
X-RECURRENCE-MASTER:True
DTSTART;TZID=Europe/London:20240412T130000
DTEND;TZID=Europe/London:20240412T140000
RECURRENCE-ID:20240412T120000Z
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20240411T163851Z
CREATED:20240410T140919Z
DTSTAMP:20240411T112142Z
LAST-MODIFIED:20240411T112141Z
SEQUENCE:3
SUMMARY:Testing….
UID:*****
URL;VALUE=URI:
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
X-APPLE-CREATOR-TEAM-IDENTITY:0000000000
TRANSP:OPAQUE
DTSTART;TZID=Europe/London:20240419T130000
DTEND;TZID=Europe/London:20240419T140000
RECURRENCE-ID:20240419T120000Z
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20240411T163851Z
CREATED:20240410T140919Z
DTSTAMP:20240411T112142Z
LAST-MODIFIED:20240411T112141Z
SEQUENCE:3
SUMMARY:Testing….
UID:******
URL;VALUE=URI:
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
X-APPLE-CREATOR-TEAM-IDENTITY:0000000000
TRANSP:OPAQUE
DTSTART;TZID=Europe/London:20240426T130000
DTEND;TZID=Europe/London:20240426T140000
RECURRENCE-ID:20240426T120000Z
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20240411T163851Z
CREATED:20240410T140919Z
DTSTAMP:20240411T112142Z
LAST-MODIFIED:20240411T112141Z
SEQUENCE:3
SUMMARY:Testing….
UID:******
URL;VALUE=URI:
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
X-APPLE-CREATOR-TEAM-IDENTITY:0000000000
TRANSP:OPAQUE
DTSTART;TZID=Europe/London:20240503T130000
DTEND;TZID=Europe/London:20240503T140000
RECURRENCE-ID:20240503T120000Z
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20240411T163851Z
CREATED:20240410T140919Z
DTSTAMP:20240411T112142Z
LAST-MODIFIED:20240411T112141Z
SEQUENCE:3
SUMMARY:Testing….
UID:******
URL;VALUE=URI:
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
X-APPLE-CREATOR-TEAM-IDENTITY:0000000000
TRANSP:OPAQUE
DTSTART;TZID=Europe/London:20240510T130000
DTEND;TZID=Europe/London:20240510T140000
RECURRENCE-ID:20240510T120000Z
END:VEVENT
BEGIN:VEVENT
DTSTAMP:20240411T163851Z
CREATED:20240410T140919Z
DTSTAMP:20240411T112142Z
LAST-MODIFIED:20240411T112141Z
SEQUENCE:3
SUMMARY:Testing….
UID:******
URL;VALUE=URI:
X-APPLE-CREATOR-IDENTITY:com.apple.mobilecal
X-APPLE-CREATOR-TEAM-IDENTITY:0000000000
TRANSP:OPAQUE
DTSTART;TZID=Europe/London:20240517T130000
DTEND;TZID=Europe/London:20240517T140000
RECURRENCE-ID:20240517T120000Z
END:VEVENT

Reading the posts I gather there is on an ongoing issue with regard to RRULE. Is this the cause of the problem?
I have tried returning node-ical back to its previous version 16 also with no effect.
Am I missing something really obvious?
Any further suggestions or help greatly received. Thanks.

sdetweil

@lightfixer2000 MMM-CalDav is creating the ics file

the node-ical problem is processing the rrule, if any

i have not seen reports of calendar troubles with the latest mm release on April 1

lightfixer2000

@sdetweil
A couple of questions for my understanding.
Does RRULE make calendar display repeat events?
Is CalDAV responsible for dropping the RRULE?
Is it possible to show repeat weekly events?

MMRIZE

@lightfixer2000
At this moment, I’m unsure the exact symptom what you said.
There is an undocumented options for more detail configuration.
Try expand: false, in your module config.

{
  module: "MMM-CalDAV", 
  config: {
    servers: [
      { 
        envPrefix: "ICLOUD_", // I assumed.
        serverUrl: "https://caldav.icloud.com", 
        expand: false,  // <== This.
        targets: [
        ...

I’m not sure whether this will help yours or not. I just suspect.

PS. (more detail).
This option is related to expanding repeated events to a series of single independent events. As far as I remember, in some prior calendars, there were some issues handling repeated events by RRULE. So, I made this module to forcefully avoid that issue by default. I think recently things might be changed, so hidden option expand: true might cause your symptom.

sdetweil

@lightfixer2000 RRULE stands for Repeating Rule
it handles ALL the rules that make this event happen again (on some cycle)
it is optional… as some (most) events don’t repeat

MMM-CalDav is processing the caldav calendar and creating the ICS file we process, using the ICAL standards.

if there is no RRULE, then it is not repeating.
the default calendar does not look at the text of the ICS file, we download it, then send it to the node-ical module to convert the text into workable objects.
it replicates the RRULE into an object in the event entry, and then we check for the RRULE object… if present we ask the RRULE library for the events that match the rules in the next year.