[gelöst] iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices

Begonnen von Beta-User, 15 März 2019, 13:13:56

Vorheriges Thema - Nächstes Thema

Beta-User

Zitat von: rudolfkoenig am 15 März 2019, 21:29:02
$we und $hms sind fuer die Perl-Skripte, aus der Zeit, wo auch noch ein $value gab, was inzwischen durch Value abgeloest wurde, weil das Setzen fuer alle Instanzen zu teuer ist.

Ich baue morgen ein IsWe() rein, mit Parameter (default: state), und $we wird auf deprecated gesetzt.
Das Gleiche mit Hms() vs. $hms.
Danke für's Einbauen!
(auch wenn ich über das mit deprecated für diese Dinge noch nachdenken muß, das klingt danach, als würden dann viele scripte irgendwann nicht mehr funktionieren, was ich nicht so toll finde... Aber klar, der Aufruf via Perl-scribt kann nicht wissen, wenn der user jetzt plötzlich andere Readings heranziehen will; von daher macht es schon Sinn, darauf hinzuweisen, dass es einen Unterschied macht; alles nicht so einfach....)

Eine Frage dazu noch: bekommt ein Parameter "tomorrow" eine Sonderbehandlung? Also dass bei diesem (und nur bei diesem) auch der morgige Wochentag berücksichtigt wird (@Cooltux: Das war doch der Grund für den Doppelcode, oder?) oder muß man sich als Aufrufer zukünftig dann um die Wochentage immer selbst kümmern bzw. eine eigene tomorrow-Funktion bauen?

M.E. gibt es noch einen guten Grund, unterschiedliche Funktionsaufrufe zu haben: $we wird zur Laufzeit ausgewertet, berücksichtigt also alle Stände, wie sie grade sind. Das sollte immer stimmen (nur dass z.B. ein holiday sich halt idR. nur einmal am Tag selbst aktualisiert). Für morgen kann das anders sein...
Das sollte dem Aufrufer bewußt sein, dass es eben prinzipiell was anderes ist, ob für "jetzt" oder "irgendwann".

Wenn letzteres: Gibt es prinzipielle Einwände gegen das Einbauen einer solchen "morgen?" Funktion z.B. in 99_utils? Also: sprechen programmiertechnische Gründe dagegen, bei relativ statischen Sachen die Vorausschau zu nutzen, um timer zu setzen (ist etwas OT, schon klar, aber ich lerne da gerne auch noch dazu...).
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

CoolTux

Also noch ist ja nichts implementiert. Warten wir da erstmal ab was Rudi macht. Die pflege des Doppelcodes war in der Tat in meinen Augen einfacher damit ich garantiert für morgen raus bekomme ob Frei oder nicht. Daher auch

$we = (
        ( ( ( $wday + 1 == 7 ? 0 : $wday + 1 ) ) == 0 || ( $wday + 1 ) == 6 )
        ? 1
        : 0
    );
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Hmm,

beim weiteren Nachdenken über das ganze Thema:
Wenn wir sowieso da was grundlegend ändern, wäre es dann nicht sinnvoll, gleich eine weitere "Tageskategorie" einzuführen? Der "Samstag" ist bei uns in der Regel schon irgendwie $we, aber doch anders, als ein Sonn- oder Feiertag...
Ginge so in die Richtung: 0=unter der Woche, 1 ist Sonn-/Feiertag, 2 ist ein freier Tag, aber eben kein Sonntag, 3 ist der Tag vor einem Feiertag, 4 wäre Tag vor "Samstag". Mind. Fall 3 könnte man auch über ein tomorrow rausfinden?

Ist noch nicht zu Ende Gedacht, ich wollte das nur mal in den Raum werfen.

@CoolTux: nils_ hatte dahingehend recht, dass der Teil zu kompliziert gedacht ist: Nummerisch ist morgen $we, wenn heute Fr. oder Sa ist, also $wday ganz ohne rechnen 5 oder 6...
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

