Anregung fuer 57_Calendar zur Nutzung von ferienwiki.de

[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]

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]

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.