UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

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

@schdief installier dir mal bitte die Development Version von Github https://github.com/WLAN-Kabel/ioBroker.calendar/tarball/development

Dann bitte auf Debug umstellen. Im Debug Modus wird die XML ausgegeben.

[schdief]

@J-A-R-V-I-S verstehe ich das richtig: development Version installieren. In der Instanzenansichtig Log Level auf Debug. -> Unter logs wird die XML ausgegeben?

calendar.0	2020-03-13 12:33:57.817	debug	(12396) Cron job started
calendar.0	2020-03-13 12:33:57.805	error	(12396) [200] Error: Attribute without value Line: 17 Column: 60 Char: >
calendar.0	2020-03-13 12:33:57.708	debug	(12396) HREF: http://xxxxx/?redirect_uri_403=%2FSurvey%2F
calendar.0	2020-03-13 12:33:57.538	info	(12396) starting. Version 1.1.2 in /opt/iobroker/node_modules/iobroker.calendar, node: v10.19.0

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

@schdief okay, der Fehler wird leider vorher geworfen. Ich werde heute nachmittag dahingehend etwas umbauen, damit das XML vorher abgefangen wird.

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

@schdief bitte lade dir noch einmal die Development Version herunter. Das XML sollte nun im Log ausgegeben werden.

[schdief]

Nein, hat sich immer noch nicht geändert. Wenn es dir hilft können wir auch den kurzen Dienstweg gehen und ich richte dir temporär einen User auf dem Nextcloud Server ein... ;)

Übrigends: Verbindung über HTTPS geht auch noch nicht. Aber das liegt evtl. an meinen selbstsignierten Zertifikaten.

calendar.0	2020-03-14 12:28:48.782	error	(7177) TypeError: Cannot read property 'statusCode' of undefined at Request.request [as _callback] (/opt/iobroker/node_modules/iobroker.calendar/lib/caldav.js:152:37) at self.callback (/opt/io
calendar.0	2020-03-14 12:28:48.782	error	(7177) uncaught exception: Cannot read property 'statusCode' of undefined

[Bostil]

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

danke euch!

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