Test Adapter Calendar v1.2.x

[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" 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.

[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

[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

maxblome created this issue in WLAN-Kabel/ioBroker.calendar

closed iCal: Incorrect handling of date and time #24

[D3ltoroxp]

Hallo J-A-R-V-I-S,
erst mal vielen Dank für die Entwicklung an solch einem Adapter. Habe den ical getestet, mit dem bekomme ich aber nicht alle Termine rein. Auch das man später vllt Termine so erstellen kann ist sehr interessant.

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

Füge "JavaScript Quellen" folgenden Eintrag hinzu: http://<FQDN aus Adapterconfig>:<Port aus Adapterconfig>
Füge bei "Authorisierte Rediret URIs" folgende Einträge hinzu: http://<FQDN aus Adapterconfig>:<Port aus Adapterconfig>/google und http://<FQDN aus Adapterconfig>:<Port aus Adapterconfig>/google/

Bis dahin hab ich alles, Client ID und Co sind erstellt. Nur das hier kapier ich nicht ganz. Mein ioBroker läuft auf einem NUC (Linux) im Netzwerk. Das heißt, ich müsste erst

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

Wichtig: Sollte dein ioBroker nicht lokal laufen, musst du zunächst noch folgende Schritte durchführen:

ausführen ? Hier am Rechner habe ich Windows laufen, geht das überhaupt ? Könnte mir hier noch mal jemand etwas genauer Helfen und unter die Arme greifen ? Was ist das z.b. für eine IP Adresse ?
192.168.0.10 example.com //<IP-Adresse ioBroker> <FQDN> Die meines Rechners, meine ausgehende ? Die von meinem Router ?

[liv-in-sky]

@D3ltoroxp

https://forum.iobroker.net/post/342759

habe es letzte woche eingerichtet (bis dahin nur den contact adapter) - die adresse 192.168.178.36 ist mein win 10
192.168.178.59 ist iobroker

was ich wirklich davon brauche weiß ich nicht wirklich - aber damit funktionierte es , wie bei dem contact adapter
aber danach konnte ich die adresse aufrufen, die im log angezeigt wird und den account freischalten

[hsteinme]

@D3ltoroxp: Auch wenn es erst 18 Stunden her ist, einfach mal zur Erinnerung:

@hsteinme sagte in Bekomme nichts vom Google Kalender (iCAL Adapter) zu @D3ltoroxp:

... empfehle ich Dir, in einem ersten Schritt das ganze Google Authorisierungsgeraffel zu umgehen und die private Adresse Deines Google-Kalenders in den Webdav-Einstellungen des Adapters einzubinden.

Nun steckst Du also mitten in diesem Google Authorisierungsgeraffel drin. Warum willst Du Dir im ersten Schritt das Leben selbst so schwer machen und den Ratschlag mit der Webdav-Schnittstelle ignorieren?