57_Calendar.pm: alpha-Test der neuen Version

[hexenmeister]

Warum ist Dein perl pingeliger als meins?

Code Auswählen Erweitern

This is perl 5, version 20, subversion 2 (v5.20.2) built for x86_64-linux-gnu-thread-multi
(with 51 registered patches, see perl -V for more detail)

auf KUbuntu 15.10.

Eine sehr gute Frage...

Code Auswählen Erweitern


This is perl 5, version 14, subversion 2 (v5.14.2) built for arm-linux-gnueabihf-thread-multi-64int
(with 89 registered patches, see perl -V for more detail)

auf CubieTruck mit Igors-Image

Code Auswählen Erweitern

Linux cubie 3.4.109-sunxi #4 SMP PREEMPT Wed Sep 30 13:44:47 CEST 2015 armv7l GNU/Linux


Die neue Version teste ich gleich.

Edit: Keine Warnings

[betateilchen]

Nochmal zum Thema modeEnded:

Ereignis 1: modeEnded vorhanden:

Code Auswählen Erweitern


2016-01-03_22:25:00 oc_Schalter changed: 636696728b end
2016-01-03_22:25:00 oc_Schalter end: 636696728b
2016-01-03_22:25:00 oc_Schalter modeUpcoming: 1bf61f34c8;c129db1744;418f7ec6ba;8c3b3c14e0;11d7c438a1;dcac449f42;0443ffc708
2016-01-03_22:25:00 oc_Schalter modeAlarmOrStart: c9a1ea64e6
2016-01-03_22:25:00 oc_Schalter modeStart: c9a1ea64e6
2016-01-03_22:25:00 oc_Schalter modeStarted:
2016-01-03_22:25:00 oc_Schalter modeEnd: 636696728b;db533f4977;698ffc0dd1;a41abb4589;AAFEBBFF8F4341788099671939BCDABF;a9c6be8b5a;9B2DD77E13DD462CACBA83ED30672B1E;c531b570e9;60e81c691d;85c66f6494;0FE7395834524DC884C8903978F77996;7020276aa4;C0579E685DB44A0D9349DF524611BD8D;FDFC8E01969A4BBFBF1BF81D67F699BC;C5F7FE902B894CF9AEB828DECBB80C34;a8f59d8d90;F5E71E148E0B48D68F1482C041D7DF2C;9FB130A0ACCB43CA931D00881D911475;FF7F7CEA049A4639BFD5759EDA4ABCEF;c85d45a0ef;91573703a9;297D5D2A7BD44354A216812108A7C368;e31a5b34fd;FBC398E8869544C68A647868D3692C1E;1CEE724FD55D4D20B2253CFE8968A003
2016-01-03_22:25:00 oc_Schalter modeEnded: 636696728b
2016-01-03_22:25:00 oc_Schalter nextWakeup: 2016-01-03 23:18:24


Ereignis 2: modeEnded fehlt:

Code Auswählen Erweitern


2016-01-04_05:00:00 oc_Schalter changed: c9a1ea64e6 end
2016-01-04_05:00:00 oc_Schalter end: c9a1ea64e6
2016-01-04_05:00:00 oc_Schalter modeUpcoming: 1bf61f34c8;c129db1744;11d7c438a1;8c3b3c14e0;418f7ec6ba;0443ffc708;dcac449f42;c9a1ea64e6
2016-01-04_05:00:00 oc_Schalter modeAlarmOrStart:
2016-01-04_05:00:00 oc_Schalter modeChanged: c9a1ea64e6
2016-01-04_05:00:00 oc_Schalter modeStart:
2016-01-04_05:00:00 oc_Schalter modeEnd: a41abb4589;698ffc0dd1;AAFEBBFF8F4341788099671939BCDABF;a9c6be8b5a;9B2DD77E13DD462CACBA83ED30672B1E;636696728b;db533f4977;C0579E685DB44A0D9349DF524611BD8D;FDFC8E01969A4BBFBF1BF81D67F699BC;C5F7FE902B894CF9AEB828DECBB80C34;c531b570e9;60e81c691d;85c66f6494;0FE7395834524DC884C8903978F77996;7020276aa4;c85d45a0ef;91573703a9;a8f59d8d90;F5E71E148E0B48D68F1482C041D7DF2C;9FB130A0ACCB43CA931D00881D911475;FF7F7CEA049A4639BFD5759EDA4ABCEF;FBC398E8869544C68A647868D3692C1E;1CEE724FD55D4D20B2253CFE8968A003;e31a5b34fd;297D5D2A7BD44354A216812108A7C368
2016-01-04_05:00:00 oc_Schalter nextWakeup: 2016-01-04 05:18:24


Unterschied zwischen Kalenderereignis 1 + 2:

• Ereignis 1 wurde gestern angelegt und ist ein einmaliges Ereignis.
• Ereignis 2 ist ein Serienelement, das schon sehr lange im Kalender vorhanden ist.

Als workaround auf dem Testsystem habe ich die notify nun umgestellt, dass auf "end" anstatt "modeEnded" getriggert wird.

