[Aufruf] ical Adapter v1.7.0

[eric2905]

Moin,

@eric2905:

Habe die 1.7.0 seit 2 Tagen laufen … `

habe den 1.7.0 jetzt nochmal frisch auf ein Testsystem installiert (2 Instanzen) und dabei festgestellt, dass das Objekt "ical.x.events.0" gelöscht wird, wenn die Instanz gestoppt und neu gestartet wurde.

Ich habe dazu ein Github-Issue eröffnet (inkl. Video, auf dem das Verhalten zu sehen ist) : https://github.com/ioBroker/ioBroker.ical/issues/85

Node : 8.12.0

npm : 6.4.1

js-controller : 1.4.2

Kann das jemand reproduzieren?

Gruß,

Eric

eric2905 created this issue in ioBroker/ioBroker.ical

closed v1.7.0 deleting Objects after instance restart #85

[RappiRN]

Ich habe das, allerdings bei nur einer Instanz, nicht.

Dafür hab ich grad gesehen, dass die Events bestehen bleiben.

D. h. ich habe vor zwei Tagen aktualisiert und da waren es noch 6 Tage bis zur nächsten Abholung. Heute sind es noch vier Tage. Unter 6 und 5 sind aber weiterhin die Datenpunkte auf true.

Hat das auch noch jemand? Ich hatte ja eben zum Testen die Instanz gestoppt und wieder gestartet, die Objekte haben weiterhin true angezeigt!

Enrico

[eric2905]

Habe jetzt nur eine Instanz laufen und der 0er-Eintrag (also heute) wird gelöscht, sobald ich die Instanz neu starte.

Von unterwegs getippert

[RappiRN]

Ich habe eben nochmal probiert, ich kann das nicht bestätigen. Eigentlich bist du ja der Profi und müsstest die Fragen stellen!

Jetzt frage ich mal (ohne wirklich Bescheid zu wissen! :lol: ), ich frage eine ics Datei im Internet ab hier mal meine Einstellungen:

Vielleicht hilf dir das ja weiter bei der Suche nach der Ursache.

Enrico

[eric2905]

Ich nutze einen Google-Kalender.

Ich werde es mal mit einem ICS-File testen.

Gruß,

Eric

Von unterwegs getippert

[RappiRN]

@RappiRN:

Dafür hab ich grad gesehen, dass die Events bestehen bleiben.

D. h. ich habe vor zwei Tagen aktualisiert und da waren es noch 6 Tage bis zur nächsten Abholung. Heute sind es noch vier Tage. Unter 6 und 5 sind aber weiterhin die Datenpunkte auf true.

Hat das auch noch jemand? Ich hatte ja eben zum Testen die Instanz gestoppt und wieder gestartet, die Objekte haben weiterhin true angezeigt! `

Ich muss mich nochmal selbst zitieren!

Das Problem besteht immer noch, nun sind schon fast alle Datenpunkte auf "true" und bleiben auch leider so! In den Einstellungen habe ich nichts gefunden, was dieses Verhalten beeinflussen könnte!

Enrico

[cash]

das Verhalten kann ich bei mir nicht nachvollziehen. Bei mir springen die States immer wieder korrekt auf false.

[RappiRN]

Na dann wären vielleicht die Versionen interessant:

Ich habe

node 8.14.0

Alles andere aktuell auf latest.

Aussehen tut es so:

Enrico

Edit: Hier noch die ics-Datei:

[apollon77]

bei Problemen mit der aktuellsten Version bitte GitHub Issue anlegen

[Jeeper.at]

Habe zu dem Datenpunkt (Anzahl der Tage bis zum Ereignis) einen Feature Request auf GitHub gestellt.

https://github.com/ioBroker/ioBroker.ic … -394125327

[wendy2702]

Hi,

hat hier noch jemand das Problem das bei Serien Terminen scheinbar immer der letzte Tag fehlt !?

Ich habe in meinem Nextcloud Kalender mal meinen Arbeitsbeginn für 2019 eingetragen. Dabei ist mir jetzt aufgefallen das in der VIS immer der Letzte Termin der Serie fehlt.

In Nextcloud sieht es so aus:

Wenn ich die ical Datei runterlade steht es so darin:

BEGIN:VEVENT
CREATED:20181224T101116Z
DTEND;TZID=Europe/Berlin:20190107T153000
DTSTAMP:20181224T101117Z
DTSTART;TZID=Europe/Berlin:20190107T070000
LAST-MODIFIED:20181224T101116Z
RRULE:FREQ=DAILY;UNTIL=20190111T060000Z
SEQUENCE:0
SUMMARY:Mirko @ Work
TRANSP:OPAQUE
UID:118E8891-C06B-4627-877A-32604B3F4136
END:VEVENT

Der Ical Adapter liest es so ein:

