Monatsrückblick Januar/Februar 2026 ist online!

[ticaki]

Hallo,

gibt es eine Möglichkeit vergangene Termine anzuzeigen?

[Bostil]

@ticaki Würde mich auch interessieren - danke.

[J.A.R.V.I.S.]

@Bostil sagte in Test Adapter Calendar v1.1.x:

Hallo zusammen, gibt es eine Möglichkeit den Kalenderhintergrund auch transparent / farblos einzustellen?

Ja, du kannst im Abschnitt "CSS Hintergrund" als "background-color" folgendes eintragen:

rgba(0, 0, 0, 0);

@ticaki sagte in Test Adapter Calendar v1.1.x:

gibt es eine Möglichkeit vergangene Termine anzuzeigen?

Aktuell noch nicht, aber du hast das Thema dankenswerterweise schon in Github aufgenommen.

[e-s]

@J-A-R-V-I-S
Ich hatte es damals vergessen ein issue anzulegen.

[Bostil]

@J-A-R-V-I-S Danke dir - hat wunderbar funktioniert!

[J.A.R.V.I.S.]

@e-s nicht so schlimm, ich hatte das damals wohl auch vergessen.

[J.A.R.V.I.S.]

1.1.3 (2020-03-22)

• Möglichkeit zum Laden von ICS-Dateien von Webservern hinzugefügt @Kueppert
• Option zum Ignorieren von Zertifikatfehlern hinzugefügt @schdief
• CalDAV 'time range' wird verwendet, um den Datenverkehr zu reduzieren
• CalDAV Bibliothek überarbeitet
• Google-Funktionen in eigene Bibliothek ausgelagert
• CalDAV-Fehler behoben, der auftrat, wenn Endzeiten fehlten
• Weitere Debug-Meldungen hinzugefügt

[hsteinme]

@J-A-R-V-I-S sagte in Test Adapter Calendar v1.1.x:

1.1.3 (2020-03-22)

Möglichkeit zum Laden von ICS-Dateien von Webservern hinzugefügt

Ganz herzlichen Dank! Auf diese Funktion hatte ich gewartet.

Ich habe einen Google-Kalender über seine private ical-Webadresse über die CALDAV-Schnittstelle in eine Instanz des Calendar Adapters eingebunden. Beim folgenden Beispiel eines Termins scheinen Umrechnungsprobleme bei den Zeiten aufzutreten:

In den Calendar-Datapoints liefern diese beiden Termine jedoch teilweise "verschobene" Zeiten:

[{"summary":"Wecker x","description":"","startTime":"2020-03-21T05:20:00","endTime":"2020-03-21T05:50:00"},
{"summary":"Roomba x","description":"","startTime":"2020-03-21T04:15:00","endTime":"2020-03-21T06:00:00"}]

Hier der entsprechende Auszug aus der zugehörigen ics-Datei:

BEGIN:VCALENDAR
PRODID:-//Google Inc//Google Calendar 70.9054//EN
VERSION:2.0
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:ioBroker
X-WR-TIMEZONE:Europe/Berlin

BEGIN:VTIMEZONE
TZID:Europe/Berlin
X-LIC-LOCATION: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
DTSTART:20200321T052000Z
DTEND:20200321T055000Z
DTSTAMP:20200322T225300Z
UID:2b2j5q6s5p636oohitn8eq8ic9@google.com
CREATED:20200315T214351Z
DESCRIPTION:
LAST-MODIFIED:20200322T225023Z
LOCATION:
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Wecker x
TRANSP:OPAQUE
END:VEVENT

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20200321T041500
DTEND;TZID=Europe/Berlin:20200321T060000
DTSTAMP:20200322T225300Z
UID:183l6bmbuh75389a32no224hms@google.com
RECURRENCE-ID;TZID=Europe/Berlin:20200321T051500
CREATED:20200112T174139Z
DESCRIPTION:
LAST-MODIFIED:20200322T225008Z
LOCATION:
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Roomba x
TRANSP:OPAQUE
END:VEVENT

END:VCALENDAR

Schau Dir das bitte mal näher an.

[J.A.R.V.I.S.]

@hsteinme danke für die Rückmeldung. Dann scheint da wohl etwas mit den Zeitzonen noch nicht zu stimmen. Werde ich mir anschauen.

[hsteinme]

@J-A-R-V-I-S sagte in Test Adapter Calendar v1.1.x:

Dann scheint da wohl etwas mit den Zeitzonen noch nicht zu stimmen.

Ja, klar! Warum auch immer hat Google hier zwei verschiedene Datumsformate gewählt:

• Roomba x: Explizite Angabe des Timezone Identifiers ("TZID=Europe/Berlin")
• Wecker x: Darstellung im UTC-Format ("Z")

Es sieht so aus, als würde die Umrechnung von UTC nach CET in zweiten Fall fehlen.

[hsteinme]

@hsteinme sagte in Test Adapter Calendar v1.1.x:

Es sieht so aus, als würde die Umrechnung von UTC nach CET in zweiten Fall fehlen.

Vielleicht gibt es ja einen Zusammenhang mit dem gerade entdeckten Logeintrag:

