Hallo,
leider bekomme ich in meinem FHEM keine klare Auswertung von Wochentagen/ Wochenenden mehr hin.
$we liefert immer eine 1, unabhängig davon ob Wochenende oder Wochentag ist.
Auch {IsWe()} oder beispielsweise {IsWe(20210929)} gibt eine 1 zurück.
Ich nutze holiday2we.
Das global Device sieht wie folgt aus:
Internals:
DEF no definition
FD 3
NAME global
NR 1
STATE no definition
TYPE Global
currentlogfile ./log/fhem-2021-10-01.log
logfile ./log/fhem-%Y-%m-%d.log
Attributes:
DbLogExclude .*
altitude 63
autoload_undefined_devices 1
autosave 0
backup_before_update 0
configfile fhem.cfg
group System
holiday2we Feiertage,Ferien,Urlaub
language DE
latitude *
logfile ./log/fhem-%Y-%m-%d.log
longitude *
modpath .
motd .
statefile ./log/fhem.save
updateInBackground 0
verbose 3
version fhem.pl:24983/2021-09-16
Und hier die Kalender:
Feiertage:
Internals:
DEF ical file feiertage.ics 86400
NAME Feiertage
NOTIFYDEV global
NR 178
NTFY_ORDER 50-Feiertage
STATE triggered
TYPE Calendar
Helper:
DBLOG:
lastUpdate:
logdb:
TIME 1633077417.15869
VALUE 2021-10-01 10:36:55
nextUpdate:
logdb:
TIME 1633077417.15869
VALUE 2021-10-02 10:36:55
nextWakeup:
logdb:
TIME 1633077417.18851
VALUE 2021-10-02 10:36:55
state:
logdb:
TIME 1633077417.176
VALUE triggered
READINGS:
2018-04-29 10:49:03 calname Feiertage
2021-10-01 10:36:57 lastUpdate 2021-10-01 10:36:55
2021-10-01 10:36:57 nextUpdate 2021-10-02 10:36:55
2021-10-01 10:36:57 nextWakeup 2021-10-02 10:36:55
2021-10-01 10:36:57 state triggered
Attributes:
onCreateEvent { $e->{end}= $e->{start}+86400 unless(defined($e->{end}))}
Inhalt:
01.01.2021 00:00 24h Neujahr in Deutschland
02.04.2021 00:00 24h Karfreitag in Deutschland
05.04.2021 00:00 24h Ostermontag in Deutschland
01.05.2021 00:00 24h Tag der Arbeit in Deutschland
13.05.2021 00:00 24h Christi Himmelfahrt in Deutschland
24.05.2021 00:00 24h Pfingstmontag in Deutschland
03.10.2021 00:00 24h Tag der Deutschen Einheit
31.10.2021 00:00 25h Reformationstag in Deutschland
25.12.2021 00:00 24h 1. Weihnachtstag in Deutschland
26.12.2021 00:00 24h 2. Weihnachtstag in Deutschland
Ferien:
Internals:
DEF ical file ./ferien.ics 86400
FUUID 5cb57027-f33f-357a-e791-53a18df7fb251417
NAME Ferien
NOTIFYDEV global
NR 74
NTFY_ORDER 50-Ferien
STATE triggered
TYPE Calendar
Helper:
DBLOG:
lastUpdate:
logdb:
TIME 1633077415.53248
VALUE 2021-10-01 10:36:53
nextUpdate:
logdb:
TIME 1633077415.53248
VALUE 2021-10-02 10:36:53
nextWakeup:
logdb:
TIME 1633077415.56386
VALUE 2021-10-02 10:36:53
state:
logdb:
TIME 1633077415.55086
VALUE triggered
READINGS:
2021-10-01 10:36:55 lastUpdate 2021-10-01 10:36:53
2021-10-01 10:36:55 nextUpdate 2021-10-02 10:36:53
2021-10-01 10:36:55 nextWakeup 2021-10-02 10:36:53
2021-10-01 10:36:55 state triggered
Inhalt
01.02.2021 00:00 48h Winterferien
29.03.2021 00:00 12d Osterferien
14.05.2021 00:00 24h Pfingstferien
25.05.2021 00:00 24h Pfingstferien
22.07.2021 00:00 42d Sommerferien
18.10.2021 00:00 12d Herbstferien
23.12.2021 00:00 16d Weihnachtsferien
Urlaub:
Internals:
DEF ./FHEM/Urlaub.holiday
FUUID 61489635-f33f-357a-c76d-9eeb9ad238e61154
HOLIDAYFILE ./FHEM/Urlaub.holiday
NAME Urlaub
NR 533
READONLY 0
STATE none
TRIGGERTIME 1633125602.00782
TYPE holiday
Helper:
DBLOG:
state:
logdb:
TIME 1633077396.01682
VALUE none
tomorrow:
logdb:
TIME 1633077396.01682
VALUE none
yesterday:
logdb:
TIME 1633077396.01682
VALUE none
READINGS:
2021-10-01 10:36:36 state none
2021-10-01 10:36:36 tomorrow none
2021-10-01 10:36:36 yesterday none
Deine Calendar-Devices haben in state auch "triggered". Aus Sicht von holiday2we ist das dann "Feiertag", da nicht "none".
Du mußt also entweder dafür sorgen, dass das Reading "state" in diesen Devices korrekt gesetzt wird, oder du musst halt das ganze umpacken. Ich mache das z.B., indem ich aus einem zentralen (ical-) Calendar dann ein paar .holiday-Dateien mache und die als holiday-Devices einbinde (und teils in holiday2we angebe).
Hallo Beta-User,
danke für deine Rückmeldung, das Vorgehen widerspricht aber leider dem was ich Automatisierung nennen würde, denn das würde bedeuten das ich jedes Jahr aufs neue die Kalender zusammenpicken müsste.
Um dies zu umgehen habe ich hier in unserem Ort sogar unseren Abfallentsorger so lange getriezt, bis dieser die Entsorgungskalender als ical Datei zur Verfügung gestellt hat :-)
Was mich wundert, früher (vor ~1,5-2 Jahren) hat es bei mir problemlos funktioniert (ich war längere Zeit im Ausland).
Damals habe ich es so eingerichtet dass die Feiertage, sowie Ferien automatisch einmal im Jahr geholt werden und ich nicht händisch nachbessern muss.
Warum setzt das Calendar Modul den state auf triggered (das passiert bei jedem Update)? Das macht doch aus Sicht FHEM keinen Sinn, oder übersehe ich etwas?
Das Verändern vom State-reading stellt sich leider ebenfalls als Problem dar, denn setstate, ändert nicht das Reading und set Ferien state none gibt eine Fehlermeldung zurück "Unknown argument state, choose one of update reload "
Wie komme ich hier an ein korrekt funktionierendes "automatisiertes" System ?
Gruß
Alex
Also:
IsWe() ist "relativ neu", holiday2we hat früher (mit Value()) auf STATE (das Internal) geschaut, evtl. hast du da mit stateFormat irgendwas hingezaubert? (Ist im list aber nicht erkennbar gewesen).
Eventuell hattest du auch mal dummy-Devices geschaltet und die in h2we eingebunden?
Gebe dir aber recht, dass das automatisch laufen sollte... Bei mir macht das "Zwischenstück" zwischen ical und holiday der Code aus https://forum.fhem.de/index.php/topic,85759.msg1167954.html#msg1167954 (https://forum.fhem.de/index.php/topic,85759.msg1167954.html#msg1167954), wobei wir einen "Familienkalender" haben, in den dann die Abfall-Termine und eben Ferien (und Feiertage, die aber über das "klassische" holiday kommen) und weitere "allgemeingültige Termine", die hier nicht interessieren, importiert sind.
Hier das aktuelle at dazu, dann wird ggf. klarer, dass man (außer für "passende Einträge" im ical zu sorgen) eigentlich nicht viel tun muss:
define a_make_holiday at *23:30 { return if $wday != 5;;\
myCalendar2Holiday('Familienkalender','.*[fF]erie.*','ferien','summary',10);;\
myCalendar2Holiday('Familienkalender','.*(Bioabfall|Restmüll).*','muell','summary',10)\
}
Ich kenne Calendar nicht.
Was bedeutet "triggered"?
Wuerde es helfen, wenn IsWe neben none auf triggered prueft?
Zitat von: rudolfkoenig am 01 Oktober 2021, 15:19:55
Ich kenne Calendar nicht.
Was bedeutet "triggered"?
Wuerde es helfen, wenn IsWe neben none auf triggered prueft?
"triggered" ist mAn. unspezifisch, v.a., wenn es ein "allgemeiner Kalender ist, in dem "alles mögliche" steht:
ZitatWenn der Kalendar neu geladen oder aktualisiert oder eine Alarm-, Start- oder Endzeit erreicht wurde, wird ein FHEM-Event erzeugt: triggered
Man kann sich darauf verlassen, dass alle Readings des Kalenders in einem konsistenten und aktuellen Zustand befinden, wenn dieses Event empfangen wird.
Wir hatten eine ähnliche Diskussion mal zu den IsWe()-Entwicklungszeiten. Da war die Frage aber, ob man neben/anstatt "state" noch auf ein anderes Reading für "today" schauen sollte (wenn es da ist). Damit könnte man uU. über einen userReadings-Mechanismus in Calendar dann Code anflanschen, der das passend befüllt. Im Ergebnis ist es aber mAn. dann auch nicht komplizierter, das in einen passenden dummy zu schreiben, oder eben meinen Code für die Generierung von holiday-Files zu übernehmen (der ist generisch, "muell" wird z.B. dann auch nicht für h2we verwendet und dient nur zur Anzeige).
IsWe() sollte schnell bleiben, von daher finde ich zumindest heute deine ablehnende Haltung gegen was anderes wie "state" völlig berechtigt.
Verstehe ich richtg, IsWe() bzw $we hat (ueber holiday2we) fuer Calendar nie funktioniert?
Hab gedacht, dass diese (mir unbekannte) Kombination durch eine Aenderung in Calendar Modul kaputtgegangen ist, da ich IsWe seit zwei Jahren nicht angefasst habe.
Zitat von: Nighthawk am 01 Oktober 2021, 14:54:59
Was mich wundert, früher (vor ~1,5-2 Jahren) hat es bei mir problemlos funktioniert (ich war längere Zeit im Ausland).
Das Calendar Modul wurde vor einiger Zeit komplett umgebaut - vielleicht war das während Deiner Abwesenheit. Dabei haben sich eine ganze Reihe grundlegender Mechanismen geändert.
Ich kann mich irren, aber ich vermute, IsWe() ist primär für die Verwendung mit holiday devices gedacht und nicht generisch für Calendar-devices.
Fakt ist: eine Abfrage auf ein CalendarDevice zum Beispiel in der Form "get <calDev> tomorrow" wird nicht das Ergebnis liefern, das Du erwartest, sondern eine Fehlermeldung.
Unknown argument tomorrow, choose one of update:noArg reload:noArg events find text full summary location description categories alarm start end vcalendar:noArg vevents:noArg
Zitat von: rudolfkoenig am 01 Oktober 2021, 15:44:38
Verstehe ich richtg, IsWe() bzw $we hat (ueber holiday2we) fuer Calendar nie funktioniert?
Richtig verstanden.
Zitat von: betateilchen am 01 Oktober 2021, 15:48:49
Ich kann mich irren, aber ich vermute, IsWe() ist primär für die Verwendung mit holiday devices gedacht und nicht generisch für Calendar-devices.
Jein. $we und h2we hatten ganz klar schon immer holiday im Blick und nie Calendar oder sonst was. Es kann aber im Prinzip jeder TYPE abgefragt werden, es werden einfach die jeweiligen Readings für "gestern bis morgen" ausgelesen, und alles, was nicht "none" ist, ist halt "1". Da aber Calendar "state" (für "heute") anders versteht, klappt das weder da, noch bei anderen TYPE, die "state" in ihrem eigenen Sinne interpretieren bzw. befüllen.
IsWe() macht nur die "alte Variable" $we systemweit einheitlich verfügbar.
MAn. macht es auch keinen Sinn, Calendar irgendwie für h2we/IsWe() aufzubohren, weil da "alles mögliche" drinstehen kann und man die Daten sowieso irgendwie aufbereiten muss.
Zitat von: Beta-User am 01 Oktober 2021, 16:06:39
$we und h2we hatten ganz klar schon immer holiday im Blick und nie Calendar oder sonst was.
sag ich doch.
Zitat von: Beta-User am 01 Oktober 2021, 16:06:39
Da aber Calendar "state" (für "heute") anders versteht...
und ab Werk auch keine readings "tomorrow" und "yesterday" kennt, kann das auch in der Vergangenheit noch nie funktioniert haben.
Zitat von: Beta-User am 01 Oktober 2021, 16:06:39
MAn. macht es auch keinen Sinn, Calendar irgendwie für h2we/IsWe() aufzubohren
Muss man auch nicht, es reicht ein einfaches notify, um die gestellte Aufgabe zu lösen.
Hilfreich wäre es allenfalls, wenn man IsWe() dahingehend nutzen könnte, auch auf ein reading "today" anstatt nur auf "state" für heute zu reagieren.
Mit dem bereits genannten notify und setreading liessen sich die readings yesterday/today/tomorrow in einem Calendar-device problemlos erzeugen und befüllen.
ZitatHilfreich wäre es allenfalls, wenn man IsWe() dahingehend nutzen könnte, auch auf ein reading "today" anstatt nur auf "state" für heute zu reagieren.
yesterday und tomorrow gabs schon, ich habe nun IsWe() mit today erweitert.
Achtung: das gilt nicht fuer $we.
Zitat von: Beta-User am 01 Oktober 2021, 15:13:15
Also:
IsWe() ist "relativ neu", holiday2we hat früher (mit Value()) auf STATE (das Internal) geschaut, evtl. hast du da mit stateFormat irgendwas hingezaubert? (Ist im list aber nicht erkennbar gewesen).
Eventuell hattest du auch mal dummy-Devices geschaltet und die in h2we eingebunden?
Gebe dir aber recht, dass das automatisch laufen sollte... Bei mir macht das "Zwischenstück" zwischen ical und holiday der Code aus https://forum.fhem.de/index.php/topic,85759.msg1167954.html#msg1167954 (https://forum.fhem.de/index.php/topic,85759.msg1167954.html#msg1167954), wobei wir einen "Familienkalender" haben, in den dann die Abfall-Termine und eben Ferien (und Feiertage, die aber über das "klassische" holiday kommen) und weitere "allgemeingültige Termine", die hier nicht interessieren, importiert sind.
Hier das aktuelle at dazu, dann wird ggf. klarer, dass man (außer für "passende Einträge" im ical zu sorgen) eigentlich nicht viel tun muss:
define a_make_holiday at *23:30 { return if $wday != 5;;\
myCalendar2Holiday('Familienkalender','.*[fF]erie.*','ferien','summary',10);;\
myCalendar2Holiday('Familienkalender','.*(Bioabfall|Restmüll).*','muell','summary',10)\
}
Danke für die Antworten, ich fürchte dann bleibt mir nicht anderes übrig als den Ansatz von Beta-User umzusetzen.
Gruß
Alex
Hallo,
dann hätte aber das Wiki noch nie gestimmt. Oder hab ich das falsch verstanden? Vielleicht hat auch Jemand zu meinem Problem eine Antwort.
https://forum.fhem.de/index.php/topic,123818.0.html (https://forum.fhem.de/index.php/topic,123818.0.html)
Zitat von: rudolfkoenig am 01 Oktober 2021, 18:24:28
yesterday und tomorrow gabs schon, ich habe nun IsWe() mit today erweitert.
Achtung: das gilt nicht fuer $we.
Zitatdann hätte aber das Wiki noch nie gestimmt.
Das ist nicht tragisch, im Zweifel zaehlt die englische Version der commandref.
Steht direkt vorne in etlichen Wiki Artikeln :)