Anregung fuer 57_Calendar zur Nutzung von ferienwiki.de

[Adimarantis]

Hallo 57_Calendar Maintainer,

Ich nutze ferienwiki.de um Ferientermine und Feiertage zu holen.
Zum einen haben dort 1-tägige Termine leider den Fehler keine Ende zu haben (das mag falsch sein, aber ich werde die Plattform kaum dazu bringen das zu korrigieren), zum anderen möchte ich nicht jedes Jahr die URL ändern müssen.

Daher habe ich bei mir folgende Änderungen im Modul implementiert (diff Ausgabe gegen aktuelle Version 2019-02-08):

Code Auswählen Erweitern

1346,1349d1345
<     } else {
<       #mod Joerg: if DTEND and DURATION is missing assume 1 day event
<         my $duration= 86400;
<         $event->{end}= $nextstart + $duration;
1720,1725c1716
<   #Change Joerg: Retrieve current year and enable %y replacement for URL
<   my($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst)=localtime();
<   $year=$year+1900;
<   $url=~s/\%y/$year/ig;


- Termine ohne korrektes Ende bekommen einfach die Länge eines Tages.
- In der URL wird %y gegen das aktuelle Jahr ersetzt

Es wird z.B. mit

Code Auswählen Erweitern

define Ferien Calendar ical url http://www.ferienwiki.de/exports/ferien/%y/de/bayern 86400
immer der Kalendar des aktuellen Jahres geholt.

Wäre schön wenn ihr diese Änderungen (zumindest funktional - bin jetzt nicht der Perl Experte) in die Release aufnehmen könntet, damit ich das nicht nach jedem Update wieder reinpatchen muss.

Gruß,
Jörg

[betateilchen]

Über die Ersetzung in der URL könnte man ja noch reden (auch wenn ich dazu keine zwingende Notwendigkeit sehe, denn es ist eher eine Frage, inwieweit man die Faulheit der Anwender unterstützen will)

Aber einen Kalendereintrag, der keinen korrekten Ende-Eintrag hat, einfach auf 1 Tag zu zwingen, halte ich für nicht sinnvoll. Denn das muss nicht immer richtig sein. Deshalb bin ich dagegen, diese Änderung modulseitig vorzunehmen.

[Otto123]

Alternative Lösung:
Einmal Jährlich den Ferienwiki Kalender in einen Google Kalender importieren (bekommt man sicher auch mit einem kleinen Programm hin?) und den Google Kalender einbinden.
1. Google Kalender heilt das Problem mit dem Termin ohne Ende
2. Ferienwiki wird nicht mit unnötigen Anfragen bombardiert.

Gruß Otto

[Dr. Boris Neubert]

- Termine ohne korrektes Ende bekommen einfach die Länge eines Tages.

Im RFC zu ICAL steht tatsächlich:

Page 53
For cases where a "VEVENT" calendar component
specifies a "DTSTART" property with a DATE value type but no
"DTEND" nor "DURATION" property, the event's duration is taken to
be one day. For cases where a "VEVENT" calendar component
specifies a "DTSTART" property with a DATE-TIME value type but no
"DTEND" property, the event ends on the same calendar date and
time of day specified by the "DTSTART" property.

Daher habe ich diese Erweiterung auch auf meiner Todo-Liste. Ich werde diese nicht vor Ende März zusammen mit den restlichen Einträgen in einem Rutsch abarbeiten.

Grüße
Boris

[betateilchen]

na, wenn es dort geschrieben steht ... 

Aber das hier

For cases where a "VEVENT" calendar component specifies a "DTSTART" property with a DATE-TIME value type  but no "DTEND" property,
the event ends on the same calendar date and time of day specified by the "DTSTART" property.

habe ich jetzt jetzt mindestens 5 Mal gelesen, aber ich glaube, noch nicht verstanden.

Heißt das im Endeffekt, dass es events ohne eine Dauer gibt?

Wenn ja - wie will das Modul dann start/stop triggern?

[Dr. Boris Neubert]

Hallo,

ich interpretiere das so:

Wenn weder DTEND noch DURATION angegeben sind:
Fall 1) DTSTART ist ein Datum (20190210) und kein Zeitpunkt (20190210T123432Z): Beginn um 00:00, Ende um 24:00 (Dauer 1 Tag)
Fall 2) DTSTART ist kein Datum (20190210) sondern ein Zeitpunkt (20190210T123432Z): Beginn UND Ende an diesem Zeitpunkt (Dauer 0 s)

