57_Calendar.pm: alpha-Test der neuen Version

[Dr. Boris Neubert]

An Chris wegen CALVIEW.

Ich habe CALVIEW gar nicht richtig zum Laufen gebracht. Konnte mir daher auch nicht ansehen, was man gegen die von VB90 geschilderte Beobachtung tun kann.

Ich habe folgendes erstellt (T ist mein Testkalender):

Code Auswählen Erweitern

define CV CALVIEW T 2
define kalenderTermine readingsGroup <%time_calendar>,<Text>,<Zuletzt erfasst> CV
attr kalenderTermine alias Termine
attr kalenderTermine group _KalenderView_
attr kalenderTermine mapping %READING

CV zeigt jedoch nur

Code Auswählen Erweitern

Internals:
   DEF        T 2
   INTERVAL   43200
   KALENDER   T
   NAME       CV
   NR         23
   STATE      t: 0 td: 0 tm: 0 ts: 0
   TYPE       CALVIEW
   Readings:
     2016-01-09 15:41:45   c-started       0
     2016-01-09 15:41:45   c-term          0
     2016-01-09 15:41:45   c-today         0
     2016-01-09 15:41:45   c-tomorrow      0
     2016-01-09 15:41:45   state           t: 0 td: 0 tm: 0 ts: 0
Attributes:
   modes      all


Kannst Du mir bitte ein funktionierendes Beispiel geben?

Viele Grüße
Boris

[Benni]

Hallo Boris,

ich habe gerade die neueste Version vom ersten Post in mein Testsystem geladen.

Beim Versuch einen neuen  Calendar per define im webif anzulegen ist mir direkt FHEM abgeschmiert.

Log-Auszug:

2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/57_Calendar.pm line 1710.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value in subtraction (-) at ./FHEM/57_Calendar.pm line 1715.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value in addition (+) at ./FHEM/57_Calendar.pm line 1854.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value $name in concatenation (.) or string at ./FHEM/57_Calendar.pm line 1861.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/57_Calendar.pm line 1868.
2016.01.10 13:35:51 1: PERL WARNING: Use of uninitialized value $type in string eq at ./FHEM/57_Calendar.pm line 1883.
Software Error at ./FHEM/57_Calendar.pm line 1907.

define des Calendar:

Code Auswählen Erweitern


define calTest Calendar ical url https://calendar.google.com/calendar/ical/8bugtd3u7c7rhf4fgaodac7ufo%40group.calendar.google.com/public/basic.ics


Das ganze passiert auch, wenn ich einen bereits bestehenden Calendar mit o.a. url modifiziere.
Beim Starten von FHEM werden aber bereits zuvor definierte Calendar ohne Probleme wieder angelegt.

Wenn ich nun auch den Kalender mit o.a. url direkt in der fhem.cfg definiere und dann FHEM starte, wird auch das neue Calendar-Device problemlos angelegt und funktioniert (s.Screenshot).

Auszug aus fhem.cfg:

Code Auswählen Erweitern


define calTest Calendar ical url https://calendar.google.com/calendar/ical/8bugtd3u7c7rhf4fgaodac7ufo%40group.calendar.google.com/public/basic.ics
attr calTest alias Test-Kalender
attr calTest hideLaterThan 1
attr calTest hideOlderThan 0
attr calTest room caltest


Gruß Benni.

[Dr. Boris Neubert]

Hallo Benni,

Danke fürs Testen und die aussagekräftigen Meldungen. Konnte das Problem damit sofort nachstellen und beseitigen.

Neue Version im Eingangsbeitrag.

Viele Grüße
Boris

[betateilchen]

Wenn ich mich auf modeEnded, modeStarted usw ohnehin nicht mehr verlassen kann, hätte ich gerne ein Attribut, mit dem ich die Generierung dieser mode.* readings samt ihrer events komplett abschalten kann. Mir reicht end: und start:

[Dr. Boris Neubert]

Kannst Du Gedanken lesen, Udo?

Ich will nämlich ein Attribut einbauen, mit dem man diese Readings anschalten kann. Es würde dann per Default gesetzt sein, bis irgendwann der Default wechselt.