Habe IsWe() implementiert und eingecheckt. Aus dem Commandref:
Zitat$we wird mit IsWe() gesetzt, diese Funktion nimmt optional die Argumente "today", "yesterday" und "tomorrow". Achtung: alles andere wird als "today" interpretiert, ohne eine Fehlermeldung zu generieren.
Von meinem "deprecated" Vorhaben habe ich mich verabschiedet, da es dann konsequenterweise $sec, $min, $hour, etc auch jeweils zu eine Funktion umgebaut werden muesste.

Zitatwäre es dann nicht sinnvoll, gleich eine weitere "Tageskategorie" einzuführen?
Das wird mir zu kompliziert, ich will mit $we den (aus meiner Ansicht) Normallfall fuer die Mehrheit der FHEM Anwender abdecken.
Wer es anders braucht, darf selber eine Routine oder gar ein Modul bauen.

betateilchen

Zitat von: rudolfkoenig am 15 März 2019, 21:29:02
$we und $hms sind fuer die Perl-Skripte, aus der Zeit, wo auch noch ein $value gab, was inzwischen durch Value abgeloest wurde, weil das Setzen fuer alle Instanzen zu teuer ist.

Und nicht zu vergessen, zwischenzeitlich wurde zusätzlich auch noch ein $today eingebaut :)
-----------------------
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

Klingt gut!

Vielleicht eine Sache noch: Ich gehe mal davon aus, dass damit "weiter" für "today" ausschließlich "state" für die holiday-Devices maßgeblich ist. Das ist erst mal sehr gut so.

Was ich für 99_Utils jetzt noch vorschlagen würde, wäre eine "IsHoliday()"-Funktion, die ohne nummerische Prüfung (!) ein beliebiges Reading über alle holiday2we-Geräte abfragt?
Damit könnte jeder, der es braucht
a) feststellen, ob IsWe() nur deswegen true liefert, weil es nummerisch richtig ist (und damit "Samstage", "normale" Sonntage und "echte Feiertage" auseinanderhalten) oder
b) ergänzend weitere holiday-ähnliche Geräte einbinden, um "eigene Samstage" oder "eigene Feiertage mit anderem Readingnamen" abzufragen.

Selbst wenn es im Moment noch niemand direkt braucht, wäre das eine Sache, die verhindert, dass jeder hier wieder eigene Wege geht, der in die Richtung was benötigt... Und viel Code wäre es ja nicht.

Aber auch so schon: DANKE!!!
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

Benni

Zitat von: rudolfkoenig am 16 März 2019, 12:11:40
Habe IsWe() implementiert und eingecheckt.

Hallo Rudi,

Wenn ich es richtig sehe, nimmt IsWe() von den holiday-Devices, die im global-Device angegeben sind, jeweils das state-Reading, um den Feiertags-Vergleich zu machen. Bisher war es für $we aber so, dass dafür das Internal STATE vom holiday-Device verwendet wurde.
Bei mir ist in holyday2we nämlich kein holiday-Device angegeben, sondern ein von mir speziell modifizierter Dummy, der im STATE den "Feiertag" ausgibt, aber im state den aktuellen Tag liefert und der ist immer !='none', weshalb bei mir gerade dauerhaft Wochenende ist.
Das wäre grundsätzlich zwar schön, führt bei mir aber an einigen Stellen zu Fehlverhalten, so musste ich zum Beispiel heute morgen schon ins kalte Badezimmer.

Das "alte" Verhalten wird übrigens auch so vom Holiday-Modul impliziert (s. Commandref):

Zitat
If entries in the holiday file match the current day, then the STATE of this holiday instance displayed in the list command will be set to the corresponding values, else the state is set to the text none. Most probably you'll want to query this value in some perl script: see Value() in the perl section or the global attribute holiday2we.

Langer Rede kurzer Sinn, könntest du bitte das alte Verhalten wieder herstellen?

Danke dir!

Gruß Benni.

CoolTux

Hallo Benni,

