Ab heute haben wir eigentlich Urlaub, demnach habe ich in meiner Holiday Datei folgendes eingetragen:
# Siehe auch
# http://de.wikipedia.org/wiki/Feiertage_in_Deutschland
# Feiertage NRW
1 01-01 Neujahr
1 05-01 Tag der Arbeit
1 10-03 Tag der deutschen Einheit
1 11-01 Allerheiligen
1 12-24 Heiligabend
1 12-25 1. Weihnachtstag
1 12-26 2. Weihnachtstag
1 12-31 Silvester
# 2 -48 Rosenmontag
2 -02 Karfreitag
2 01 Ostermontag
2 39 Christi Himmelfahrt
2 50 Pfingsten
2 60 Fronleichnam
# Urlaube
4 05-19 05-21 Testurlaub
Diese ist als Feiertage_NRW holiday Device definiert:
Internals:
NAME Feiertage_NRW
NR 67
STATE none
TRIGGERTIME 1495231202.04379
TYPE holiday
Readings:
2017-05-09 08:05:16 state none
2017-05-09 08:05:16 tomorrow none
2017-05-09 08:05:16 yesterday none
Attributes:
room Kalender
Wie man sieht, ist der STATE hier schon mal "none", obwohl er für heute und morgen ja "Testurlaub" sein sollte. Da läuft also schon mal was falsch.
Zudem ist Feiertage_NRW als holiday2we definiert, demnach sollte $we für heute eigentlich auch 1 sein, ist es aber nicht.
Wenn ich ein "get Feiertage_NRW today" mache, kommt aber korrekt "Testurlaub" zurück. Also ist der Eintrag in der Datei wohl korrekt.
Welchen Fehler habe ich hier? Warum ändert sich der STATE vom holiday device nicht?
Edit: Nach kurzem Blick in den Code, habe ich jetzt mal manuell in der Commandline ein
{holiday_refresh ("Feiertage_NRW", 0)}
ausgeführt.
Dadurch wird der STATE aktualisiert und auch $we ist dann korrekt gesetzt.
Funktioniert hier vielleicht die automatische tägliche Aktualisierung nicht? Im List oben war der STATE ja auch vom 09. Mai, ist ja schon ein paar Tage her, obwohl die FHEM Instanz in den letzten Tagen auch das eine oder andere mal neugestartet wurde. FHEM ist im Übrigen auf dem aktuellen Stand, letztes Update gestern morgen. Eigentlich sollte laut Code ja ein Timer für die nächtliche Aktualisierung sorgen.
holiday setzt STATE beim FHEM-Start und kurz nach Mitternacht, und ueberwacht nicht die Datei.
Wenn die Aenderung der Datei den heutigen Tag betrifft, dann muss man entweder
modify <NAME>
oder
{ holiday_refresh("<NAME>" }
ausfuehren. Oder FHEM neu starten.
Die Datei wurde seit Monaten nicht geändert und fhem wurde wie gesagt erst gestern neu gestartet. Auch nach einem restart heute morgen wurde das Device nicht aktualisiert.
Ich habe in der Zeile 64 von FHEM/95_holiday.pm ein bisschen Logging eingebaut (update erst ab Morgen):
Log3 $name, 5, "holiday_refresh $name called for $fordate";
Kannst du bitte mit dieser Version und attr global verbose 5 pruefen, welche Meldungen betreffend deiner Datei im FHEM-Log bei einem Neustart auftauchen? Gibt es jetzt schon irgendwelche Fehlermeldungen? Verwendest du configDb?
Muss ein Sonderfall sein, da holiday bei mir seit vielen Jahren unveraendert ohne Probleme laeuft.
Kann ich am Sonntag testen, wenn wir zurück sind. Melde mich dann. :)
Fehlermeldungen sind aktuell keine im Log gewesen. Verwende auch nicht configDb.
Kurzes Update aus der Ferne: Das Device hat sich über Nacht wieder nicht automatisch aktualisiert. Es steht noch alles auf dem Stand von gestern.
Internals:
NAME Feiertage_NRW
NR 67
STATE Testurlaub
TRIGGERTIME 1495317602.07457
TYPE holiday
Readings:
2017-05-19 08:43:47 state Testurlaub
2017-05-19 08:43:47 tomorrow Testurlaub
2017-05-19 08:43:47 yesterday none
Attributes:
room Kalender
Nach manueller Aktualisierung über {holiday_refresh ("Feiertage_NRW")}:
Internals:
NAME Feiertage_NRW
NR 67
STATE Testurlaub
TRIGGERTIME 1495317602.0909
TYPE holiday
Readings:
2017-05-20 07:38:39 state Testurlaub
2017-05-20 07:38:39 tomorrow Testurlaub
2017-05-20 07:38:39 yesterday Testurlaub
Attributes:
room Kalender
Die Daten stimmen alle, nur die Automatik scheint bei mir nicht zu klappen. Könnte ich natürlich notfalls einfach über ein nächtliches DOIF lösen, das den refresh anstößt.
Werde aber morgen nach dem Update noch mal genau das Logfile checken.
Ist nur hier aus der Ferne mit dem Handy gerade nicht so einfach. :)
Das sind die Einträge im Log nach einem shutdown restart:
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-20
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 00-00
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 00-00
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-19
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-21
2017.05.20 08:18:31 5: Compute sunrise/sunset for latitude 51.56522 , longit
ude 6.99477
2017.05.20 08:18:31 5: Compute sunrise/sunset for latitude 51.56522 , longit
ude 6.99477
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-19
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 00-00
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 00-00
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-18
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-20
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-21
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 00-00
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 00-00
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-20
2017.05.20 08:18:31 5: holiday_refresh Feiertage_NRW called for 05-22
Das Device hat sich übrigens beim Restart nicht aktualisiert. Das list sieht noch genauso aus wie im vorherigen Post, auch die Reading Timestamps sind weiter von 07:38:39 und nicht etwa von 08:18, wo der Refresh angeblich laut Log getriggered wurde.
ZitatDas list sieht noch genauso aus wie im vorherigen Post
Um das zu analysieren brauche ich (wie im vorherigen Post erwaehnt :) ) die Meldungen von "attr global verbose 5" nach dem Neustart. Ich vermute, dass die Readings nach dem Start von einem verspaetet eingelesenen Statefile ueberschrieben werden.
Die Meldungen mit Datum 00-00 kommt mir merkwuerdig vor, ich weiss im Moment nicht, wie man das provoziert.
Danke fuer den Log.
Ich hatte ein Bug bei der Initialisierung, da ich nicht damit gerechnet habe, dass vor meine eiegene (d.h. holiday-interne) Initialisierng ein get holiday von anderen Modulen (DOIFTOOLS oder HOMESTATE / Residents) aufgerufen wird. Ich habe das jetzt hoffentlich gefixt, ab morgen per update.
Prima. Rückmeldung gibt's dann morgen nach dem Test. :)
Läuft mit der Änderung bisher problemlos, Danke. :)