Anregung fuer 57_Calendar zur Nutzung von ferienwiki.de

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