Ich Frage dem Verständnis wegen, also bitte nicht provokativ verstehen. Aber wäre es nicht einfacher die Dummys an zu passen?
Warum ich frage, nun wenn Rudi umstellt kommt auf jeden Fall Beta-User und will es wieder anders rum, weil er seine Holiday Devices anders angelegt hat.
Wem gibt man nun also den Vorrang?


Grüße
Du musst nicht wissen wie es geht! Du musst nur wissen wo es steht, wie es geht.
Support me to buy new test hardware for development: https://www.paypal.com/paypalme/MOldenburg
My FHEM Git: https://git.cooltux.net/FHEM/
Das TuxNet Wiki:
https://www.cooltux.net

Beta-User

Ich "will" eigentlich nicht unbedingt irgendwas "anders" rum.

Mein Anliegen war, eine zentrale Stelle zu haben, die letztendlich modulübergreifend für ein einheitliches Verhalten des "Wochenendes" innerhalb FHEM sorgt.

Allerdings: Wenn ich Rudi richtig verstanden habe, sind manche Dinge eben noch so, weil sie in einer sehr alten Schicht von FHEM halt mal so definiert waren (value kleingeschrieben). Ob und wann es ggf. Sinn macht, das anzufassen, kann ich nicht beurteilen, ebensowenig, ob es dann besser wäre, $we zu lassen und stattdessen eben $WE oder $wenew zu schaffen oder für die betroffenen eine $weold bereitzustellen. Deswegen hatte ich die Frage eingangs auch offen gestellt, und ich hätte jetzt auch nicht das Problem damit, weiter auf stateFormat bei den holiday-Devices zu verzichten.

Im Kern _glaube_ ich, dass wir eine komplexere Methodik für das WE-Thema haben sollten, daher auch der Vorschlag mit "IsHoliday()" und der Hinweis auf Samstag. Wenn dann der Schluß aus Kompabilitätsgründen ist, neue Funktionen auf IsWe() zu verweisen, ist das für mich auch ok. Ob ich jetzt in Perl $we oder IsWe() abfrage, ist ziemlich egal.

Ein Aspekt dazu noch: bleibt $we unverändert, dürfte das bei den usern, die die Diskussion nicht kennen und ggf. eine neue Variable nicht wahrnehmen, dazu führen, dass ggf. sehr lange noch $we aus "alten" Beispielen kopiert wird. Das erscheint mir nicht optimal.

Aber wie gesagt: Ich hänge nicht an einer bestimmten Lösung...
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

Benni

Zitat von: CoolTux am 21 März 2019, 08:06:47
Ich Frage dem Verständnis wegen, also bitte nicht provokativ verstehen. Aber wäre es nicht einfacher die Dummys an zu passen?
Warum ich frage, nun wenn Rudi umstellt kommt auf jeden Fall Beta-User und will es wieder anders rum, weil er seine Holiday Devices anders angelegt hat.
Wem gibt man nun also den Vorrang?

Grundsätzlich sehe ich das so, dass das bisherige verhalten erhalten bleiben sollte und somit auch den Vorrang hat, schließlich ist es in der Commandref (beim Holiday-Modul) ja auch so dokumentiert.


Zitat von: Beta-User am 16 März 2019, 15:07:47
Vielleicht eine Sache noch: Ich gehe mal davon aus, dass damit "weiter" für "today" ausschließlich "state" für die holiday-Devices maßgeblich ist.

Beta-User geht ja auch nur davon aus, dass state maßgeblich ist und bisher war. Allerdings ist diese Annahme definitiv falsch!

Ich kann den Dummy auch nicht einfach modifizieren, da ich state im Dummy anders verwende, das würde bei mir größere Umbaumaßnahmen erfordern.

Gruß Benni.



rudolfkoenig

Ich finde die aktuelle Version deutlich sauberer als die alte Variante.
Ich wuerde das nur sehr ungern doppelten Hacks (dummy statt holiday, STATE leitet sich nicht vom state ab) opfern.