Im Logfile heute morgen um 05:00:00 Uhr sieht es übrigens verheerend aus:

Code Auswählen Erweitern


2016.01.04 05:00:00 3: get oc_Schalter summary c9a1ea64e6  : sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
2016.01.04 05:00:00 3: set sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts off : Please define sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts
sz_Bett_rechts first


[betateilchen]

Mir ist noch ein eigenartiges Verhalten aufgefallen:

Gestern abend habe ich zu Testzwecken einen einmaligen Termin von 22:20 bis 22:25 Uhr angelegt, danach ein set ... reload gemacht.

Dann habe ich per get ... vevents festgestellt, dass ich versehentlich den Termin auf den 04.01. anstatt den 03.01. geplant hatte. Das Datum habe ich dann im Termin korrigiert.

Ein neues set ... reload in fhem hat aber nicht dazu geführt, dass im Calendar-device der Termin vom 04. auf den 03. gewandert wäre. fhem behauptet per get ... vevents stur, dass der Termin am 04.01. ansteht.

Erst ein Löschen des Termins mit anschließender Neuanlage mit korrektem Datum löste das Problem.

[Dr. Boris Neubert]

Hallo Udo,

Danke für Deine Tests. Habe die Ergebnisse registriert und werde sie am Wochenende abarbeiten.

Zu der Änderung von Terminen. Das hatte ich bei mir exzessiv getestet. Falls Du das nachstellen kannst, wäre mir geholfen, den entsprechenden Auszug von get ... vevents zu sehen.

Ein geändertes VEVENT gibt es nach dem ersten get ... reload zweimal, einmal als modified-new (oder changed-new) und einmal als modified-old (oder changed-old), wobei die beiden VEVENTS wechselseitig auf die interne ID (kleine Ganzzahl) ihres Gegenstücks verweisen. Ist das VEVENT einfach nur known, hat das Modul die Änderung nicht mitbekommen. Auch in diesem Fall wäre es interessant, es zu sehen, wobei ich dann auch noch die genaue Zeit der Änderung im Google-Kalender wissen müsste, um zu sehen, wie das im VEVENT reflektiert ist.

Viele Grüße
Boris

[betateilchen]

Edit: wir reden nicht von einem Google-Kalender, sondern von einem Kalender in ownCloud, in dem Einträge per Apple OSX Kalender verwaltet werden.

Termin angelegt:

Code Auswählen Erweitern


38: VEVENT [new]
    CREATED: 20160104T212702Z
    DTEND: 20160105T231500
    DTSTAMP: 20160104T212800Z
    DTSTART: 20160105T230000
    SEQUENCE: 0
    SUMMARY: testEintrag
    UID: 54B48541-01B0-4114-8B18-1CEE487BC6E7
    X-APPLE-TRAVEL-ADVISORY-BEHAVIOR: AUTOMATIC
    >>> Events:
      54B4854101B041148B181CEE487BC6E7    upcoming                     05.01.2016 23:00:00-05.01.2016 23:15:00 testEintrag
    >>> Skipped events:


Termin geändert von 05.01. auf 04.01., danach ein get ... reload

Code Auswählen Erweitern


38: VEVENT [known]
    CREATED: 20160104T212702Z
    DTEND: 20160105T231500
    DTSTAMP: 20160104T212800Z
    DTSTART: 20160105T230000
    SEQUENCE: 0
    SUMMARY: testEintrag
    UID: 54B48541-01B0-4114-8B18-1CEE487BC6E7
    X-APPLE-TRAVEL-ADVISORY-BEHAVIOR: AUTOMATIC
    >>> Events:
      54B4854101B041148B181CEE487BC6E7    upcoming                     05.01.2016 23:00:00-05.01.2016 23:15:00 testEintrag
    >>> Skipped events:


Es gibt keine zwei vevents, soweit ich das sehe.

[betateilchen]

Nachtrag:

Das Löschen des Kalendereintrags wird erkannt:

Code Auswählen Erweitern


38: VEVENT [obsolete, deleted]
    CREATED: 20160104T212702Z
    DTEND: 20160105T231500
    DTSTAMP: 20160104T212800Z
    DTSTART: 20160105T230000
    SEQUENCE: 0
    SUMMARY: testEintrag
    UID: 54B48541-01B0-4114-8B18-1CEE487BC6E7
    X-APPLE-TRAVEL-ADVISORY-BEHAVIOR: AUTOMATIC
    >>> Events:
    >>> Skipped events:


[Dr. Boris Neubert]

Edit: wir reden nicht von einem Google-Kalender, sondern von einem Kalender in ownCloud, in dem Einträge per Apple OSX Kalender verwaltet werden.

Ahaaa, möglicherweise verhält sich das nicht RFC-konform. Kannst Du mir bitte mal das VEVENT aus dem icalendar schicken, vor und nach Änderung?  get ... vcalendar

Will sehen, woran man die Änderung überhaupt erkennen kann.

[betateilchen]

Angelegt:

Code Auswählen Erweitern


BEGIN:VEVENT

CREATED:20160104T230906Z

