Autor Thema: [gelöst] iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices  (Gelesen 4155 mal)

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
  • eigentlich eher user wie "developer"
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #15 am: 16 März 2019, 09:07:15 »
$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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22032
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #16 am: 16 März 2019, 10:12:21 »
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://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
  • eigentlich eher user wie "developer"
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #17 am: 16 März 2019, 11:41:47 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20868
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #18 am: 16 März 2019, 12:11:40 »
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.

Zitat
wä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.
Gefällt mir Gefällt mir x 2 Liste anzeigen

Offline betateilchen

  • Developer
  • Hero Member
  • ****
  • Beiträge: 16056
  • s/fhem\.cfg/configDB/g
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #19 am: 16 März 2019, 14:55:51 »
$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 :)
-----------------------
Unaufgeforderte Anfragen per email werden von mir nicht beantwortet. Dafür ist das Forum da.
-----------------------
Nächster Hamburg Stammtisch am 20.09.2019

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
  • eigentlich eher user wie "developer"
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #20 am: 16 März 2019, 15:07:47 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2074
  • FHEMinist
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #21 am: 21 März 2019, 05:28:31 »
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.

Online CoolTux

  • Developer
  • Hero Member
  • ****
  • Beiträge: 22032
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #22 am: 21 März 2019, 08:06:47 »
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://paypal.me/pools/c/8gULisr9BT
FHEM GitHub: https://github.com/fhem/
kein Support für cfg Editierer

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
  • eigentlich eher user wie "developer"
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #23 am: 21 März 2019, 08:40:35 »
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-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2074
  • FHEMinist
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #24 am: 21 März 2019, 08:41:59 »
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.


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.



Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20868
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #25 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.

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

Offline Beta-User

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7540
  • eigentlich eher user wie "developer"
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #26 am: 21 März 2019, 10:40:46 »
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!
« Letzte Änderung: 21 März 2019, 10:43:06 von Beta-User »
Server: HP-T620@Debian 10, aktuelles FHEM + ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN
svn:MySensors, WeekdayTimer, AttrTemplate => {mqtt2, mysensors, httpmod}

Offline Benni

  • Developer
  • Hero Member
  • ****
  • Beiträge: 2074
  • FHEMinist
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #27 am: 21 März 2019, 11:10:24 »
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)



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


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!  ;)

« Letzte Änderung: 21 März 2019, 11:15:25 von Benni »
Zustimmung Zustimmung x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 20868
Antw:iswe(), eventuell isweTomorrow() und holiday-ähnliche Devices
« Antwort #28 am: 27 Juni 2019, 08:15:34 »
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
Gefällt mir Gefällt mir x 1 Liste anzeigen

Offline Loredo

  • Developer
  • Hero Member
  • ****
  • Beiträge: 3644
  • ~ Challenging Innovation ~
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