IsWe

[Migul47]

Hallo,

IsWe() liefert heute 1, IsWe(today) liefert 0. Allgemeines Problem oder nur heute wegen Zeitumstellung und Feiertag?

[Nobbynews]

Beides liefert bei mir als Ergebnis "1".
Denkfehler bei mir.
Liefert ebenfalls "1" und "0".

[Beta-User]

Da müsste eine bareword-warning im log stehen. Pack today in Quotes...

[Migul47]

Da müsste eine bareword-warning im log stehen. Pack today in Quotes...

Steht auch in Anführungszeichen im Code drin.

[rudolfkoenig]

Vermutlich eine Folge von dem hier gemeldeten Problem: https://forum.fhem.de/index.php?topic=123808

[michaelw]

Also ich habe heute das gleiche Problem. IsWe() liefert 1, IsWe("today") oder IsWe("today",7) liefert mir 0 zurück. Habe zwei Holiday Devices bei holiday2we eingetragen. Das eine zeigt auch für heute korrekt den Eintrag aus der entsprechenden holiday-Datei an.
Sollte das Problem schon gefixt sein? Habe gerade ein Update durchgeführt, aber es bleibt bei diesen Werten

[Beta-User]

Kann ich so bestätigen.

Es ist (unterstellt, mein Code-Verstndnis ist korrekt) m.E. nicht glücklich gewählt, dass bei Vorgabe von "today" (anders als bei den anderen beiden) für _alle_ h2we-Devices vorausgesetzt wird, dass die ein "today"-Reading haben. Für diesen "today"-Fall (aber nur für diesen) wäre es m.E. erforderlich, im Falle von "undefined" auf "state" zu schauen. Die Logik dahinter wäre: Wer "today" angibt, hat die Chance, _auch_ "atypische Devices" mit einzubinden, muss dann aber dafür sorgen, dass "today" _in diesen Devices_ gefüllt wird, damit nicht auf "state" rekurriert wird.

Leider kann man sowas kaum noch jemandem erklären...
(Spontan würde ich für zurück zum alten Zustand votieren).

[rudolfkoenig]

@michaelw: falls ich etwas pruefen sol, dann brauche ich die Readings aller im holiday2we erwaehnten Instanzen.
@Beta-User: ich meine today verhaelt sich _exakt_ so wie yesterday und tomorrow. Was meinst du mit dem alten Zustand?

[Beta-User]

@Beta-User: ich meine today verhaelt sich _exakt_ so wie yesterday und tomorrow. Was meinst du mit dem alten Zustand?

Das Problem ist genau das, dass "today" sich genau verhält wie die beiden "Nebenreadings",
das aber auf die Nutzererwartung trifft, dass "holiday"-Devices "wüßten", dass "today" in "state" steht...

Mit "altem Zustand" ist daher gemeint, dass wenigstens "holiday"-TYPE-Devices die Anfrage korrekt (im Sinne der User-Erwartung) beantworten . Nur dann kann man sinnvoll zwischen "Calendar"-TYPE-Devices ("today" vorhanden) und "klassischen" h2we-Geräten mischen.

Ergo müßte es entweder ein (neues) "today"-Reading in holiday-Devices geben, oder der Code müßte schauen, ob "today" als Reading im einzelnen Device existiert und (nur) wenn nicht dann "state" berücksichtigen (also anders gesagt: "today" nur als erste Adresse betrachten, was  genau anders ist als bei den "Nebenreadings").

Da  das m.E. zu kompliziert ist, um es den Usern zu erklären, würde ich dazu neigen, einfach "today" wieder abzuschaffen (=alten Zustand wieder herstellen) und stattdessen eben die User auffordern, Geräte zu bauen, die die Infos passend liefern. That's all.

Klarer, was ich meine?

Nachtrag noch:
Falls du in Erwägung ziehst, bei "today" den Rückfall auf "state" zu vercoden, wäre es m.E. dann sinnvoll, den Abfragedefault ebenfalls direkt auf "today" zu machen, und nicht mehr auf "state" (und dieses keyword ggf. alternativ (als verstecktes feature) zu "yesterday" und "tomorrow" zuzulassen, um die Suche auf dieses Reading zu beschränken). Dann verhält sich das m.E. eher entsprechend der User-Erwartung, weil dann auch die Module (ASC, WeekdayTimer, DOIF (?)), die bisher "leer" angefragt haben dann ein entsprechendes Ergebnis erhalten...

[michaelw]

@rudolfkoenig:

So in Ordnung?

Code Auswählen Erweitern


Internals:
   FUUID      5f89e4b6-f33f-2ea3-2596-8bc33de621204294
   HOLIDAYFILE ./FHEM/mw.holiday
   NAME       mw
   NR         20
   READONLY   0
   STATE      none
   TRIGGERTIME 1636239602.202
   TYPE       holiday
   READINGS:
     2021-11-06 00:00:02   state           none
     2021-11-06 00:00:02   tomorrow        none
     2021-11-06 00:00:02   yesterday       Urlaub
