57_Calendar.pm: alpha-Test der neuen Version

[Dr. Boris Neubert]

Und es werden Dir auch unter >>> Events: die Events angezeigt? Und es liegen welche im Intervall [heute-1d, heute+30d]?

Übrigens: es heißt nun get CalBB full alarm (statt modeAlarm).

Siehe bitte Doku und What's new? im ersten Post.

[JoWiemann]

Hmm, habe das nie benutzt und auch nicht getestet - Code war eine Spende eines Dritten.

Das Package heisst

Code Auswählen Erweitern

libio-compress-perl auf neueren Systemen.

Mit libio-compress-perl funktioniert es bei mir nicht, aber mit dem CPAN-Modul läuft es.

Grüße Jörg

[JoWiemann]

Hallo Boris,

mit vevent bekomme ich folgende Infos:

Code Auswählen Erweitern


1: VEVENT [known]
    CREATED: 20160102T200805Z
    DESCRIPTION:
    DTEND: 20160103T200000Z
    DTSTAMP: 20160102T213149Z
    DTSTART: 20160103T190000Z
    LAST-MODIFIED: 20160102T200805Z
    LOCATION:
    SEQUENCE: 0
    SUMMARY: Testeintrag
    UID: ovorq4p1igeja1obd2dnfhda1g@google.com
    >>> Events:
      ovorq4p1igeja1obd2dnfhda1ggooglecom    upcoming                     03.01.2016 20:00:00-03.01.2016 21:00:00 Testeintrag
    >>> Skipped events:


als List sehe ich folgendes:

Code Auswählen Erweitern


   NAME       MeinKalender
   NR         384
   NTFY_ORDER 50-MeinKalender
   STATE      updated
   TYPE       Calendar
   Readings:
     2016-01-02 22:35:57   calname         jowiemann@debitel.net
     2016-01-02 22:35:57   lastUpdate      2016-01-02 22:35:51
     2016-01-02 20:17:55   modeAlarm
     2016-01-02 20:17:55   modeAlarmOrStart
     2016-01-02 20:17:55   modeAlarmed
     2016-01-02 20:17:55   modeChanged
     2016-01-02 21:07:07   modeEnd         6525gcvtf11q2p3cedj78db3ctr6juau01googlecom;6525gcvtf11q2p3cedj78db3ctr6juau02googlecom
     2016-01-02 20:17:55   modeEnded
     2016-01-02 20:17:55   modeStart
     2016-01-02 20:17:55   modeStarted
     2016-01-02 21:08:20   modeUpcoming    ovorq4p1igeja1obd2dnfhda1ggooglecom
     2016-01-02 22:35:57   nextUpdate      2016-01-02 23:35:51
     2016-01-02 22:35:57   nextWakeup      2016-01-02 23:35:51
     2016-01-02 22:35:57   state           updated
   Fhem:
     iCalendar  BEGIN:VCALENDAR


Müsste nicht irgendwie ModeStart gefüllt werden?

Grüße Jörg

[Dr. Boris Neubert]

Nein, der 03.01. ist erst morgen 

[Benni]

Guten Morgen Boris,

ich habe inzwischen einen Testkalender eingerichtet, mit dem es korrekt funktioniert.
Damit erhalte ich auch die >>>Events unter vevents angezeigt und auch mit get bekomme ich die korrekten Werte
Es war tatsächlich so, dass in meinem bisher verbundenen Kalender keine Ereignisse im Intervall [heute-1d, heute+30d] lagen 
Nach Erweiterung des Intervalls mittels hideLaterThan zeigt mir auch der ursprüngliche Kalender die korrekten Daten an.

Sieht also erst mal gut aus.
Werde weiter testen.

Gruß Benni.

[chris1284]

hi boris,

soweit lässt es sich einbinden und läuft auch stabil
schade das get full <id> nicht mehr geht....
so konnte man sich einzelne id's auslesen, was ich mir auch für das neue modul wieder wünschen würde (CALVIEW nutzt diese funktion ,sowie die meisten code-schnipsel für die myUtils zum auswerten des calendar ).

Code Auswählen Erweitern

get full all funktioniert

Code Auswählen Erweitern

get full modeUpcoming / modeEnd / andere modes geht noch nicht (es pasiert nichts)

[betateilchen]

schade das get full <id> nicht mehr geht....
so konnte man sich einzelne id's auslesen, was ich mir auch für das neue modul wieder wünschen würde (CALVIEW nutzt diese funktion ,sowie die meisten code-schnipsel für die myUtils zum auswerten des calendar ).

soweit ich anfangs gelesen habe, soll das "get" ohnehin umgebaut/erweitert werden. Warten wir mal ab, was da noch kommt. In einer alpha-Phase ist ein Modul meistens in seinem Funktionsumfang noch nicht vollständig im Funktionsumfang.

Hinweis: ab dem zweiten Google-Calendar werden die Alarme nicht übertragen, d.h. sie kommen schon gar nicht beim Download des iCalenders an.

@Boris: was heißt das konkret? Das Modul selbst kann aber schon mit mehreren Kalendern umgehen, oder? Ich werde im Laufe der nächsten Tage in den Test mit einsteigen.