UID:E59607CA-154A-4B8A-8D5D-6DF446F65AB5

DTEND;TZID=Europe/Berlin:20160106T071500

TRANSP:OPAQUE

X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC

SUMMARY:Neues Ereignis

DTSTART;TZID=Europe/Berlin:20160106T061500

DTSTAMP:20160104T230910Z

SEQUENCE:0

END:VEVENT




Geändert:

Code Auswählen Erweitern



BEGIN:VEVENT

CREATED:20160104T230906Z

UID:E59607CA-154A-4B8A-8D5D-6DF446F65AB5

DTEND;TZID=Europe/Berlin:20160105T071500

TRANSP:OPAQUE

X-APPLE-TRAVEL-ADVISORY-BEHAVIOR:AUTOMATIC

SUMMARY:Neues Ereignis

DTSTART;TZID=Europe/Berlin:20160105T061500

DTSTAMP:20160104T231009Z

SEQUENCE:0

END:VEVENT


Will sehen, woran man die Änderung überhaupt erkennen kann.

an DTEND, DTSTART und DTSTAMP würde ich vermuten

[betateilchen]

Hallo Boris,

hatte die alte Modulversion eigentlich ein (bekanntes?) Problem mit Terminen über den Jahreswechsel?

http://forum.fhem.de/index.php/topic,46853.0.html

Falls ja, sollte man mal prüfen, wie sich die neue Modulversion dabei verhält.

[Dr. Boris Neubert]

hatte die alte Modulversion eigentlich ein (bekanntes?) Problem mit Terminen über den Jahreswechsel?

http://forum.fhem.de/index.php/topic,46853.0.html

Nein, und siehe dort.

Viele Grüße
Boris

[VB90]

kurze Rückmeldung meinerseits...

bei mir läuft alles wie es soll. zumindest soweit ich das beurteilen vermag.
Ich habe lediglich Anzeigefehler in der Readingsgroup vom CALVIEW.
Dort werden die Serientermine sehr häufig angezeigt. siehe Screenshot.

Ich sehe die Probleme aber eher beim CALVIEW Modul, das aufgrund der hiesigen Neuentwicklung eben nicht 100% kompatibel zu sein scheint. Setze ich im CALENDAR Device ein "get Device full all" wird alles korrekt angezeigt.

vb

[betateilchen]

Ich habe lediglich Anzeigefehler in der Readingsgroup vom CALVIEW.
...
Ich sehe die Probleme aber eher beim CALVIEW Modul

nein, das kommt aus dem neuen Kalendermodul. Ich habe ähnliche Probleme (siehe weiter oben hier im Thread)

Bei mir hat die Begrenzung auf 1 bei "get ... summary $uid 1" den Effekt behoben. Wobei ein einzelner event ja von Haus aus nur eine summary hat und nicht die ganze Liste aus der eigenen Serie

[Dr. Boris Neubert]

Hallo,

habe zwei Änderungen durchgeführt (siehe bitte Eröffnungsbeitrag).

Ich bestätige ferner, dass bei einem Serientermin modeEnded nicht kommt - der Grund ist, dass der Termin wieder in den Modus Upcoming geht. In modeEnded sind die Ereignisse, die gerade nach modeEnd gekommen sind.

Womit ich mich noch befassen werde ist die Frage, ob ein beendeter Termin nicht noch durch modeEnd und modeEnded gezogen werden sollte und ob das überhaupt realisierbar ist.

Das ist alles schon sehr subtil...

Die empfohlene Vorgehensweise ist sowieso auf das Event end: <uid> zu reagieren. Das muss ich noch dokumentieren.

Interaktion mit CALVIEW sehe ich mir auch noch näher an.

Grüße
Boris

[betateilchen]

Bevor Du jetzt noch mehr solche Krücken vorschlägst, solltest Du besser auf die angedachte Abwärtskompatibilität komplett verzichten und lieber ein logisch und leicht verständliches, stabiles Modul bauen.

Mir wäre das jedenfalls als Anwender viel lieber.

[Dr. Boris Neubert]

Hallo,

so, das Ende des alpha-Tests naht.

An den FHEM-Events für die mode...-Readings habe ich nicht gedreht.

Ich habe einen neuen Filter namens "new" eingebaut. Er funktioniert praktisch so wie "all" in der Vorversion, indem aus jeder Menge von Terminen mit derselben UID der erste nicht abgelaufene Termin angezeigt wird. Dafür ist jetzt das Attribut hideOlderThan per Default nicht mehr gesetzt. Migrationshinweise in What's new? im ersten Beitrag.

Die von Udo gemeldeten Auffälligkeiten sollten entweder beseitigt oder erklärt sein.

Weiterhin gibt es jetzt das Plug-In onCreateEvent. Damit kann man sich z.B. einen Alarm an die Termine zur Abholung der Mülltonne zaubern. Das tut hoffentlich die ganzen Frickeleien mit den Müllkalendern vereinfachen.

Wenn nichts gravierendes mehr an Meldungen kommt, geht das Teil morgen in den beta-Test für alle.

Viele Grüße
Boris