Attributes:
   alias      Urlaub Michael
   devStateIcon {my $value=ReadingsVal("$name","state","none"); if ($state eq 'none') {'<div  style="font-size:12px;">Leider kein Urlaub.</div>';} else {'<div  style="font-size:12px;">'.$state.'</div>';}}
   group      Kalender
   icon       time_calendar
   room       Wohnung



Internals:
   FUUID      5f89e4b6-f33f-2ea3-cac5-7801b4e881cc4283
   HOLIDAYFILE ./FHEM/nw.holiday
   NAME       nw
   NR         19
   READONLY   0
   STATE      none
   TRIGGERTIME 1636239602.73585
   TYPE       holiday
   READINGS:
     2021-11-06 00:00:02   state           none
     2021-11-06 00:00:02   tomorrow        none
     2021-11-06 00:00:02   yesterday       none
Attributes:
   alias      Feiertage NRW
   devStateIcon {my $value=ReadingsVal("$name","state","none"); if ($state eq 'none') {'<div style="font-size:12px;">Heute ist kein Feiertag.</div>';} else {'<div  style="font-size:12px;">Heute ist '.$state.'.</div>';}}
   group      Kalender
   icon       time_calendar
   room       Wohnung


Code Auswählen Erweitern

Internals:
   FUUID      5f89e4b6-f33f-2ea3-cac5-7801b4e881cc4283
   HOLIDAYFILE ./FHEM/nw.holiday
   NAME       nw
   NR         19
   READONLY   0
   STATE      none
   TRIGGERTIME 1636239602.73585
   TYPE       holiday
   READINGS:
     2021-11-06 00:00:02   state           none
     2021-11-06 00:00:02   tomorrow        none
     2021-11-06 00:00:02   yesterday       none
Attributes:
   alias      Feiertage NRW
   devStateIcon {my $value=ReadingsVal("$name","state","none"); if ($state eq 'none') {'<div style="font-size:12px;">Heute ist kein Feiertag.</div>';} else {'<div  style="font-size:12px;">Heute ist '.$state.'.</div>';}}
   group      Kalender
   icon       time_calendar
   room       Wohnung

Das sind natürlich jetzt Daten von heute. Für yesterday wird bei mir auch die korrekte Ausgabe geliefert. Es klappt halt nich für den Eintrag, den ich in me.holiday definiert habe. Das ganze (IsWe("today",7)) hatte im letzten Winter noch vernünftig funktioniert. Ich weiß nicht seit wann es nicht mehr geht, da ich das für meine Heizungssteuerung verwende und die Sommer nicht getriggert wird.

[rudolfkoenig]

Ergo müßte es entweder ein (neues) "today"-Reading in holiday-Devices geben, oder der Code müßte schauen, ob "today" als Reading im einzelnen Device existiert und (nur) wenn nicht dann "state" berücksichtigen

Die erste Variante ist einfacher zu implementieren, und die Nebenwirkungen sind auch geringer: das habe ich jetzt gemacht.

@michaelw: dass diese Abfrage vor deinem Update funktioniert hat, ist Glueck, IsWe("vorvorgestern") haette das gleiche Ergebnis gebracht.
Mit der neuen Version von holiday.pm sollte es aber wieder funktionieren.

[michaelw]

Meinst du mit "neue Version", die Version, die ich gestern per Update geholt habe oder meinst du noch eine andere Version?

[Beta-User]

Wenn es erst vorhin eingecheckt wurde, kommt das mit dem morgigen update.

@Rudi: Der Vorschlag mit der komplexeren Umsetzung hatte auch die User im Blick, die bisher dummy aus Calendar gefüllt hatten (usw.)... Bei dieser Gruppe findet sich "today" auch in "state" - bin mal gespannt, wann der erste merkt, dass seine bisher "allgemein" empfohlene Lösung nicht mehr funktioniert .

[rudolfkoenig]

Bin nicht sicher, dass ich Dich folgen kann, aber ich finde die aktuelle Loesung weniger verwirrend.
Wenn man nach today/yesterday/tomorrow fragt, dann wird im entsprechenden Reading gesucht.
Wenn man es nicht spezifiziert, dann im state.
Und rueckwaertskompatibel sollte es auch sein.

[Beta-User]

...solange du nicht die Anregung des TE so interpretierst, dass $we (im AnalyzePerlCommand()-Umfeld) und IsWe() die Abfrage nach "today" zurückgeben, ist aus meiner Sicht alles gut .
Das scheint mir nur eben das zu sein, was hier eigentlich gewünscht war, wenn ich das richtig interpretiert hatte. Aber vermutlich habe ich das falsch reininterpretiert ...