calendar.1	2020-03-23 08:48:10.991	info	(11331) Updated calendar "ioBroker"
calendar.1	2020-03-23 08:48:10.991	error	(11331) TypeError: Cannot read property 'val' of undefined
calendar.1	2020-03-23 08:48:10.990	debug	(11331) {"prodid":"-//Google Inc//Google Calendar 70.9054//EN","version":"2.0","calscale":"GREGORIAN","method":"PUBLISH","events":[{"dtstart":{"val":"20200323T060500Z"},"dtstamp":"20200323T074810Z","u
calendar.1	2020-03-23 08:48:10.989	debug	(11331) PARSED ICAL
calendar.1	2020-03-23 08:48:10.683	debug	(11331) Read events of 'ioBroker'

[hsteinme]

@J-A-R-V-I-S sagte in Test Adapter Calendar v1.1.x:

1.1.3 (2020-03-22)
CalDAV-Fehler behoben, der auftrat, wenn Endzeiten fehlten

Auch in Version 1.1.3 treten auf der CalDAV Schnittstelle Probleme mit "endlosen" :blush: Terminen auf. Der folgende 09:15 Uhr Termin wird z.B. nicht vom Adapter übernommen:

[{"summary":"Test #2","description":"","startTime":"2020-03-23T08:20:00","endTime":"2020-03-23T08:25:00"}]

BEGIN:VEVENT
DTSTART:20200323T082000Z
DTEND:20200323T082500Z
DTSTAMP:20200323T081242Z
UID:2sfke795d0lmm4dk9tfhfr54hv@google.com
CREATED:20200323T080455Z
DESCRIPTION:
LAST-MODIFIED:20200323T080455Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Test #2
TRANSP:OPAQUE
END:VEVENT

BEGIN:VEVENT
DTSTART:20200323T081500Z
DTSTAMP:20200323T081242Z
UID:2e2p5mu0ghooaquhqr6vsgcjr3@google.com
CREATED:20200323T080119Z
DESCRIPTION:
LAST-MODIFIED:20200323T080418Z
LOCATION:
SEQUENCE:1
STATUS:CONFIRMED
SUMMARY:Test #1
TRANSP:OPAQUE
END:VEVENT

[hsteinme]

calDAV Schnittstelle: Ein über mehrere Tage dauernder Termin wird im Adapter nur im Datapoint des Anfangstages vermerkt, nicht jedoch in den Datapoints der folgenden Tage. Feature oder Fehler?

[hsteinme]

calDAV Schnittstelle: Der Logdatei entnehme ich, dass die Termin-Datenpunkte im 10-Minuten-Takt einen Update erfahren. Dazu ein Doppelwunsch:

• Bitte die Taktlänge konfigurierbar machen.
• Bitte einen Button-Datenpunkt calendar.x.refresh bereit stellen, mit dem ein Update der Termin-Datenpunkte aller Kalender angestoßen werden kann.

Beide Neu-Features wären nicht nur in Test-Situationen hilfreich. Das bereits jetzt vorhandene "Feature", den Datenpunkt-Update über einen Restart der Instanz zu initiieren, ist sicherlich kein "schöner" Ansatz.

[hsteinme]

calDAV Schnittstelle: Von Terminserien wird nur der erste Termin in den Datenpunkten angezeigt, nicht jedoch die Folgetermine.

BEGIN:VEVENT
DTSTART;TZID=Europe/Berlin:20200323T133000
DTEND;TZID=Europe/Berlin:20200323T143000
************************
RRULE:FREQ=DAILY;COUNT=4
************************
DTSTAMP:20200323T093754Z
UID:2qa6j60e6p2pfv0ig84011b0hv@google.com
CREATED:20200323T093044Z
DESCRIPTION:
LAST-MODIFIED:20200323T093044Z
LOCATION:
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Test Serie
TRANSP:OPAQUE
END:VEVENT

Google-Schnittstelle: Hier tritt dieses Problem nicht auf.

[J.A.R.V.I.S.]

@hsteinme danke für das intensive testen und die detaillierten Rückmeldung. Dann werde ich da wohl noch ein bisschen nachbessern müssen. :blush:

[hsteinme]

@J-A-R-V-I-S sagte in Test Adapter Calendar v1.1.x:

Dann werde ich da wohl noch ein bisschen nachbessern müssen.

Nein, das musst Du nicht. Ich würde mich aber freuen, wenn Du es tun würdest :+1:

[J.A.R.V.I.S.]

@hsteinme naja, der Adapter soll ja keine falschen Daten anzeigen.

[RandyAndy]

@hsteinme sagte in Test Adapter Calendar v1.1.x:

calDAV Schnittstelle: Ein über mehrere Tage dauernder Termin wird im Adapter nur im Datapoint des Anfangstages vermerkt, nicht jedoch in den Datapoints der folgenden Tage. Feature oder Fehler?

Dieses Ergebnis kann ich nur bestätigen. Da ich damit Aufenthalte von Feriengästen anzeigen will ist der Adapter so noch nicht brauchbar.

Andreas

[J.A.R.V.I.S.]

@hsteinme @RandyAndy das werde ich überarbeiten. Danke für die Rückmeldung.

https://github.com/WLAN-Kabel/ioBroker.calendar/issues/24