ZitatDas "alte" Verhalten wird übrigens auch so vom Holiday-Modul impliziert (s. Commandref):
Ich habe die Doku ergaenzt:
ZitatNote: since March 2019 the IsWe() function (and $we) are accessing the state, tomorrow and yesterday readings, and not the STATE internal.

Beta-User

#26
Einen Einwand vielleicht noch:

Die Änderung - so sinnvoll ggf. die Mehrheit die findet - kam recht schnell und befindet sich an zentraler Stelle. User, die die bisherige Doku sauber gelesen haben, jetzt auf "dann date halt nicht up" zu verweisen, ist nicht "F" im FHEM-Sinne.
Die Zahl dürfte zwar nicht besonders groß sein (2 Meldungen nach 4 update-Tagen!), aber der Umbau vorhandener Logik ist uU. keine Kleinigkeit.

Eine weitere Abfrage innerhalb von AnalyzeCommandChain einzubauen, ist auch nicht das gelbe vom Ei, aber evtl. übergangsweise "das kleinere Übel".

Wäre es ein gangbarer Weg, "global" vorübergehend (!) ein neues Attribut zu verpassen, das das alte $we-Verhalten bereitstellt?
Das ganze dann nach einer Übergangszeit (8-12 Wochen?) auf das neue Verhalten umschalten und das Attribut wieder beseitigen? (Featurelevel dürfte nicht passen, sonst auch gerne das), und wir könnten $motd nutzen, darauf hinzuweisen, dass das Umstellen via Attribut keine dauerhafte Lösung bietet...

@Benni:
Ich hatte "weiter" in Anführungszeichen gesetzt... Dass es vorher nicht state war, war schon klar, das sollte eigentlich aus dem Ausgangspost erkennbar sein.
Trotzdem sorry für diese Nebenwirkung!
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

Benni

#27
Zitat von: rudolfkoenig am 21 März 2019, 09:27:51
Ich finde die aktuelle Version deutlich sauberer als die alte Variante.
Ich wuerde das nur sehr ungern doppelten Hacks (dummy statt holiday, STATE leitet sich nicht vom state ab) opfern.
Ich habe die Doku ergaenzt:

Schade!  :-\
(Auf nichts ist verlass!)

Dann weiß ich jetzt wenigstens, was ich dieses Wochenende vor habe  ::)
(Auch wenn IsWe() und $we das nun anders ausweisen, ist das erst übermorgen)



Zitat von: Beta-User am 21 März 2019, 10:40:46
...
Die Zahl dürfte zwar nicht besonders groß sein (2 Meldungen nach 4 update-Tagen!),
...
Das ganze dann nach einer Übergangszeit (8-12 Wochen?)


Ich glaube du unterschätzt hier die Langzeitwirkungen, es gibt viele User, die deutlich größere Update-intervalle haben.


Zitat von: Beta-User am 21 März 2019, 10:40:46
Wäre es ein gangbarer Weg, "global" vorübergehend (!) ein neues Attribut zu verpassen, das das alte $we-Verhalten bereitstellt?

Nee, komm, dann lieber gleich in den sauren Apfel beissen!  ;)


rudolfkoenig

IsWe hat ab sofort eine spezielle Behandlung fuer Eintraege in der holiday2we Liste mit dem Namen weekEnd und noWeekEnd:
https://forum.fhem.de/index.php/topic,101789

Loredo

I like!

Wie wäre es, wenn man IsWe() auch mit einem YYYY-DD-MM Datum füttern könnte, jetzt wo 95_holiday das auch verarbeiten kann?
Bei mir lokal habe ich es entsprechend gepatcht und es funktioniert prima.
Hat meine Arbeit dir geholfen? ⟹ https://paypal.me/pools/c/8gDLrIWrG9

Maintainer:
FHEM-Docker Image, https://github.com/fhem, Astro(Co-Maintainer), ENIGMA2, GEOFANCY, GUEST, HP1000, Installer, LaMetric2, MSG, msgConfig, npmjs, PET, PHTV, Pushover, RESIDENTS, ROOMMATE, search, THINKINGCLEANER