--> sobald der beta-Test durch ist, werden solche Neuerungen geliefert. Insbesondere aber erstmal die flexible Ausgabe, die ich hier beschrieben habe: http://forum.fhem.de/index.php/topic,46608.msg383729.html#msg383729

(Natürlich kann man sich auf mode... verlassen - man muss nur wissen, was es leistet und was nicht.)

[betateilchen]

Die mode.* leisten in meinen Tests einfach nicht mehr das, was bisher möglich war. Insofern sind sie für mich leider unzuverlässig geworden.

Hat zufällig jemand schon ganztägige, periodische Termine getestet? Bin noch nicht dazu gekommen, aber mit diesen Terminen hatte ich im alten Modul massive Probleme.

Ausserdem wäre es schön, wenn Du die jeweils aktuelle betaversion in ./contrib bereitstellen könntest, da macht das Testen auf entfernten Systemen, die man per ssh erreicht, viel einfacher, da man die Datei dann per avn bereits auf dem Zielsystem hat. Das ist viel einfacher, als sie erst aus dem Forum runterladen und dann aufs Zielsystem kopieren zu müssen.

Viele Grüsse aus dem IC im Mittelrheintal

[Benni]

Hallo Boris,

danke! Die neue Version führt nicht mehr zum Absturz, aber....

...hat sich zwischenzeitlich noch was bei der Sichtbarkeit der Termine geändert?
Sobald ich das Attribut hideLaterThan auf einen beliebigen Wert setze bekomme ich mit einem get leider gar nichts mehr zurück. Sobald ich das Attribut wieder lösche, bekomme ich wieder alles zurück.

Getestet mit meinem (öffentlich verfügbaren) Test-Kalendar von ein paar Posts weiter oben.

In wie weit ist denn bereits die angedeutete neue get-Syntax,

Code Auswählen Erweitern

get events ...
die mir übrigens sehr gut gefällt, implementiert?

limit scheint jedenfalls noch nicht zu funktionieren 
(bekomme derzeit immer alles zurück)

[Dr. Boris Neubert]

Hallo Benni,

Danke fürs Weitertesten.

Kann Deine Meldung nicht nachvollziehen. Habe Deinen Kalender definiert und dann

Code Auswählen Erweitern

attr calTest hideLaterThan 30d

gesetzt und es funktioniert. Bitte beachten, dass bei Angabe einer nackten Ganzzahl die Zeitangabe in Sekunden ist (siehe commandref für die erlaubten Formate).

Weitere Neuerungen kommen, wenn die neue Version durch den Betatest ist (siehe meine Antwort wenige Beiträge zurück an betateilchen).

Grüße
Boris

[betateilchen]

Die Funktionsweise der hideDingenskirchen ist mir ohnehin suspekt. Da habe ich noch NIE das Ergebnis bekommen, mit dem ich eigentlich gerechnet hätte.

[Benni]

Bitte beachten, dass bei Angabe einer nackten Ganzzahl die Zeitangabe in Sekunden ist (siehe commandref für die erlaubten Formate).

Ah! Das ist mir leider entgangen. 
Jetzt klappt's! Danke!

[Dr. Boris Neubert]

Hallo,

habe noch eine funktionale Erweiterung eingebaut:

Neue Filter mode=<regex> und uid=<regex> bei get <name> <format> <filter> [max]

Grüße
Boris

[Benni]

Hallo Boris,

ich habe bei mir doch noch eine Kleinigkeit festgestellt.

Ich habe ein Notify auf dem 'updated' Event es Kalenders gesetzt, in dem ich dann u.a. per get Termine anhand deren Status abfrage:

Code Auswählen Erweitern


get calTest summary upcoming
get calTest summary start


(die werde ich dann noch auf die neue filter-Funktionalität umstellen)

anscheinend ist aber zum Zeitpunkt, an dem das updated Event kommt, der Kalender noch nicht vollständig verarbeitet, denn ich bekomme mit den get keine Ergebnisse. Wenn ich allerdings nach einer Verzögerung (aktuell habe ich mal 30 Sekunden genommen) die get-Abfrage mache, erhalte ich die erwarteten Ergebnisse.