Viele Grüße
Boris

[betateilchen]

ja, ich bin bei beiden Punkten bei Dir.

Aber was triggert dann FHEM, wenn die Dauer = 0 Sekunden ist?

Dann gibt es 4 Events alle exakt zur gleichen Zeit? Das kann FHEM doch gar nicht abbilden, weil zumindest "change" dann ein duplicate ist.

change - start - change - end

[betateilchen]

Für das Ersetzen von Platzhaltern durch Zeitangaben (gemäß POSIX::strftime) gibt es in FHEM bereits bewährte Mechanismen, das macht die Sache recht einfach.

Code Auswählen Erweitern


Internals:
   DEF        ical url https://irgendeineurl.de/%Y/test.ics
...
   .fhem:
...
     url        https://irgendeineurl.de/2019/test.ics
...


Code Auswählen Erweitern


Index: 57_Calendar.pm
===================================================================
--- 57_Calendar.pm      (revision 18547)
+++ 57_Calendar.pm      (working copy)
@@ -1709,7 +1709,8 @@

   my $name      = $a[0];
   my $type      = $a[3];
-  my $url       = $a[4];
+  my @t         = localtime;
+  my $url       = ResolveDateWildcards($a[4], @t);
   my $interval  = 3600;

   $interval= $a[5] if($#a==5);


[nils_]

Für das Ersetzen von Platzhaltern durch Zeitangaben (gemäß POSIX::strftime) gibt es in FHEM bereits bewährte Mechanismen, das macht die Sache recht einfach.

Code Auswählen Erweitern


Internals:
   DEF        ical url https://irgendeineurl.de/%Y/test.ics
...
   .fhem:
...
     url        https://irgendeineurl.de/2019/test.ics
...


Code Auswählen Erweitern


Index: 57_Calendar.pm
===================================================================
--- 57_Calendar.pm      (revision 18547)
+++ 57_Calendar.pm      (working copy)
@@ -1709,7 +1709,8 @@

   my $name      = $a[0];
   my $type      = $a[3];
-  my $url       = $a[4];
+  my @t         = localtime;
+  my $url       = ResolveDateWildcards($a[4], @t);
   my $interval  = 3600;

   $interval= $a[5] if($#a==5);


frage dazu (kannte den mechanismus noch nicht):
wann wird das jahr ersetzt???
vermutlich einmal beim anlegen des devices.... und dann im nächsten jahr??

[betateilchen]

wann wird das jahr ersetzt???
vermutlich einmal beim anlegen des devices.... und dann im nächsten jahr??

Bei jedem Neustart von FHEM wird das define ausgeführt und %Y durch das dann aktuelle Jahr ersetzt.

Aber Vorsicht: der vorgeschlagene patch ist noch nicht im Modul eingebaut!

[nils_]

Bei jedem Neustart von FHEM wird das define ausgeführt und %Y durch das dann aktuelle Jahr ersetzt.

also d.h. man müsste dann dafür sorgen, je nach genutzen wildcards (könnte ja auch ein %d sein), fhem neuzustarten ?! im beispiel reicht es ja jeden 1. januar.
(mir ist durchaus bewusst, das ein täglicher kalender keinen wirklichen sinn macht, aber wer weiß schon was manchen leutchen so einfällt )

Aber Vorsicht: der vorgeschlagene patch ist noch nicht im Modul eingebaut!

ja, ist mir bewusst

[Beta-User]

Ein defmod oder reload dürften auch reichen. Trotzdem ist der regelmäßige online-Zugriff völlig überflüssig.
Just my2ct.

[Otto123]

Hallo,

Auch wenn das bei dem Thema leicht OT ist, aber jetzt wird ja hier eh schon die eine oder andere Entwicklung besprochen:

Ich hätte noch die Anregung, die Auswirkung der Angabe [<interval>] so zu ändern, dass die 0 nicht ein ständiges automatisches neu laden, sondern kein automatisches neu laden mehr bewirkt.
Keine Angabe setzt ja (leider) den Standardwert 3600.

Gruß Otto

[betateilchen]

Code Auswählen Erweitern

attr <calendarName> update none

Steht übrigens in der Doku zum Calendar-Modul. Aber wer kommt schon auf die völlig abwegige Idee, einen Blick in die Doku zu werfen...

[Adimarantis]

Bei jedem Neustart von FHEM wird das define ausgeführt und %Y durch das dann aktuelle Jahr ersetzt.

Das würde jetzt an meinem use case vorbei gehen.
Ich würde den Calendar möglichst am 1. Januar um 0:00 neu einlesen, damit er erkennt, dass der 1. Januar ein Feiertag ist und somit z.B. die Rollos erst später hochfährt. Daher sollte so eine Ersetzung (wie in meinem Vorschlag) adhoc bei jedem Zugriff durchgeführt werden. Wann der nächste Neustart ist, steht in den Sternen und bis dahin fehlen ggf. die Infos.

Gruß,
Jörg

[Beta-User]

Nochmal zwei Varianten zu deinem "use-case" (der nicht besonders speziell ist und eigentlich auch schon an anderer Stelle mehrfach ausdiskutiert...):

Variante 1:
Was hindert dich daran, einen Kalender, der sich NIE ändert, lokal am 31.12. für das nächste Jahr - immer demselben Namen - runterzuladen und als file einzubinden? Dann kannst du ein kurzes update-Intervall angeben und hast immer den aktuellen Stand, auch wenn das INet mal kaputt ist...

Variante 2:
Importiere die Kalender halt in einen, dessen Name sich nicht ändert und greife die Daten dort ab.
(Ich mache das z.B. zusammen mit Müll usw. in einen, auf den auch meine Frau Zugriff hat. Da muß man dann halt in der Auswertelogik etwas mehr filtern... Hier werden z.B. dann aus dem allg. ical mehrere .holiday-Dateien extrahiert (alle Woche neu), die ich dann teilweise (für Ferien, Müll natürlich nicht) wieder in holiday2we (global) verwende. So sind auch bewegliche Ferientage kein Problem, die muß man nur passend eintragen ).

Aber alle Tage einen sich nicht ändernden Kalender abfragen ist einfach unnötig (ein früherer Anbieter der Kalender  hat irgendwann auf die vielen Zugriffe so reagiert, dass er das für automatische Zugriffe gesperrt hat, das muss sich eigentlich nicht nochmal wiederholen, nur weil u.a. die user hier sowas nicht berücksichtigen wollen...)

[betateilchen]

Wenn Du ohnehin nur einmal pro Jahr den Kalender updaten willst, ist es wahrlich nicht zuviel verlangt, im Rahmen dieser einmaligen Aktion pro Jahr das Jahr auch entsprechend selbst mit anzugeben.

[nils_]

Wenn Du ohnehin nur einmal pro Jahr den Kalender updaten willst, ist es wahrlich nicht zuviel verlangt, im Rahmen dieser einmaligen Aktion pro Jahr das Jahr auch entsprechend selbst mit anzugeben.

grundsätzlich gebe ich dir recht. ich mache das für meinen müllkalender genau so. am 1. januar runterladen, kopieren, einlesen, fertig.


aber für Adimarantis drehen wir uns nun im kreis, denn das Jahr ändern will er ja vermeiden....

... zum anderen möchte ich nicht jedes Jahr die URL ändern müssen.

[Adimarantis]

Ist ja nicht so, als wäre die Lösung super kompliziert. Hab das bei mir lokal ja schon implementiert.

FHEM is home automation - und auch wenn hier nur etwas automatisiert wird, was einmal im Jahr passiert, verstehe ich nicht, warum mehr Zeit in die Diskussion als die eigentliche Implementierung gesteckt wird. Das ist ja fast wie bei uns in der Firma.

Dann verwende ich halt weiter meine private Version. Ich dachte nur das wäre auch für andere interessant.
Kann man ein Modul explizit vom update ausschliessen?

Gruß,
Jörg

[betateilchen]

Kann man ein Modul explizit vom update ausschliessen?

ja. Steht in der commandref beschrieben.

Ist ja nicht so, als wäre die Lösung super kompliziert.

Es hat niemand behauptet, es sei super kompliziert. Aber bei solchen Änderungen stellt sich immer die Frage, ob diese für die Allgemeinheit sinnvoll wären oder nicht. Und bei einer url, die nur einmal pro Jahr evaluiert werden müsste, ist eine ad-hoc Evaluierung für mich wenig sinnvoll und würde voraussichtlich zu mehr Fragen führen als  dass sie Probleme lösen würde.

[Beta-User]

FHEM is home automation - und auch wenn hier nur etwas automatisiert wird, was einmal im Jahr passiert, verstehe ich nicht, warum mehr Zeit in die Diskussion als die eigentliche Implementierung gesteckt wird. Das ist ja fast wie bei uns in der Firma.

Nur am Rande: An sich hast du damit einen Punkt für dich.
ABER: Ich hatte "früher mal" auch den alten Ferienkalender (INet-Quelle, nicht lokal, ganz nach der damaligen Anleitung im wiki oder dem pdf) eingebunden, dann unbedacht einfach die Jahreszahl angepaßt und mich irgendwann gewundert, warum eigentlich FHEM denkt, dass grade keine Ferien sind, obwohl das am 2.01. doch eigentlich sonst immer so ist... Ursache: Der Anbieter hatte die URL-Struktur geändert .

Seitdem bin ich etwas skeptisch eingestellt, was Automatismen angeht, die sich auf externe Quellen verlassen, die man nicht sowieso regelmäßig überprüfen muß...

[nils_]

FHEM is home automation - und auch wenn hier nur etwas automatisiert wird, was einmal im Jahr passiert, verstehe ich nicht, warum mehr Zeit in die Diskussion als die eigentliche Implementierung gesteckt wird. Das ist ja fast wie bei uns in der Firma.

dann mach dir ein at, was am 1. januar ein defmod vom calendar device durchführt.
zack - automatisch 

[Beta-User]

dann mach dir ein at, was am 1. januar ein defmod vom calendar device durchführt.
zack - automatisch 

Was ist daran besser als das at, das den Kalender am 31.12. für's nächste Jahr holt ? Das würde es auch automatisch machen und dieses Kriterium voll erfüllen, und das ganz ohne "rotes Fragezeichen".

(Aber bitte erkennen wir an: auch der TE hat eine automatische Lösung vorgeschlagen, die die Augabenstellung generisch löst! Es mag Fälle geben, in denen die vorgeschlagene Änderung wirklich Vorteile bietet. Dass diese eben m.E. nicht für diesen Typ "unveränderlicher" Kalenderdaten bestehen, ist was substanziell anderes.)

[nils_]

Was ist daran besser als das at, das den Kalender am 31.12. für's nächste Jahr holt ?

nix.... außer das es einen tag später loslegt 

[betateilchen]

Hier die Variante, mit der die url erst beim tatsächlichen update des Kalenders evaluiert wird.

Code Auswählen Erweitern


Index: 57_Calendar.pm
===================================================================
--- 57_Calendar.pm      (revision 18659)
+++ 57_Calendar.pm      (working copy)
@@ -2471,7 +2471,9 @@

   Log3 $hash, 4, "Calendar $name: Updating...";
   my $type = $hash->{".fhem"}{type};
-  my $url= $hash->{".fhem"}{url};
+#  my $url= $hash->{".fhem"}{url};
+  my @ti   = localtime;
+  my $url  = ResolveDateWildcards($hash->{".fhem"}{url}, @ti);

   my $errmsg= "";
   my $ics;


[Dr. Boris Neubert]

Notiz an mich selbst:

Code Auswählen Erweitern

attr <calendarName> update onURLChanged

The update is only performed if the calendar's URL has changed. This usually occurs if the calendar's URL contains wildcards that evaluate to different URLs over time. The actual check for a changed URL is performed periodically at intervals as specified in the calendar device's definition.

Event erzeugen, wenn sich die URL ändert.

[betateilchen]

Notiz an mich selbst:

auweia... so weit ist es schon?

Aber die Idee finde ich gut. Wir beide sollten mal einen Workshop machen, um unsere Ideen zum Kalendermodul auszutauschen und umzusetzen...

[betateilchen]

Event erzeugen, wenn sich die URL ändert.

soll ich mal einen patch bauen?

[Dr. Boris Neubert]

Gerne.

Kannst Du gerne auch einchecken inklusive Doku.

[betateilchen]

Code = fertsch.

Doku = morgen



Edit: ich habe auch gleich noch die Änderung eingebaut, Intervalle von 0 nicht mehr zuzulassen, um eine Endlosschleife zu vermeiden. Wird ein Intervall von 0 im define angegeben, wird künftig der default Wert von 3600 verwendet.

[betateilchen]

sch... SVN. Arbeit von 2 Stunden futsch.

[betateilchen]

Hallo Boris, kann es sein, dass das Attribut update = sync|async überhaupt nicht mehr relevant ist?
Im Code habe ich keine Stelle gefunden, an der dies ausgewertet wird.

Wenn dem tatsächlich so ist, schmeiß ich das gleich aus der commandref raus.

[Otto123]

Hallo Udo,

das ist genau mein Eindruck. Und kann es sein, dass update = none zumindest beim Systemstart keine Wirkung hat?
Ich habe einen Kalender eingebunden, der blockiert meinen Pi 1 jeweils (gefühlt) 5 min beim Laden. 
Beim Systemstart und beim Update...
Ich kann das noch genauer untersuchen.

Gruß Otto

[betateilchen]

So langsam gerät dieser Thread komplett durcheinander...

[betateilchen]

Ich nehme meine Frage bezüglich sync/async zurück, ich habe doch eine Stelle gefunden, nämlich beim Verarbeiten des per url geladenen Kalenders.

Code Auswählen Erweitern


    if(AttrVal($name, "update", "sync") eq "async") {
      Calendar_AsynchronousUpdateCalendar($hash);
    } else {
      Calendar_SynchronousUpdateCalendar($hash);
    }


Das Holen des Kalenders von der url erfolgt immer nonblocking.

Das erklärt auch folgendes Phänomen:

Wenn das Attribut update auf "none" gesetzt ist, werden die Kalenderdaten immer synchron (blocking) verarbeitet.  Eine asynchrone Verarbeitung findet nur statt, wenn das Attribut explizit auf "async" gesetzt ist. Das wiederum schließt die Verwendung von "none" aus.

Genau so bin ich nämlich auf diese Frage gestoßen. Wenn ich das Attribut update = onUrlChanged setze, funktioniert das asynchrone Verarbeiten auch nicht mehr.

Man sollte darüber nachdenken, die asynchrone Verarbeitung als Standard zu verwenden anstatt wie bisher die synchrone Variante.

[betateilchen]

Achso, und um diese Frage noch zu beantworten

kann es sein, dass update = none zumindest beim Systemstart keine Wirkung hat

Beim Systemstart wird ein Kalender immer geladen, weil zum Zeitpunkt, zu dem das define ausgeführt wird, das Attribut noch gar nicht bekannt ist.

Das Attribut update gibt laut commandref

The optional parameter interval is the time between subsequent updates in seconds.

den Abstand vor, in dem ein Update des geladenen Kalenders durchgeführt wird. Insofern ist das kein Fehler, sondern genau das Verhalten, das auch beschrieben ist.

[Dr. Boris Neubert]

Hallo,

es wird komplex...

Ich bin heute Abend einige Stunden im Zug unterwegs und gucke mal in den Code. Dann melde ich mich mit validierten Aussagen wieder.

Folgende Dinge aber fallen mir jetzt schon ein:

async|sync und none|onChangeUrl sind zwei unabhängige Aspekte und sollten in zwei Attribute namens synchronousUpdate und update kodiert werden.

Code Auswählen Erweitern

attr myCalendar synchronousUpdate 0|1 (asynchon ist damit der Default).

Code Auswählen Erweitern

attr myCalendar update none|onChangeUrl

Das bricht die Abwärtskompatibilität, macht aber nix kaputt.

Der Kalender sollte kein Update bei der Definition machen und ich dachte, dass erst bei global:INITALIZED ein Update angestoßen würde. Dann sind die Attribute bekannt. Allerdings wird der (ziehmlich fette) Zustand des Kalenders nicht gespeichert, so dass es doch sein kann, dass man den Kalender wenigstens einmal nach dem Start abgeholt haben muss.

Die einzelnen Schritte, die zu den Weckzeiten und Prüfintervallen des Kalenders abgearbeitet werden, müssen vermutlich noch leicht anders geschnitten werden. Zum Glück habe ich das Modul gut dokumentiert.

Viele Grüße
Boris

[nils_]

bevor ihr alles neu macht (es gibt ja nun mehrere threads mit erweiterungen ), bitte bindet doch den übersetzten teil der commandref mit ein.
danke!

[betateilchen]

@nils_ Wenn ich herausfinden könnte, welche der Übersetzungen jetzt die "verbindliche" ist, hätte ich das längst gemacht.

[betateilchen]

async|sync und none|onChangeUrl sind zwei unabhängige Aspekte und sollten in zwei Attribute namens synchronousUpdate und update kodiert werden.
...
Das bricht die Abwärtskompatibilität, macht aber nix kaputt.

Die Idee mit zwei Attributen wäre jetzt mein nächster Schritt gewesen.

Zum Thema Abwärtskompatibilität: sollte ein User tatsächlich das vorhandene Attribut "update" auf sync|async gesetzt haben, kann man in Calendar_Attr() eine entsprechende Meldung ins Log schreiben und das Setzen einfach ignorieren.

Bevor ich aber jetzt weiterbaue, warte ich erstmal ab, was Boris heute noch rausfindet

[nils_]

@nils_ Wenn ich herausfinden könnte, welche der Übersetzungen jetzt die "verbindliche" ist, hätte ich das längst gemacht.

ja verstehe ich.
darum hatte ich ja auch im commdref thread nochmal nachgefragt

das soll euch aber nicht bei der weiterentwicklung bremsen  

[Dr. Boris Neubert]

Logik scheint ganz allein in GetUpdate() reinzumüssen.
none sollte auch beim Start NICHT Update anstoßen, wenn ich mir den Code ansehe.

[betateilchen]

Logik scheint ganz allein in GetUpdate() reinzumüssen.
none sollte auch beim Start NICHT Update anstoßen, wenn ich mir den Code ansehe.

Beim ersten Satz bin ich komplett bei Dir.
Beim zweiten Satz bin ich mir nicht sicher. Davon abgesehen, würde das Laden eines Kalenders beim define für mich immer Sinn machen, unabhängig von einem gesetzten Attribut. Im Sinnes eines konsistenten Datenbestandes halte ich das für entscheidend.

[Dr. Boris Neubert]

ad none: muss ich mir Sonntagabend auf 28" nochmal überlegen...

[betateilchen]

Ok, den Rest habe ich in Arbeit.

[betateilchen]

Folgende Änderungen sind nun umgesetzt

• In der Definition eines Calendar-Device können nun Wildcards (Platzhalter) - analog zu den Parametern bei FileLog - angegeben werden. Diese werden jeweils beim Kalenderupdate ausgewertet und durch die tatsächlichen Werte ersetzt. Damit können beispielsweise Jahreszahlen in der URL automatisch angepasst werden.
• Das Attribut "update" hat den neuen Wert "onUrlChanged" dazubekommen. Damit kann festgelegt werden, dass eine Aktualisierung des Kalenders tatsächlich nur dann erfolgt, wenn sich die URL seit dem letzten Abruf verändert hat. Dieser Attributwert macht eigentlich nur dann Sinn, wenn im define des device mit Wildcards (siehe 1.) gearbeitet wird.
• Die Werte "sync" und "async" wurden aus dem Attribut "update" entfernt. Wird einer diesen beiden Werte beim FHEM Start in der Konfiguration gefunden, wird eine Logmeldung ausgegeben, die auf das neue Attribut "synchronousUpdate" hinweist. Das vorhandene Attribut "update" wird gelöscht, die Konfiguration wird jedoch NICHT automatisch gespeichert, es erscheint das rote Fragezeichen. Damit kann der Anwender erkennen, dass sich etwas geändert hat.
• Das Attribut "synchronousUpdate" wurde neu eingeführt. Damit kann gesteuert werden, ob das Kalenderupdate (Verarbeitung der gelesenen Kalenderdaten) blocking (Attributwert = 1) oder nonblocking (Attributwert = 0) ausgeführt werden soll. Defaultwert ist ab sofort nonblocking.
• Ein Intervall von 0 ist ab sofort nicht mehr zulässig. Wird dieser Wert angegeben, verwendet das device automatisch den Defaultwert 3600 Sekunden. Eine entsprechende Logmeldung wird ausgegeben.
• Die englische commandref wurde den Änderungen entsprechend angepasst.

[betateilchen]

ad none: muss ich mir Sonntagabend auf 28" nochmal überlegen...

Zur Unterstützung Deiner Überlegungen habe ich zwei Debug Meldungen eingebaut und getestet.

Momentan verhält sich ein Calendar device wie folgt:

Variante 1: Attribut "update" gar nicht gesetzt.

Code Auswählen Erweitern


2019.02.23 12:17:49 0: Server shutdown
2019.02.23 12:17:49 3: web: port 8084 opened
2019.02.23 12:17:49 3: telnet: port 7072 opened
2019.02.23 12:17:50 3: n_fheminfo return value: Statistics data sent to server. See Logfile (level 4) for details.
2019.02.23 12:17:50 0: Featurelevel: 99.99
2019.02.23 12:17:50 0: Server started with 17 defined entities (fhem.pl:18623/2019-02-17 perl:5.024001 os:linux user:fhem pid:2126)
2019.02.23 12:17:50 3: Opening mqtt2 device
2019.02.23 12:17:50 3: mqtt2 device opened
2019.02.23 12:17:52 1: DEBUG>GetUpdate 1
2019.02.23 12:17:52 1: DEBUG>ProcessUpdate 1
2019.02.23 12:17:55 3: DbLog dbLog - Creating Push-Handle to database SQLite:dbname=/opt/fhem/sqldb/fhemlog.db with user
2019.02.23 12:17:55 3: DbLog dbLog - Push-Handle to db SQLite:dbname=/opt/fhem/sqldb/fhemlog.db created


Ergebnis: Sowohl GetUpdate als auch ProcessUpdate werden ausgeführt (die 1 ist der Wert von $init_done)

Variante 2: Danach wurde das Attribut "update" auf den Wert "none" gesetzt und erneut ein shutdown restart ausgeführt.

Code Auswählen Erweitern


2019.02.23 12:18:35 0: Server shutdown
2019.02.23 12:18:35 3: web: port 8084 opened
2019.02.23 12:18:35 3: telnet: port 7072 opened
2019.02.23 12:18:36 3: n_fheminfo return value: Statistics data sent to server. See Logfile (level 4) for details.
2019.02.23 12:18:36 0: Featurelevel: 99.99
2019.02.23 12:18:36 0: Server started with 17 defined entities (fhem.pl:18623/2019-02-17 perl:5.024001 os:linux user:fhem pid:2137)
2019.02.23 12:18:36 3: Opening mqtt2 device
2019.02.23 12:18:36 3: mqtt2 device opened
2019.02.23 12:18:41 3: DbLog dbLog - Creating Push-Handle to database SQLite:dbname=/opt/fhem/sqldb/fhemlog.db with user
2019.02.23 12:18:41 3: DbLog dbLog - Push-Handle to db SQLite:dbname=/opt/fhem/sqldb/fhemlog.db created


Ergebnis: GetUpdate und ProcessUpdate werden nicht ausgeführt.

Trotzdem fände ich es "logischer", einen Kalender zumindest beim Systemstart zwingend zu laden, da die Kalenderdaten nirgends persistent in FHEM gespeichert werden.

[dancatt]

Hallo,

prima Arbeit. Vielen Dank dafür.
Finde ich schon mal super dass im Falle eines Ferienkalenders mit Wildcard %Y und Attribut update=onUrlChanged der Kalender nur neu eingelesen wird wenn sich was an der Url ändert. Problem mit dem Ferienkalender ist nun, wenn sich die Url ändert (bei neuem Jahr) man sich eventuell noch in den Weihnachtsferien befindet. Wird nun der neue Ferienkalender eingelesen, dann sind keine Ferien mehr. Oder sehe ich das falsch?
Gibt es dazu eine gängige Lösung? Was mir einfällt wäre den Kalender mit update=none einzustellen und ein jährliches at zu definieren welches erst nach den Weihnachtsferien den Kalender aktualisiert. Könnte man aber auch für das Attribut update noch einen Wert onUrlChangedAndNoAlarm (oder sowas in der Art) einbauen? Dann würde der Kalender erst aktualisiert werden, wenn sich die Url ändert UND in meinem Fall KEINE Weihnachtsferien mehr wären.

Ich hoffe ich konnte das Problem halbwegs klar formulieren.

Vielen Dank.

Gruß Daniel

[Otto123]

Hallo Daniel,

klingt unlogisch.
Wenn Ferien vom  25.12. bis 5.1. sein sollten, dann
müssen im alten Kalender Ferien vom 25.12. bis 31.12. und im neuen Kalender Ferien vom 1.1. bis 5.1 stehen.

Gruß Otto

[dancatt]

klingt unlogisch.
Wenn Ferien vom  25.12. bis 5.1. sein sollten, dann
müssen im alten Kalender Ferien vom 25.12. bis 31.12. und im neuen Kalender Ferien vom 1.1. bis 5.1 stehen.

Dem ist leider nicht so. Es gibt pro Jahr nur einmal Weihnachtsferien. In deinem Fall gäbe es zwei. In der angehängten ics-Datei für 2019 sieht man dass am Anfang Januar die Weihnachtsferien von 2018 auch nicht enthalten sind.

[Otto123]

Naja dann darfst Du den Kalender nicht automatisch aktualisieren (macht hier sowieso keinen Sinn).
Ein Event auf das Ende der Weihnachtsferien zum einlesen des neuen Kalenders?

Ich weiß: man wird nicht alle Ausnahmen des Lebens automatisch verarbeiten können

Gruß Otto

[Beta-User]

Nur als Anmerkungen: Man kann diese ganzen Probleme umgehen, indem man den Ferienkalender nicht auf Gedeih und Verderb getrennt von anderen Kalendern hält, sondern in einen fortlaufenden anderen Kalender importiert, der immer an derselben Stelle verfügbar ist.

Da man - wenn man das für holiday2we nutzen will - sowieso eine Nachbearbeitung braucht, kann man dann auch gleich immer mal wieder eine .holiday-Datei aus dem Kalender ableiten, die dann nur Ferientermine enthält, und die dann verwenden oder sich direkt den holiday-Wert anzeigen lassen (der kennt auch ein Reading "tomorrow", falls das jemanden interessiert).

(Bei Bedarf kann ich den Code zur Ableitung des .holiday nochmal verlinken, steht irgendwo in diesem Forumsbereich unter "Kein Bedarf für Calendar2holiday" oder so ähnlich...)

[betateilchen]

Problem mit dem Ferienkalender ist nun, wenn sich die Url ändert (bei neuem Jahr) man sich eventuell noch in den Weihnachtsferien befindet. Wird nun der neue Ferienkalender eingelesen, dann sind keine Ferien mehr. Oder sehe ich das falsch?

Ja das siehst du falsch.

[dancatt]

Ja das siehst du falsch.

Darf ich dann fragen wie es denn wirklich ist?
Vielen Dank.

[betateilchen]

Ist doch ganz einfach...

Ein Ferientermin vom 20.12.2018  bis zum 05.01.2019, der im ics file für 2018 steht, ist doch Deinem Calendar device in FHEM längst mit Start- und Endezeitpunkt bekannt.

Wenn am 01.01.2019 dann ein "neues" ics file gelesen wird, werden die "bekannten" Termine keineswegs zuerst gelöscht, sondern die neuen Termine für 2019 hinzugefügt. Es wird nämlich ein "update" durchgeführt, kein "reload".

Zum Glück funktioniert Software manchmal logischer, als manche Anwender denken können.

[dancatt]

Danke für die Erklärung. Mir war das so nicht bewusst. Dachte sobald die URL neu ist wird auch alles neu eingelesen. Also IM Prinzip ein reload. Trotzdem vielen Dank.