2018-12-27 13:13:37.392  - debug: ical.1 RRule event:Mirko @ Work; start:Mon Jan 07 2019 07:00:00 GMT+0100 (CET); endpreview:Sat Jan 12 2019 13:13:37 GMT+0100 (CET); today:Thu Dec 27 2018 00:00:00 GMT+0100 (CET); now2:Thu Dec 27 2018 00:00:00 GMT+0100 (CET); now3:Wed Dec 26 2018 15:30:00 GMT+0100 (CET); rule:{"_string":null,"_cache":{"all":false,"before":[],"after":[],"between":[]},"origOptions":{"dtstart":"2019-01-07T07:00:00.000Z","freq":3,"until":"2019-01-11T06:00:00.000Z"},"options":{"dtstart":"2019-01-07T07:00:00.000Z","freq":3,"until":"2019-01-11T06:00:00.000Z","interval":1,"wkst":0,"count":null,"tzid":null,"bysetpos":null,"bymonth":null,"bymonthday":[],"bynmonthday":[],"byyearday":null,"byweekno":null,"byweekday":null,"bynweekday":null,"byhour":[7],"byminute":[0],"bysecond":[0],"byeaster":null},"timeset":[{"hour":7,"minute":0,"second":0,"millisecond":0}]}
2018-12-27 13:13:37.392  - debug: ical.1 dates:["2019-01-07T07:00:00.000Z","2019-01-08T07:00:00.000Z","2019-01-09T07:00:00.000Z","2019-01-10T07:00:00.000Z"]
2018-12-27 13:13:37.393  - debug: ical.1 use offset -60 for Mon Jan 07 2019 08:00:00 GMT+0100 (CET)
2018-12-27 13:13:37.393  - debug: ical.1 use offset -60 for Mon Jan 07 2019 16:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.393  - debug: ical.1    0: Event (undefined):Mon Jan 07 2019 07:00:00 GMT+0100 (CET) Mon Jan 07 2019 15:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.394  - debug: ical.1     todayOnly = false: (Mon Jan 07 2019 07:00:00 GMT+0100 (CET)-Mon Jan 07 2019 15:30:00 GMT+0100 (CET)), alreadyStarted=false
2018-12-27 13:13:37.394  - debug: ical.1 Event with time added: " rrule " Mirko @ Work at 07.01.2019 07:00-15:30
2018-12-27 13:13:37.394  - debug: ical.1 use offset -60 for Tue Jan 08 2019 08:00:00 GMT+0100 (CET)
2018-12-27 13:13:37.394  - debug: ical.1 use offset -60 for Tue Jan 08 2019 16:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.395  - debug: ical.1    1: Event (undefined):Tue Jan 08 2019 07:00:00 GMT+0100 (CET) Tue Jan 08 2019 15:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.395  - debug: ical.1     todayOnly = false: (Tue Jan 08 2019 07:00:00 GMT+0100 (CET)-Tue Jan 08 2019 15:30:00 GMT+0100 (CET)), alreadyStarted=false
2018-12-27 13:13:37.395  - debug: ical.1 Event with time added: " rrule " Mirko @ Work at 08.01.2019 07:00-15:30
2018-12-27 13:13:37.395  - debug: ical.1 use offset -60 for Wed Jan 09 2019 08:00:00 GMT+0100 (CET)
2018-12-27 13:13:37.395  - debug: ical.1 use offset -60 for Wed Jan 09 2019 16:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.396  - debug: ical.1    2: Event (undefined):Wed Jan 09 2019 07:00:00 GMT+0100 (CET) Wed Jan 09 2019 15:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.396  - debug: ical.1     todayOnly = false: (Wed Jan 09 2019 07:00:00 GMT+0100 (CET)-Wed Jan 09 2019 15:30:00 GMT+0100 (CET)), alreadyStarted=false
2018-12-27 13:13:37.396  - debug: ical.1 Event with time added: " rrule " Mirko @ Work at 09.01.2019 07:00-15:30
2018-12-27 13:13:37.396  - debug: ical.1 use offset -60 for Thu Jan 10 2019 08:00:00 GMT+0100 (CET)
2018-12-27 13:13:37.396  - debug: ical.1 use offset -60 for Thu Jan 10 2019 16:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.396  - debug: ical.1    3: Event (undefined):Thu Jan 10 2019 07:00:00 GMT+0100 (CET) Thu Jan 10 2019 15:30:00 GMT+0100 (CET)
2018-12-27 13:13:37.396  - debug: ical.1     todayOnly = false: (Thu Jan 10 2019 07:00:00 GMT+0100 (CET)-Thu Jan 10 2019 15:30:00 GMT+0100 (CET)), alreadyStarted=false

So sieht es dann in VIS aus:

Ist das ein Bug?

Danke und Gruß

[twonky]

Auf den ersten Blick würde ich sagen:

Start-Datum: 2019-01-07 07:00

End-Datum: 2019-01-07 15:30

Wiederholen bis: 2019-01-11 06:00

Da der 2019-01-07 07:00 nach "Wiederholen bis" liegt, wird es nicht angezeigt. Oder "Wiederholen bis" muss als UTC interpretiert werden.

Wenn ich aber

DTSTART;TZID=Europe/Berlin:20190107T070000

RRULE:FREQ=DAILY;UNTIL=20190111T060000Z

auf https://jakubroztocil.github.io/rrule/ einstelle kommt 2019-01-07 bis 2019-01-10 raus.

[wendy2702]

Also liegt der Fehler nicht im iCal Adapter sondern im Nextcloud Kalender?

Gesendet von iPhone mit Tapatalk Pro

[twonky]

Das Z am Ende vom "Wiederholen Bis"/UNTIL deutet auf UTC hin. Legst du ein github issue am, ich guck's mir an sobald ich Zeit habe. Danke

[wendy2702]

Ok.

Sobald ich am Rechner sitze.

EDIT: ISSUE —> https://github.com/ioBroker/ioBroker.ical/issues/90

Gesendet von iPhone mit Tapatalk Pro

wendy2702 created this issue in ioBroker/ioBroker.ical

closed Problem mit Serien Termin und UTC #90

[wendy2702]

Problem scheint bei mir mit Version 1.7.1 von Github gelöst zu sein.

Danke für den schnellen Fix!