So wie's aussieht, verwende ich da wahrscheinlich noch "zukünftige" Funktionalität, zumindest konnte ich in der Doku nichts zum updated-Event finden, den habe ich mir aus dem Eventmonitor geholt.

2016-01-17 12:43:59 Calendar calTest update
2016-01-17 12:43:59 Calendar calTest retrieved
2016-01-17 12:43:59 Calendar calTest calname: Testkalender
2016-01-17 12:43:59 Calendar calTest lastUpdate: 2016-01-17 12:43:59
2016-01-17 12:43:59 Calendar calTest nextUpdate: 2016-01-17 16:43:59
2016-01-17 12:43:59 Calendar calTest updated
2016-01-17 12:43:59 Calendar calTest nextWakeup: 2016-01-17 16:43:59

Wie auch immer, mit der verzögerten Abfrage funktioniert es jetzt erst mal so, wie ich wollte, daher das nur als Hinweis.

Gruß Benni.

[Dr. Boris Neubert]

Hallo Benni,

ich habe bei mir doch noch eine Kleinigkeit festgestellt.

Danke für die Meldung. Ohne Deinen Use Case und die genaue Beschreibung wäre das sicher erst irgendeinem User aufgefallen und dann hätte ich mir Ewigkeiten das Hirn zermartert, was das Problem ist.

Es ist KEINE Kleinigkeit.

Das updated-Event kommt in der von Dir getesteten Version, nachdem die Termine (calendar events am VEVENT) erzeugt sind und bevor die Modi aktualisiert sind. Damit stehen die Modi alle auf "undefined" und Du erhältst keine Termine, die im Modus "upcoming" oder "start" stehen.

Wie lässt sich das beheben? Dazu vorab eine Erklärung. Die zwei zentralen Routinen sind Calendar_Update und Calendar_CheckTimes. Calendar_Update holt den Kalender von der Quelle und aktualisiert Termine, sofern diese an der Quelle geändert wurden. Calender_CheckTimes wird zu jedem Zeitpunkt aufgerufen, an dem ein Termin beginnt, endet, oder alarmiert wird, sowie nach einem Update. Erst dabei werden auch die Modi aller Termine aktualisiert.

Ereignis "update" feuern nach Calendar_Update führt dazu, dass in diesem Augenblick die Modi noch nicht korrekt sind. Ereignis "update" feuern nach Calendar_CheckTimes führt dazu, dass Dein Notify nach jeder Modusänderung jedes Termins gefeuert wird.

Die sauberste Lösung ist m.E. die folgende:
- Ereignis "triggered" wird gefeuert, immer nachdem CheckTimes die Modi aktualisiert hat.
- Ereignis "update" wird gefeuert, immer nachdem CheckTimes die Modi aktualisiert hat und zuvor der Kalender aktualisiert wurde (per update oder reload).

Das setze ich noch um, aber nicht mehr heute.

Viele Grüße
Boris

[Dr. Boris Neubert]

Hallo Benni,

habe die Änderung am Calendar-Modul durchgeführt. Nachdem der Kalender aktualisiert wurde und alle Zeiten gesetzt sind, wird das FHEM-Event triggered gefeuert. Auf das Event updated aus meinem vorigen Beitrag habe ich verzichtet. Mir leuchtet nicht ein, wozu man das braucht.

Viele Grüße
Boris

[Dr. Boris Neubert]

Hallo,

ich habe an einer zentralen Stelle im Modul noch herumgebastelt. Die Laufzeit für das Merging und Crossreferencing der Termine geht quadratisch mit der Anzahl der VEVENTs. Das habe ich durch Perl-Gymnastik mit Lookup-Hashes versucht zu beschleunigen. Meine Tests mit mehreren Kalendern haben danach immer noch die richtigen Ergebnisse erbracht. Es wäre aber gut, wenn jeder seinen Anwendungsfall noch mal testet.

Die Version im ersten Beitrag ist der Release-Kandidat. Wenn nichts mehr gefunden wird, geht das Modul nächstes Wochenende ins Update.

Grüße
Boris