[Benni]

Hallo Chris,

schade das get full <id> nicht mehr geht....

doch, geht schon, aber die Events müssen aber innerhalb des definierten Intervalls sein (Default [heute-1d, heute+30d])

-> siehe ein paar Posts weiter oben

[Dr. Boris Neubert]

Hallo Udo,

@Boris: was heißt das konkret? Das Modul selbst kann aber schon mit mehreren Kalendern umgehen, oder? Ich werde im Laufe der nächsten Tage in den Test mit einsteigen.

für meine Tests habe ich zusätzlich zu meinem ersten privaten Produktivkalender einen zweiten Kalender bei Google angelegt. Während die ics-Datei, die ich vom meinem privaten Kalender herunterlade, die VALARMS am VEVENT enthält, finde ich bei dem Testkalender keine VALARMS in der ics-Datei, obwohl die Termine mit Benachrichtigungen versehen sind.

Das Modul kann mit beliebig vielen Kalendern umgehen und behandelt alle gleich.

Viele Grüße
Boris

[chris1284]

Hallo Chris,

doch, geht schon, aber die Events müssen aber innerhalb des definierten Intervalls sein (Default [heute-1d, heute+30d])

-> siehe ein paar Posts weiter oben

das sind sie. alle in kw1 und 2, also max heute+14d

Übrigens: es heißt nun get CalBB full alarm (statt modeAlarm).

das die get's nicht zu den readings passen finde ich nicht optimal (reading modeXXX -> get XXX), sollte einheitlich sein

[Dr. Boris Neubert]

Hallo Chris, hallo Benni,

doch, geht schon, aber die Events müssen aber innerhalb des definierten Intervalls sein (Default [heute-1d, heute+30d])

-> siehe ein paar Posts weiter oben

die Beschränkung der sichtbaren Termine per Default scheint ein überraschendes Feature zu sein. Was denkt Ihr, wie das geändert werden könnte, damit niemand in diese Falle tappt?

Es ist aber schon klar, dass grundsätzlich Termine nur zwischen [t-400d, t+400d] erzeugt werden? Dabei ist t der letzte Zeitpunkt, an dem ein Termin als new, modified oder changed erkannt wurde. Das soll verhindern, dass Speicher- und Laufzeitgrenzen überschritten werden - besonders bei Terminserien ohne Ende  und gleichzeitig möglichst alle Termin in den vergangenen und nächsten 12 Monaten erfasst werden.

Viele Grüße
Boris

[Benni]

schade das get full <id> nicht mehr geht....

Also bei mir funktioniert das

Code Auswählen Erweitern


get calFHEM full eve7rtanico82903lmrctsfof8googlecom
eve7rtanico82903lmrctsfof8googlecom       end                     03.01.2016 08:35:00-03.01.2016 08:45:00 dmFHEM switch dmFHEM

[chris1284]

mittlerweile geht das bei mir auch, ich hatte vorhind id's mit 2016...._davor , warum auch immer.

[Benni]

die Beschränkung der sichtbaren Termine per Default scheint ein überraschendes Feature zu sein. Was denkt Ihr, wie das geändert werden könnte, damit niemand in diese Falle tappt?

Ich weiß ja nicht, wie das modulintern mit der Sichtbarkeit und den tatsächlich verfügbaren events (t-400 bis t+400) verwaltet wird. Aber ich finde, dass zumindest ein explizites get mit uid eines termins aus dem tatsächlich verfügbaren Event-Bereich auch ein Ergebnis liefern sollte, zumal die uids in den Readings ja auch angezeigt werden (so war es zumindest bei meinen Tests von gestern Abend).

Eventuell reicht es ja den default für den sichtbaren Bereich zu erhöhen, evtl. sogar auf max.
Ich schätze mal, dass die Menge der Kalender, bei denen das speicherkritisch sein könnte geringer ist, als die Anzahl derer, die in die Sichtbarkeitsfalle stolpern

Gruß Benni.

[Dr. Boris Neubert]

das die get's nicht zu den readings passen finde ich nicht optimal (reading modeXXX -> get XXX), sollte einheitlich sein

Die gets scheinen auch eine Falle zu sein. Ich hoffe, dass es nicht zu schmerzhaft wird, wenn ich

Code Auswählen Erweitern

get <name> full|text|summary|location|alarm|start|end <reading>|<uid> [max]

abschaffe. Durch den Fehler beim Aufruf wird der Anwender auf die Doku gestoßen.

Ich würde gerne folgendes einführen:

Code Auswählen Erweitern

get <name> events [format:<formatspec>] [filter:<filterspec>] [limit:<limitspec>]

mit

Code Auswählen Erweitern


<formatspec>:= full|text|summary|location|alarm|start|end|{ <perlcode> }
<filterspec> := uid =<uid> | mode=<mode> | { <perlcode> }
<limitspec> := max=<max> | window=timespec1,timespec2


Beispiele:

Code Auswählen Erweitern


get MyCalendar events format:full filter:uid=543567e3d2
get MyCalendar events format:{ strftime("%Y-%m-%d", $tstart) . " " . $summary } limit:windows=1d,30d
get MyCalendar events format:text limit:max=3