Calendar Modul pars-Logik für RRULE

Begonnen von JudgeDredd, 13 September 2026, 11:20:18

Vorheriges Thema - Nächstes Thema

JudgeDredd

Hallo Zusammen,

ich nutze das Kalender Modul schon lange und bin sehr zufrieden. Vielen Dank vorab schonmal an Boris für die Bereitstellung.

Heute bin ich in Vorbereitung einer MS-Exchange Ablösung über folgende Ungereimtheit gestoßen.

VEVENT:
1: VEVENT @26 [known]
    CREATED: 20260912T153502Z
    DTEND: 20200122T110000
    DTSTAMP: 20260912T153614Z
    DTSTART: 20200122T100000
    LAST-MODIFIED: 20260912T153614Z
    RRULE: FREQ=WEEKLY;COUNT=2;BYDAY=WE
    SEQUENCE: 3
    STATUS: CONFIRMED
    SUMMARY: untertägiger Termin mit 2 Wiederholungen
    TRANSP: OPAQUE
    UID: bd6e954e-bc34-4c9d-8bbd-03ef059896d5
    >>> is a series
    >>> Events:
      bd6e954ebc344c9d8bbd03ef059896d5         end                     13.08.2025 10:00-13.08.2025 11:00 untertägiger Termin mit 2 Wiederholungen   
      bd6e954ebc344c9d8bbd03ef059896d5         end                     20.08.2025 10:00-20.08.2025 11:00 untertägiger Termin mit 2 Wiederholungen   
    >>> Skipped events:

DTSTART liefert das Datum: 22.01.2020/10:00:00
RRULE besagt 2 wöchentliche Wiederholungen, was zu dem manuell berechneten Endedatum 29.01.2020 führt.

Wie man aber im Kalendermodul (get <calName> vevents) sieht, generiert er dabei 2 Events am 13.08.2025 & 20.08.2025

Aus meiner Sicht ist das nicht nachvollziehbar.
Kann mir das Jemand erklären oder hat das parsen der RRULE noch einen Bug ?

Gruß,
JudgeDredd
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

betateilchen

Da diese events in der Vergangenheit liegen und somit nicht mehr relevant werden, würde ich mir darüber keine allzu großen Gedanken machen.
Mit dem Attribut cutOffOlderThan kannst Du das vermutlich komplett bereinigen.


Generell gilt: RRULE ist in Calendar nicht vollständig implementiert.

Before the regular creation is done, events for RDATEs are added as long as
an RDATE is not superseded by an EXDATE. An RDATE takes precedence over a
regularly created recurring event.

Starting with the start date of the series, one event is created after the
other. Creation stops when the series ends or when an event more than 400 days
in the future has been created. If the event is in the list of exceptions
(either defined by other events with same UID and a RECURRENCE-ID or by the
EXDATE property), it is not added.

What attributes are recognized and which of these are honored or ignored?

The following frequencies (FREQ) are recognized and honored:
SECONDLY
MINUTELY
HOURLY
DAILY
WEEKLY
    BYDAY: recognizes and honors one or several weekdays without prefix (e.g. -1SU, 2MO)
MONTHLY
    BYDAY: recognizes and honors one or several weekdays with and without prefix (e.g. -1SU, 2MO)
    BYMONTHDAY: recognized but ignored
    BYMONTH: recognized but ignored
YEARLY

For all of the above:
    INTERVAL: recognized and honored
    UNTIL: recognized and honored
    COUNT: recognized and honored
    WKST: recognized but ignored
    EXDATE: recognized and honored
    RDATE: recognized and honored

*** Step 4: The device readings related to updates are set

- calname
- lastUpdate
- nextUpdate
- nextWakeup
- state
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

JudgeDredd

Hi betateilchen,
Zitat von: betateilchen am 13 September 2026, 13:37:15Da diese events in der Vergangenheit liegen und somit nicht mehr relevant werden, würde ich mir darüber keine allzu großen Gedanken machen.
Ja, soweit der Plan. Aber ich würde gerne ausschließen, dass nicht auch mal "fehlerhafte" events erzeugt werden, die in der Zukunft liegen. Auch durch die Tatsache, das es für mich sehr "willkürlich" aussieht. Warum gerade das Jahr 2025 ?
Zitat von: betateilchen am 13 September 2026, 13:37:15Mit dem Attribut cutOffOlderThan kannst Du das vermutlich komplett bereinigen.
Das Attribut definiert aber keinen Importfilter und ignoriert die vergangenen Einträge, sondern das Modul liest  immer den kompletten Kalender ein und verbirgt die Einträge die vor dem Attribut-Datum liegen nur.

Grundsätzlich stören mich "end"-Events nicht, und von Problemen beim parsen der RRULE liest man ja auch im Netz. Es gibt wohl ein NodeJS-Module das recht zuverlässig funktioniert, aber das nutzt das Calendar-Modul ja nicht.

Aber vielleicht hat ja Boris noch eine Erklärung.
Router: Eigenbau (pfSense)
FHEM: Proxmox (DELL R720) | Debian 12 (VM)

betateilchen

Zitat von: JudgeDredd am 13 September 2026, 14:09:03das es für mich sehr "willkürlich" aussieht. Warum gerade das Jahr 2025 ?

Das ist nicht willkürlich, sondern nachvollziehbar.

  • Das Modul rechnet 400 Tage zurück, wenn Du das von heute ausgehend machst, landest Du beim 09.08.2025.
  • Somit sind die beiden ermittelten Termine am 13.08.25 und am 20.08.25 die beiden ersten Termine, die innerhalb der Serie im 400-Tage-Fenster liegen.
  • Und da die Serie nach zwei Terminen endet, gibt es keine weiteren Termine.
  • Machst Du die Abfrage in 4 Wochen, kommen entsprechend zwei andere (spätere) Termine in 2025 raus.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!