Hallo,
IsWe() liefert heute 1, IsWe(today) liefert 0. Allgemeines Problem oder nur heute wegen Zeitumstellung und Feiertag?
Beides liefert bei mir als Ergebnis "1".
Denkfehler bei mir.
Liefert ebenfalls "1" und "0".
Da müsste eine bareword-warning im log stehen. Pack today in Quotes...
Zitat von: Beta-User am 01 November 2021, 10:00:17
Da müsste eine bareword-warning im log stehen. Pack today in Quotes...
Steht auch in Anführungszeichen im Code drin.
Vermutlich eine Folge von dem hier gemeldeten Problem: https://forum.fhem.de/index.php?topic=123808
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
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).
@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?
Zitat von: rudolfkoenig am 05 November 2021, 19:40:15
@Beta-User: ich meine today verhaelt sich _exakt_ so wie yesterday und tomorrow. Was meinst du mit dem alten Zustand?
;D 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...
@rudolfkoenig:
So in Ordnung?
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
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.
ZitatErgo 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.
Meinst du mit "neue Version", die Version, die ich gestern per Update geholt habe oder meinst du noch eine andere Version?
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 ;) .
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.
...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 ;D .
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 ::) ...