$we und IsWe() liefert immer 1

Begonnen von Nighthawk, 01 Oktober 2021, 12:00:19

Vorheriges Thema - Nächstes Thema

Nighthawk

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


Beta-User

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).
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

Nighthawk

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

Beta-User

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, 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)\
}
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

Ich kenne Calendar nicht.
Was bedeutet "triggered"?
Wuerde es helfen, wenn IsWe neben none auf triggered prueft?

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

rudolfkoenig

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.

betateilchen

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
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

Beta-User

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.
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

betateilchen

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.
-----------------------
Formuliere die Aufgabe möglichst einfach und
setze die Lösung richtig um - dann wird es auch funktionieren.
-----------------------
Lesen gefährdet die Unwissenheit!

rudolfkoenig

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.

Nighthawk

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, 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

Migul47

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

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.


rudolfkoenig

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 :)