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

[Beta-User]

Hallo Rudi,
hallo zusammen,

nachdem ich gestern über eine kleine Falle im Zusammenhang mit holiday2we gestolpert bin (s.u.):

1. Wäre es nicht sinnvoll, zentral eine Funktion bereitzustellen, die ein konsistentes Ergebnis hinsichtlich der Variable $we liefert, an der Modulautoren andocken können?

Wünschenswert wäre eine wahr/falsch-Rückgabe analog isday() bei Sunrise_EL.

Soweit ich den Code verstanden habe, kommt $we aus den Zeilen 1109ff@fhem.pl.

Spräche außer ggf. einer kleinen Performanceeinbuße etwas dagegen, das in eine separate sub auszulagern?

2. Weiter ist es an einigen Stellen (z.B. bei der Berechnung von timern für den morgigen Tag) hilfreich zu wissen, ob morgen $we wahr ist.
Abhilfe könnte eine "baugleiche" sub schaffen oder der Aufruf von "iswe()" mit einem optionalen "tomorrow". Mindestens zwei Module nutzen sowas schon bei separater Codepflege.

3. Über $we bin ich "gestolpert", als ich es mir einfach machen wollte und das entsprechende holiday-Device der Einfachheit halber auf meiner Startpage angezeigt habe. Irgendwann habe ich es netter anzusehen gefunden, über stateFormat auch state und tomorrow anzuzeigen. Leider habe ich das gemacht, ohne mir den Quellcode in fhem.pl näher anzuschauen...
Ergo wäre meine weitere Anregung, zukünftig tatsächlich den "state" zu nutzen und nicht "STATE", könnte sonst sein, dass noch mehr sich wundern, warum ihre Rollladen-Funktionen seltsame Timerangaben enthalten usw..

In dem Zusammenhang gäbe es dann ggf. Inkonsistenzen, so dass die Autoren der anderen Module ggf. entweder wieder den code aus fhem.pl kopieren würden oder eben direkt die Funktion nutzen können.

4. Da zwischenzeitlich mehr Leute erkannt haben, dass man mehrere holiday-Devices in holiday2we reinschreiben kann: vielleicht könnte man das in dem Zuge so erweitern, dass erst geschaut wird, ob ein Reading mit Namen "today" (oder "holiday_today") vorhanden ist und wenn, dann das statt "state" verwenden? Für "tomorrow" ggf. dasselbe (wenn der "holiday_"-Präfix allg. für sinnvoll gehalten wird)?
Habe das noch nicht vollständig durchdacht, aber an sich wäre es z.B. dann recht einfach, einem Calendar oder Anwesenheits-dummy ein entsprechendes Reading zu verpassen, ohne die erforderliche Info auf weitere Geräte zu verteilen. In den state zu schreiben wäre bei anderen Devices aber eventuell ein Problem, daher der Vorschlag zur Erweiterung der abzuprüfenden Readings.

Ich hoffe, das einigermaßen nachvollziehbar dargestellt zu haben und kann mich auch gerne an einem patch dazu versuchen (wenn gewünscht).
Und bitte seht mir nach, wenn ich bei den Vorschlägen irgendeinen grundlegenden architektonischen Aspekt nicht bedacht haben sollte, ich beschäftige mich nur hobbymäßig mit Perl...

Gruß, Beta-User

[CoolTux]

Könnte so aus schauen

Code Auswählen Erweitern


sub IsWe() {
    my ( undef, undef, undef, undef, undef, undef, $wday, undef, undef ) =
      localtime( gettimeofday() );
    my $we = ( ( $wday == 0 || $wday == 6 ) ? 1 : 0 );

    if ( !$we ) {
        foreach my $h2we ( split( ',', AttrVal( 'global', 'holiday2we', '' ) ) )
        {
            my ( $a, $b ) =
              ReplaceEventMap( $h2we, [ $h2we, ReadingsVal($h2we,'state',0) ], 0 );
            $we = 1 if ( $b && $b ne 'none' );
        }
    }
    return $we;
}

sub IsWeTomorrow() {
    my ( undef, undef, undef, undef, undef, undef, $wday, undef, undef ) =
      localtime( gettimeofday() );
    my $we = (
        ( ( ( $wday + 1 == 7 ? 0 : $wday + 1 ) ) == 0 || ( $wday + 1 ) == 6 )
        ? 1
        : 0
    );

    if ( !$we ) {
        foreach my $h2we ( split( ',', AttrVal( 'global', 'holiday2we', '' ) ) )
        {
            my ( $a, $b ) = ReplaceEventMap( $h2we,
                [ $h2we, ReadingsVal( $h2we, 'tomorrow', 0 ) ], 0 );
            $we = 1 if ( $b && $b ne 'none"');
        }
    }
    return $we;
}



Beim Codereview in der fhem.pl ist mir gerade was aufgefallen

Code Auswählen Erweitern


1108   my $hms = sprintf("%02d:%02d:%02d", $hour, $min, $sec);


das $hms wird in der Routine in welches es definiert wurde nie verwendet. Auch nicht in einer Rückgabe oder durch schreiben in eine globale Array oder Hash Referenz.


Grüße

[nils_]

vielleicht könnte man das in dem Zuge so erweitern, dass erst geschaut wird, ob ein Reading mit Namen "today" (oder "holiday_today") vorhanden ist und wenn, dann das statt "state" verwenden? Für "tomorrow" ggf. dasselbe (wenn der "holiday_"-Präfix allg. für sinnvoll gehalten wird)?
Habe das noch nicht vollständig durchdacht, aber an sich wäre es z.B. dann recht einfach, einem Calendar oder Anwesenheits-dummy ein entsprechendes Reading zu verpassen, ohne die erforderliche Info auf weitere Geräte zu verteilen. In den state zu schreiben wäre bei anderen Devices aber eventuell ein Problem, daher der Vorschlag zur Erweiterung der abzuprüfenden Readings.

den teil finde ich gut. ein dummy an sich tut ja nicht weh, aber so könnte man es am entsprechenden device "verwalten".

[Beta-User]

@CoolTux

Danke!

Vielleicht magst du noch testen, ob das hier auch funktioniert, wenn du die Zeile jeweils erweiterst (hier für "today"):

Code Auswählen Erweitern

ReplaceEventMap( $h2we, [ $h2we, ReadingsVal($h2we,'holiday_today',0) // ReadingsVal($h2we,'state',0) ], 0 );

den teil finde ich gut. ein dummy an sich tut ja nicht weh, aber so könnte man es am entsprechenden device "verwalten".

Yup, geht nicht um's wehtun, sondern um's nicht "umpacken" müssen. Das würde (hoffentlich) das obige machen: Schau nach, ob's das erste gibt (defined), wenn nicht, nimm das andere..

@CoolTux: kommt dir das bekannt vor? 

[Wuppi68]

ich finde die Idee gut

Hätte da einen möglichen anderen Ansatz:

wäre es nicht am elegantesten wenn $IsWe() mit optionalen Parametern gefüttert werden kann?

$IsWe()
$IsWe('TOMORROW')
$IsWe('31-02-2097')

nur eine Idee

[CoolTux]

ich finde die Idee gut

Hätte da einen möglichen anderen Ansatz:

wäre es nicht am elegantesten wenn $IsWe() mit optionalen Parametern gefüttert werden kann?

$IsWe()
$IsWe('TOMORROW')
$IsWe('31-02-2097')

nur eine Idee

Das letzte finde ich persönlich zur Steuerung jetzt nicht so wichtig. Meiner Steuerung interessiert es nicht was in 3 Jahren oder Ende des Monats ist. Es interessiert heute und morgen. Also zu mindest meine Steuerung 

[CoolTux]

@CoolTux

Danke!

Vielleicht magst du noch testen, ob das hier auch funktioniert, wenn du die Zeile jeweils erweiterst (hier für "today"):

Code Auswählen Erweitern

ReplaceEventMap( $h2we, [ $h2we, ReadingsVal($h2we,'holiday_today',0) // ReadingsVal($h2we,'state',0) ], 0 );

Kann ich mir erst heute Abend in Ruhe anschauen.

[Wuppi68]

Das letzte finde ich persönlich zur Steuerung jetzt nicht so wichtig. Meiner Steuerung interessiert es nicht was in 3 Jahren oder Ende des Monats ist. Es interessiert heute und morgen. Also zu mindest meine Steuerung 

ich hätte aktuell auch keine Verwendung für Kann mir aber vorstellen dass es dort bestimmt ein paar Fälle schon heute gibt und wer weiß was morgen los ist

[nils_]

beitrag/code entfernt, weil ungetestet......

[Beta-User]

Wow, soviel Interesse, cool .

Was das mit dem optionalen Parmeter für iswe() angeht, war das ja auch mal ein Gedankengang im Ausganspost. Wäre halt eine Prüfung voab mehr, was bei der Menge an vermuteten Aufrufen der Funktion vielleicht tatsächlich Einfluß auf die Performance haben könnte? (Müßte jemand klären, der mehr Ahnung als ich hat...)

Aber die zweite Funktion könnte man m.E. als "Sowieso-Sonderfall" vielleicht tatsächlich so gestalten, dass nicht nach tomorrow (default) geschaut wird, sondern ggf. nach jedem beliebigen Tag (wer's braucht; mir soll's recht sein...).
Müßte man halt erst errechnen, was die Differenz an Tagen ist usw. und das dann auch anders benennen, "willbewe()".

Aber kommt jetzt bitte keiner mit gestern oder 34 b.c. .


@nils_

Das ist nicht ganz so trivial, weil das ganze im Modulkontext funktionieren muß, auch unterschiedliche Readings herangezogen werden müssen, (heute- und morgen-Fall), dann sollte es abwärtskompatibel sein (also state/tomorrow von holiday-Devices gelesen werden!) und zu guter letzt gibt 0+0 immer noch 0...

(auch wenn ich das mit dem  $wday + 1 ) ) == 0 grade auch nicht nachvollziehbar finde )

Aber Cooltux code id Fassung mit dem alternativen Reading testen wäre nett, du brauchst dazu nur einen dummy mit den richtigen Readings in holiday2we .

[nils_]

ok.... das war vorhin nur auf die schnelle zusammengeschustert....
und auch ungetestet, weil keine umgebung hier

[Beta-User]

ok.... das war vorhin nur auf die schnelle zusammengeschustert....
und auch ungetestet, weil keine umgebung hier

Sowas mache ich gelegentlich auch, geht auch oft genug schief, aber folgende Anmerkungen möchte ich dazu loswerden:

- erstens schreibt man es fairerweise dazu, dass es ungetesteter code ist...
- Wichtiger: Mein Anliegen ist es, dass der zuständige Maintainer eine nachvollziehbare Darstellung und ggf. Hilfe in Form lauffähiger patches bekommt.

CoolTux Code dazu kenne ich so halbwegs, da habe ich zufällig mitgewirkt, genauer: CoolTux angestiftet, das aus fhem.pl zu borgen und für den Tag vorher zu erweitern, nur war ich damals leider nicht in der Lage, meine Bedenken gegen Doppelcode soweit in "Perl"-Form zu bringen, dass man das hätte umsetzen können...

Wenn jetzt jeder "irgendwas" liefert, ist es am Ende unübersichtilich => kontraproduktiv. Und du wolltest das doch durchaus auch (in Teilen) haben, oder? In diesem Forenbereich ist also volle Ernsthaftigkeit gefragt, und ich habe einige Zeit mit mir gerungen, bis ich hier überhaupt was schreibe. Meine eigenen Kenntnisse sind da nämlich nach wie vor eigentlich zu dünn, auch wenn ich hin und wieder einen Treffer lande.

Ist nicht böse gemeint, nur zum drüber nachdenken...

[nils_]

- erstens schreibt man es fairerweise dazu, dass es ungetesteter code ist...

sorry hab ich ehrlich vergessen. hab den code entfernt.

- Wichtiger: Mein Anliegen ist es, dass der zuständige Maintainer eine nachvollziehbare Darstellung und ggf. Hilfe in Form lauffähiger patches bekommt.

das wäre nicht das problem gewesen, aber sei es drum...

CoolTux Code dazu kenne ich so halbwegs, da habe ich zufällig mitgewirkt, genauer: CoolTux angestiftet, das aus fhem.pl zu borgen und für den Tag vorher zu erweitern, nur war ich damals leider nicht in der Lage, meine Bedenken gegen Doppelcode soweit in "Perl"-Form zu bringen, dass man das hätte umsetzen können...

sehr löblich. aber doppel-code steht in dem vorschlag von cooltux. ich will das in keinster weise kritisieren, denn ich wäre auf diese lösung nicht im entferntesten gekommen. dafür kenne ich die fhem funktionen/internas  wenig bis gar nicht.
ich wollte nur einen _vorschlag_ machen, wie man die beiden subs zusammenfassen könnte. (mit meinem bescheidenen perl-wissen)

Wenn jetzt jeder "irgendwas" liefert, ist es am Ende unübersichtilich => kontraproduktiv. Und du wolltest das doch durchaus auch (in Teilen) haben, oder?

meine lieferung gibt es nun nicht mehr.... ja wollte ich haben. we und we-tomorrow direkt am device zu verwalten finde ich gut!

In diesem Forenbereich ist also volle Ernsthaftigkeit gefragt, ....

mmmmh, scheint mir zu fehlen.

Ist nicht böse gemeint, nur zum drüber nachdenken...

hab ich!

und um das nicht weiter in die länge zu ziehen, wars das erstmal hier von mir.....
//edit: falls es weiterhilft kann ich gerne meine beiträge aus diesem thread entfernen, nur sind dann die dann die quotes/kommentare aus dem zusammenhang gerissen.

[CoolTux]

nils hat aber Recht. Mein Code ist wirklich doppelt. Er hat mich damit angeregt einmal darüber nach zu denken es besser machen. im Grunde sollte für tomorrow eine kleine wrapper Funktion auf IsWe() genügen.
Ich schaue einmal.

[rudolfkoenig]

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

[Beta-User]

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

[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

Code Auswählen Erweitern


$we = (
        ( ( ( $wday + 1 == 7 ? 0 : $wday + 1 ) ) == 0 || ( $wday + 1 ) == 6 )
        ? 1
        : 0
    );


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

[rudolfkoenig]

Habe IsWe() implementiert und eingecheckt. Aus dem Commandref:

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

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.

[betateilchen]

$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

[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!!!

[Benni]

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

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

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

[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?

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.

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

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

Ich habe die Doku ergaenzt:

Note: since March 2019 the IsWe() function (and $we) are accessing the state, tomorrow and yesterday readings, and not the STATE internal.

[Beta-User]

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!

[Benni]

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! 

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

[rudolfkoenig]

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?

Habs eingebaut, damit man pruefen kann, ob $we an einem bestimmten Tag auch richtig gesetzt sein wird.
Bin trotzdem etwas ungluecklich, weil die Aenderung nach meinem Geschmack zu gross ist fuer so eine zentrale Funktion.

[Loredo]

Auch wenn es häufig mühsam sein mag, finde ich persönlich die Weiterentwicklung zentraler Logiken (und die Beibehaltung der Kompabilität) besonders wichtig (siehe die Vordiskussion zu IsWe()). Wenn du schreibst "sondern generiert daraus das Reading "DayType"", dann verursacht das bei mir ein nicht näher spezifiziertes Unbehagen... (Es impliziert, dass man mit sonstigen Logiken dann besser dort andockt.)Wir können gerne (auch mit Rudi) darüber diskutieren, ob es Sinn macht, im Rahmen von h2we ein (!) bestimmtes Reading (vorgelagert zu state, aber bei allen in h2we angegebenen Devices identisch (!)) bei anderen als .holiday-Devices abzufragen, wenn das Sinn macht, aber das weiter aufzufächern, finde ich auf den ersten Blick nicht sooo prickelnd. Bin aber weder ein guter Programmierer, noch habe ich Erfahrung mit Softwarearchitektur, kann also sein, dass mein ungutes Bauchgefühl da völlig täuscht.

DaySchedule ist bei weitem nicht das erste Modul, welches aus einem IsWe() einen Readingwert generiert.
Das global Device hat laut Rudis Definition keinerlei Readings und ich glaube holiday2we hat schon eine recht lange Historie. Mittlerweile favorisiert Rudi ja glaube ich immer, dass man möglichst ein separates Modul schreibt statt zentrale Funktionen einzubauen. Ein gutes Beispiel ist das allowed Modul, ich glaube zu der Zeit hat Rudi begonnen das etwas stärker zu forcieren.
Ich persönlich denke, dass DaySchedule durchaus das Modul sein kann, in welches die holiday2we Logik ausgeweitet werden könnte (zumindest erscheint es mir vom Scope des Moduls her passend). Ich überlege mal, wie eine entsprechende Wrapper Funktion aussehen könnte.


Rudi hatte oben ja mit der letzten Änderung schon Bauchweh geäußert. Es ist also unwahrscheinlich, dass für IsWe() so etwas wie die Unterstützung von DaySchedule und Mehrsprachigkeit kommt, sowas gehört einfach in ein eigenes Modul. Vielleicht kann man aber IsWe() und $we so  mit einbeziehen, dass man ein einzelnes DaySchedule Device optional so markieren kann, dass es als Lieferant für IsWe() und $we dient. Womöglich geht das auch ohne Änderung am fhem.pl Code, ich schaue mal.

[Beta-User]

Ein paar Anmerkungen zu dem DaySchedule-Thema:

- Es geht nicht darum, dass IsWe() genutzt wird, um einen Readingwert zu generieren. Das geschieht an vielen Stellen in einigen Modulen. Das Bereitstellen von IsWe() dient nach meinem Verständnis dazu, es beliebigen Modulen zu ermöglichen, die Frage zu klären, ob jetzt für die FHEM-Instanz $we wahr oder falsch ist, und zwar für die Tage gestern, heute und morgen. Ziel ist Konsistenz zu dieser Frage in FHEM.

- Meine Erwartungshaltung an ein Modul, das es ggf. dem Anwender ermöglichen soll, auf die Frage "$we?" Einfluß zu nehmen, wäre dementsprechend die, dass es sich "rückwärts" so an IsWe() andockt, dass diese Einstellung (z.B. in DaySchedule) auch allen anderen Modulen bekannt gemacht werden _kann_, die IsWe() abfragen, und man als User nicht darauf angewiesen ist, plötzlich seine ganzen Logiken umzustellen, weil es jetzt eine "bessere" Infoquelle gibt. (Ist schon klar, dass man das mit einem Eventhandler usw. auch "zu Fuß" hinbekäme, einen Dummy "zu füttern"; es geht um die aus Anwendersicht "organische" Einbindung in das Gesamtsystem).

- Generell: MMn. sollte FHEM als Basissystem weiter mit recht wenigen Modulen konfiguriert werden _können_, sonst wird der Einstieg noch viel schwieriger, als er heute vermeintlich schon ist. Die wenigsten haben "vom Start weg" eine konkrete Vorstellung, welche (Logik-) Module sie irgendwann mal einsetzen werden, und sich direkt mit der vollen Bewohner/Kalender-Steuerung zu befassen, erscheint schwierig, bevor man sich nicht ein Grundverständnis erarbeitet hat. (Ab da ist dann auch klar, dass es eventuell doch eine individualisierte Betrachtung der Frage geben _kann_ oder sogar geben muß, ob jetzt $we ist oder nicht. Das ist aber eine Sache, die viele eventuell dann nicht mehr so genau interessiert).

- Der o.g. Konsistenzgedanke steht auch hinter dem Vorschlag, rückwärts ein "holiday"-Device exportieren zu können.

- Ergänzend: Ein Export als .holiday ermöglicht dann nicht nur "IsWe()-Konsistenz, sondern bietet eine gewisse Sprachen-Variabilität. Das zwar nicht als echte Mehrsprachigkeit, aber wenn die Sprache vor dem Export berücksichtigt wird, kann man ja zumindest den Rückgabewert einer holiday-Abfrage beeinflussen. (Dass das bei "mehrsprachigen Haushalten" immer noch nicht optimal ist, ist klar, ebenso, dass es evtl. für die eigentliche Anzeige besser ist, Calendar (oder ggf. dein Modul) zu nutzen...)

Sind nur meine Gedanken dazu, wie gesagt: Ich versuche das eher aus der Anwender/Einsteiger-Perspektive zu sehen. Dass man als Modulentwickler ggf. ganz andere Vorstellungen hat, ist auch ok.

[Loredo]

Es wird ja niemand gezwungen DaySchedule zu verwenden, es ist ein Zusatzangebot.
Ich glaube mangels Konsensfähigkeit und den Erfahrungen aus der Vergangenheit wirst du keinen Idealzustand herbeiführen können.

[Loredo]

Womöglich geht das auch ohne Änderung am fhem.pl Code, ich schaue mal.

DaySchedule hat jetzt einen global-Mode, bei dem es sich zwischen die globale IsWe() Funktion schaltet, wenn es mit "define name DaySchedule global" definiert wurde. Löscht man das Device, greift wieder die ursprüngliche Funktion aus fhem.pl alleine.
Damit erhält man ein konsistentes Verhalten zwischen dem Reading "DayType" und der Ausgabe von IsWe().
Wenn man .holiday-Dateien verwendet, muss man allerdings auf die gleichzeitige Mehrsprachigkeit verzichten (also wie bisher auch). Wenn man auf Kalender Devices setzt, gibt es keinerlei Beschränkungen.


Wenn DaySchedule global agiert, dann kann man IsWe() auch im Array-Kontext abfragen ("my ($index, $long, $short, $symbol) = IsWe()") und erhält dann ein Array mit den ausgeschriebenen Werten und eine genauere Unterscheidung, ob der Tag tatsächlich ein Wochenende ist oder "nur" ein Feiertag. Diese Unterscheidung kann IsWe() bisher nicht. Außerdem ist eine Abgrenzung zwischen Arbeitstagen und freien Wochentagen möglich.

- Der o.g. Konsistenzgedanke steht auch hinter dem Vorschlag, rückwärts ein "holiday"-Device exportieren zu können.

- Ergänzend: Ein Export als .holiday ermöglicht dann nicht nur "IsWe()-Konsistenz, sondern bietet eine gewisse Sprachen-Variabilität. Das zwar nicht als echte Mehrsprachigkeit, aber wenn die Sprache vor dem Export berücksichtigt wird, kann man ja zumindest den Rückgabewert einer holiday-Abfrage beeinflussen. (Dass das bei "mehrsprachigen Haushalten" immer noch nicht optimal ist, ist klar, ebenso, dass es evtl. für die eigentliche Anzeige besser ist, Calendar (oder ggf. dein Modul) zu nutzen...)

Das verstehe ich nicht, kannst du das näher erläutern? Warum sollte ich einen Export von etwas machen, was ich schon in einer  anderen .holiday Datei oder einem Kalender habe, den ich pflege? Ich hätte die Inhalte doch nur doppelt und eine .cal-Datei umzuwandeln in eine .holiday-Datei erscheint mir etwas, was das Calendar Modul bieten sollte, wenn man sowas braucht.

[Beta-User]

Hmmm,

ich will nicht behaupten, dass ich deine Antwort in der Tiefe verstehe, aber wenn sich das Modul nebenwirkungsfrei in die IsWe()-Abfrage einklinkt (was hoffentlich auch der Fall ist, wenn die Funktion von fhem.pl selbst aufgerufen wird mit AnalyzeCommand()&Co), dann klingt das für mich sehr nach Konsistenz  .

Und einen Export braucht man dann auch nicht anzubieten, weil es ja keine Differenz zwischen den unterschiedlichen Ebenen/Abfragemechanismen gibt. Das war nur ein Vorschlag, um eben über die vorgelagerten Daten Konsistenz zu erreichen, um den Preis der zugegebenermaßen doppelten Datenhaltung. (Eine ical2holiday-Funktion hatte ich mir im Sinne der genannten Konsistenz z.B. selbst mal geschrieben, um jeweils (u.a.) die aktuellen Feriendaten im "klassischen" holiday-Format zu haben (deswegen auch der Hinweis, dass es beliebig schwierig ist, die unterschiedlichen Varianten zu berücksichtigen, wie verschiedene User ical-Daten füllen und wie man das dann wieder seitens FHEM interpretiert). Da dein neues Modul die Interpretation bereits übernimmt (?), war die Annahme, dass der Export der _vorgefilterten/interpretierten_ Daten leichter ist als in Calendar direkt. Exportieren ist aber wie gesagt gar nicht mehr notwendig, wenn es stattdessen nachgelagert dasselbe Ergebnis gibt...)

Im Ergebnis: Danke, dass du dir die Zeit genommen hast, über den Einwand nachzudenken! Dass das Thema auch insoweit gelöst zu sein scheint, freut mich sehr, bin mal gespannt, wie viele das dann auch nutzen .



Leicht OT:
Ggf. müßte "man" (vermutlich ich) den WeekdayTimer dann nochmal ansehen: Der schaut (nach meinem evtl. unvollständigen Verständnis) immer 7 Tage in die Zukunft und wertet auch h2we-Daten direkt aus. Da war es bisher am einfachsten, vorgelagert die h2we-holiday-Dateien auszuwerten und erforderlichenfalls IsWe() nur für heute und morgen zu nutzen.
Das war (erzwungenermaßen) "schon immer" in der weiteren Vorausschau (ab übermorgen) nur teilweise richtig, es ergeben sich in der Zusammenschau insbesondere mit Calendar-gesteuerten Dummys aber ggf. Probleme, weil die Auswerte und Änderungszeitpunkte "falsch herum" sein können (WDT macht das immer um Mitternacht; wer also die Kalender=>Dummyfunktion (zufällig) etwas später aufruft, hat noch Urlaub... Muß mal über eine notify-fn hirnen, das Problem gibt's noch nicht so lange ...)

Wenn ein (vorhandenes/als global definiertes) DaySchedule da im Rahmen der Vorausschau irgendwie sinnvoll berücksichtigt werden kann, versuche ich mich gerne darin, auch ein insoweit konsistentes Ergebnis für WDT zu erzielen .

[Loredo]

Ja, es gibt einige Module, die an IsWe() vorbei direkt holiday2we auswerten:

- 95_DOIF.pm
- 98_DOIFtools.pm
- 98_WeekdayTimer.pm
- UConv.pm (ist obsolete, Code wurde in DaySchedule integriert und wird bald gelöscht)
- HOMESTATEtk.pm (ist obsolete, Code wurde in DaySchedule integriert und wird bald gelöscht)
- RESIDENTStk.pm (passe ich an)

Diese gehören so oder so entsprechend umstellt, da sie ansonsten auch mit allen anderen neuen Funktionen in IsWe() inkompatibel sind. Ist aber auch dem geschuldet, dass es seinerzeit nur $we gab und IsWe() als zentrale Funktion noch nicht existierte.
Um weiter als 1 Tag in die Zukunft zu schauen, braucht man aber seit IsWe() nichts eigenes mehr. Das ist wie gesagt ziemlich sicher alles noch aus alter Vorzeit.


Ich behaupte DaySchedule geht sehr vorsichtig mit Datumwechsel und DST um, aber genau hier erwarte ich mir auch mehr Tests von Dritten.

Edit: Genau an dieser Stelle war mir der 2 Sekunden Versatz aufgefallen, wenn man einen InternalTimer auf 00:00:00 stellt. Wahrscheinlich begegnest du dem selben Phänomen bei deiner Beobachtung.

[Beta-User]

Na, jedenfalls für WDT stimmt das nur zum Teil:
- Direkt nach der Bereitstellung von IsWe() kam eine Version ins svn, die für heute und morgen IsWe() nutzt ;
- für weekEnd und noWeekEnd gibt es seit So. (wenige Tage nach Erscheinen der aktualisierten fhem.pl!) hier eine Testversion:https://forum.fhem.de/index.php/topic,101899.0.html
Ergo: sollte von Userseite keine Fragen aufwerfen (unterstellt, ich bekomme auch noch sich ändernde Dummy...-Devices in den Griff, Vorschläge nehme ich gerne entgegen).

...es scheint sich nur keiner zu trauen, das zu testen (0 downloads bisher)... (Wenn jemand mit besseren Perl-Kenntnissen mal über die Änderungen drüberschauen könnte, wäre ich demjenigen sehr verbunden, ist nicht soooo viel, aber diese Art Funktionen und ihre Verschachtelungen? Bin mit sowas stark gefordert (der Hauptteil des Codes stammt bekanntlich von jemandem anderen) und habe einige Zeit gebraucht, bis ich den Eindruck hatte, das Ergebnis paßt... Mein FHEM läuft jedenfalls mit dem Code und ein paar WDT's soweit erkennbar problemlos, die machen aber seit ASC auch nichts mehr besonders "spürbares" am $we, und schichten tue ich auch nicht; (btw: evtl. wäre es aber eine Idee, holiday-Devices per Attribut zu den h2we-Geräten hinzufügbar zu machen?)).

Und was die beiden genannten weiteren Module angeht, werden die Maintainer da sicher einen Weg finden, wenn sie sich dazu entschließen...

[Loredo]

(Wenn jemand mit besseren Perl-Kenntnissen mal über die Änderungen drüberschauen könnte, wäre ich demjenigen sehr verbunden, ist nicht soooo viel

Es wäre leichter, wenn du auf Github ein Repository für den Delta Vergleich hättest.
Ich kenne allerdings WeekdayTimer überhaupt nicht.

(btw: evtl. wäre es aber eine Idee, holiday-Devices per Attribut zu den h2we-Geräten hinzufügbar zu machen?)).

Dafür gibt es bei DaySchedule eben mehrere Attribute, u.a. eines analog zu holiday2we, bei dem man aber neben holiday-Devices auch Calendar Devices verlinken kann. Ansonsten weiß ich aber wohl leider nicht, was du meinst.

[Beta-User]

Es wäre leichter, wenn du auf Github ein Repository für den Delta Vergleich hättest.
Ich kenne allerdings WeekdayTimer überhaupt nicht.

Danke für's Angebot. Das mit den Deltas mag halt jeder "ein wenig anders"...
Ich werde da sowieso vor dem Hintergrund der heutigen Diskussion nochmal drübergehen und dann wohl erst heute/morgen IsWe() auswerten, und erst danach den allg. Durchlauf über die h2we-devices  machen. Wenn ich das fertig habe, schicke ich dir einen Link? Wenn's zu speziell ist, darfst du auch gerne nein sagen (für mich war's jedenfalls schwierig zu erkennen, wo der vorhandene Code eigentlich was macht...).

Dafür gibt es bei DaySchedule eben mehrere Attribute, u.a. eines analog zu holiday2we, bei dem man aber neben holiday-Devices auch Calendar Devices verlinken kann. Ansonsten weiß ich aber wohl leider nicht, was du meinst.

...Analog zu holiday2we, aber ohne Calendar (kann man ohne zusätzliche Info nicht einfach so verwenden), das war die Idee (einschl. weekEnd und noWeekEnd). Damit man z.B. für einen Raum, in dem ein schichtender Mitmensch lebt, die dortigen Rollläden "anders" als den Rest mit WeekdayTimer steuern kann (so man nicht ASC nehmen mag). Da geht aber auch schon heute manches mit den vorhandenen Attributen, mal schauen...

[Beta-User]

Danke für's Angebot. Das mit den Deltas mag halt jeder "ein wenig anders"...
[...] Wenn ich das fertig habe, schicke ich dir einen Link?

Wenn du also magst (oder sonst wer):
https://github.com/rejoe2/FHEM/commit/c2614b009b3708b76ac54c2686859139d8be77b1
Ist bislang nur kurz angetestet, es scheint aber zu passen, weitere Tests im Echtsystem mache ich vorauss. am WE ( ).

Edit: Genau an dieser Stelle war mir der 2 Sekunden Versatz aufgefallen, wenn man einen InternalTimer auf 00:00:00 stellt. Wahrscheinlich begegnest du dem selben Phänomen bei deiner Beobachtung.

Hab's nochmal im Code nachgesehen: Der WDT-Timer zur täglichen Neuberechnug macht das tatsächlich genau und (wohl damit andere Routinen bereits tendenziell durch sein können) absichtlich und schon immer 5 Sek. nach Mitternacht. Hat als mMn. nichts mit dieser Beobachtung zu tun (und an 2 Sek. wegen veränderter Tageslänge glaube ich nach wie vor nicht, das sind in unseren Breiten irgendwas um die 8 Minuten (würde mal unterstellen, das ist effektiv schwankend, da irgendeine Sinuskurve, jedenfalls wären mehrfach beobachte genaue 2 Sek. (mit denen man auf ca. 20 Min Delta-Tageslänge p.a. käme) schon ein extremer Zufall).

Damit man ggf. die Neuberechnung manuell bei Bedarf/Erneuerung einer heutigen h2we-Info starten kann, habe ich den vorhandenen "enable"-setter jetzt etwas aufgebohrt.


Was anderes:
Wenn _ein_ Modul "IsWe()" überschreibt, mag das noch angehen, aber wenn mehr Entwickler das als gutes Beispiel begreifen, _könnte_ das irgendwann Nebenwirkungen haben, deren Ursache dann schwer zu ergründen sein könnte (sagt mir mein evtl. nicht begründetes Bauchgefühl).

EDIT: Ich werde vermutlich trotzdem am WE mal die Testversion von Astro einspielen...

[Loredo]

Wenn _ein_ Modul "IsWe()" überschreibt, mag das noch angehen, aber wenn mehr Entwickler das als gutes Beispiel begreifen, _könnte_ das irgendwann Nebenwirkungen haben, deren Ursache dann schwer zu ergründen sein könnte (sagt mir mein evtl. nicht begründetes Bauchgefühl).

Dein Bauch ist aber wirklich was ganz besonderes 


Es ist natürlich keineswegs gedacht, dass noch irgendein anderes Modul die selbe Methode verwendet. Das soll auch nicht notwendig sein, denn diese Module sollen sich ja nur mit dem Wert befassen, den IsWe() liefert. Wenn es Bedarf gibt das Verhalten weiter zu verfeinern, sind das Erweiterungen für DaySchedule. Genau das ist ja der Sinn die Logik in ein Modul zu verlagern. Auf diese Weise sind wir aber flexibel genug keine bestehenden Installationen zu brechen.

Außerdem gibt es bei verbose=5 ein entsprechend verändertes Logging, es lässt sich also aufspüren.

EDIT: Ich werde vermutlich trotzdem am WE mal die Testversion von Astro einspielen...

Jetzt nur nichts durcheinander bringen: Astro kann isday(), sunrise(), sunset() etc ersetzen, DaySchedule kann nur IsWe() ersetzen.

[Beta-User]

  Auf meinen "Bauch" (auch) zu hören, hat sich für mich als recht effektive Methode rausgestellt, manchen Problemen aus dem Weg zu gehen . Dass das aber vor dem Hintergrund meiner sehr begrenzten Erfahrung kein verläßlicher Indikator für wirkliche Problem in einem Software-Umfeld ist, ist klar, und genau darauf wollte ich mit der flapsigen Wortwahl hinweisen...

Und dass Astro "ganz woanders" ansetzt, ist (auch mir) schon klar, und an sich finde ich die Methode nicht unbedingt verkehrt, zentrale Routinen "global" zu überschreiben (ohne jetzt die Feinheiten zu kennen, warum die ersetzende Funktion im Detail die "bessere" ist). Problematisch wird es nur dann, wenn es von mehreren Seiten kommt (weil jemand es "noch besser" kann, aber keine "Lust", das durch/nach Diskussion mit einem anderen Entwickler in die zentrale Codebasis zu bringen (das ist bitte nur leicht ironisch zu lesen...)).

Ist angedacht, derartige Überschreibungen irgendwo (auf einfache Weise) sichtbar zu machen? (Oder gibt es das schon, z.B. in einem list zu global?)

[Loredo]

Ist angedacht, derartige Überschreibungen irgendwo (auf einfache Weise) sichtbar zu machen? (Oder gibt es das schon, z.B. in einem list zu global?)

Wenn die anderen Routinen aktiv sind, gibt es ein entsprechend verändertes Logging bei verbose=5.
Wenn Astro oder DaySchedule im "global mode" laufen, gibt es dort das Internal SCOPE=global. In die Internals vom global Device möchte ich nur auf Rudis expliziten Wunsch schreiben, um dort solche Änderungen noch sichtbarer zu machen. Dann wäre allerdings auch zu überlegen, ob die Markierung, welches Gerät nun eine bestimmte zentrale Aufgabe übernommen hat, nicht auch programmatisch noch anders gekennzeichnet werden sollte. Astro und DaySchedule merken sich aktuell im Modul-Hash, welches Gerät im globalen Kontext angesprochen werden soll. Das kann man natürlich auch nach $modules{global}{<USECASE>} schreiben, dafür gibt es aber keine Absprache bisher.

[rudolfkoenig]

Wenn _ein_ Modul "IsWe()" überschreibt, mag das noch angehen, aber wenn mehr Entwickler das als gutes Beispiel begreifen, _könnte_ das irgendwann Nebenwirkungen haben, deren Ursache dann schwer zu ergründen sein könnte (sagt mir mein evtl. nicht begründetes Bauchgefühl).

Wenn mehrere Module IsWe ueberschreiben, dann haengt von der Definitionsreihenfolge der Instanzen ab, welche IsWe() gilt.
Selbst bei einem Modul ist es problematisch, wenn ein Benutzer Code mit IsWe() veroeffentlicht, die fhem.pl Version geaendert wird, oder auf IsWe zurueckfuehrbare Probleme gemeldet werden.
Das ist mW aktuell der Fall mit apptime, die zentrale fhem.pl Funktionen ueberschreibt.

[Beta-User]

Sehr aus der Hüfte:

- Evtl. wäre es beim Starten schon bei verbose=4 (oder 3) angebracht, das Überschreiben ins Log zu werfen (also da, wo es grade durch das Aufheben von strict als Warning mit höherem Level (?) unterdrückt wird, aber mit einem rein informativen Text wie "Info: Function redeclaration - IsWe() is now answered by DaySchedule")?
Ausgaben erst bei "5" könnte (an der Stelle) zu hoch sein, und man hätte die übliche Stelle (log), um eventuelle Fehler-/Irritationsquellen leichter zu lokalisieren, ohne den Hilfesuchenden mit (für diesen irritierenden) Fragen an "exotische" Stellen leiten zu müssen?

- Ob eine Info in global für "Sunrise_EL" angezeigt wäre, mag ich nicht so recht beurteilen. Wenn ich es recht verstehe, muß man das nicht extra aktiv schalten, das rückt es in die Nähe von global.
Grundsätzlich: Wenn man durch ein einfaches "list SCOPE=global" oä. an die Infos kommt, welche Module die Funktionen von fremden Modulen (absichtlich) überschreiben, ist das aber m.E. hinreichend, vielleicht ergänzt um weitere Infos, welche Funktionen betroffen sind (sonst muß man in den Modulcode, was dann sehr weit "unter dem Auto" ist, oder?).
Das müßte dann aber von allen Modulentwicklern beachtet werden, außerdem gehören so eine allgemeinen Vorgaben dann auch in die Doku (dev-module-intro), zusammen mit dem freundlichen Hinweis, dass man als Entwickler (später dann) mal nachfragen sollte, ob es Konflikte geben könnte, die man besser auf anderem Weg löst.

- Bitte seht es mir nach, wenn ich nix zu schreiben kann und mag, welche Absprachen ggf. dazu noch Sinn machen. Da muß evtl. auch insgesamt nochmal etwas länger drüber nachgedacht werden können (von denen, die die Auswirkungen usw. besser beurteilen können).

Wenn mehrere Module IsWe ueberschreiben, dann haengt von der Definitionsreihenfolge der Instanzen ab, welche IsWe() gilt.

...das war naheliegend...

Selbst bei einem Modul ist es problematisch, wenn ein Benutzer Code mit IsWe() veroeffentlicht, die fhem.pl Version geaendert wird, oder auf IsWe zurueckfuehrbare Probleme gemeldet werden.

Deswegen ist es m.E. wichtig, dann wenigstens relativ leicht rausfinden zu können, welche möglichen Verursacher überhaupt am Start sind. Für IsWe() ist das noch vergleichsweise einfach, da die Funktion an sich "simpel" ist und keinen großen Änderungen (mehr) unterworfen (zumindest geht mir grad die Phantasie dazu aus...).

Das ist mW aktuell der Fall mit apptime, die zentrale fhem.pl Funktionen ueberschreibt.

Sollte der Autor hier mitlesen: vielleicht im obigen Sinn (wenn "man" sich darauf verständigt hat, wie) dann entsprechende Infos bereitstellen.

[Beta-User]

Dazu wäre noch hinzuzufügen, dass DaySchedule im globalen Modus noch weitere Funktionen global (also für alle Module und auch für selbstgeschriebenen Perl Code) bereitstellt, die etwas genauer als IsWe() funktionieren:
[...]

Der Unterschied zwischen IsWe() und IsWeekend() ist dabei, dass IsWeekend() wirklich nur am Samstag und Sonntag eine 1 zurückliefert, IsWe() jedoch auch an Feiertagen, Urlaubstagen. Sprich, IsWe() wird nur an Arbeitstagen eine 0 liefern, an allen anderen Tagen eine 1, ganz gleich warum es kein Arbeitstag ist.

Sorry, wenn ich das hier aufgreife, (will wie gesagt den anderen Thread nicht "mitlesen") aber das stimmt so nicht ganz (ich habe auch etwas Nachhilfe gebraucht, bis ich das verstanden hatte):

Code Auswählen Erweitern

IsWe(;$$) { my ($when, $wday) = @_; ...
Gibt man für $wday was an ( > 8 ), bekommt man tatsächlich nur $we an Feiertagen, und mit dem globalen Umschalter weekEnd kann man das auch zur default-Verhaltensweise machen.
Und 0/6 für $we zu halten, berücksichtigt die überwiegenden hiesigen Gepflogenheiten, aber nicht abweichende religiöse Vorstellungen oder andere Kulturkreise...

[Loredo]

- Evtl. wäre es beim Starten schon bei verbose=4 (oder 3) angebracht, das Überschreiben ins Log zu werfen

Logeintrag hinzugefügt.

Grundsätzlich: Wenn man durch ein einfaches "list SCOPE=global" oä. an die Infos kommt, welche Module die Funktionen von fremden Modulen (absichtlich) überschreiben, ist das aber m.E. hinreichend, vielleicht ergänzt um weitere Infos, welche Funktionen betroffen sind (sonst muß man in den Modulcode, was dann sehr weit "unter dem Auto" ist, oder?).
Das müßte dann aber von allen Modulentwicklern beachtet werden, außerdem gehören so eine allgemeinen Vorgaben dann auch in die Doku (dev-module-intro), zusammen mit dem freundlichen Hinweis, dass man als Entwickler (später dann) mal nachfragen sollte, ob es Konflikte geben könnte, die man besser auf anderem Weg löst.

Können wir erstmal einen Schritt nach dem anderen machen, bitte? Denk nicht, ich habe sowas nicht auch schon bedacht.

Deswegen ist es m.E. wichtig, dann wenigstens relativ leicht rausfinden zu können, welche möglichen Verursacher überhaupt am Start sind. Für IsWe() ist das noch vergleichsweise einfach, da die Funktion an sich "simpel" ist und keinen großen Änderungen (mehr) unterworfen (zumindest geht mir grad die Phantasie dazu aus...).

Wie gesagt, ich halte das für einfach kommunizier- und erkennbar. Bitte nicht zu "deutsch" hier denken, die denken immer gerne es muss alles 100% so eintreten, wie man es vorhersieht, bevor man überhaupt was anfängt...    Ich mag das Wort "agile Entwicklung" nicht, aber genau das ist es, was ich hier tue.
Wenn es einen besseren Weg gibt oder gar einen direkteren, um älteren Code (wie bei SUNRISE_EL) bzw. dessen duplizierte Funktionalität zu erneuern - nur raus damit. Ich denke aber nicht, dass Rudi sich überreden lässt fhem.pl oder 99_SUNRISE_EL.pm so anzupassen, dass es mit Astro und DaySchedule (dann auch ohne Device bzw. nur optional) arbeitet.

Sollte der Autor hier mitlesen: vielleicht im obigen Sinn (wenn "man" sich darauf verständigt hat, wie) dann entsprechende Infos bereitstellen.

Schwerer, weil es kein Device gibt, es bleibt nur logging, was es derzeit nicht tut.
Soweit ich apptime verstehe, ist es da auch etwas rigoroser beim ersetzen der Funktionen. In Astro und DaySchedule bleiben aber die originalen Funktionen erhalten und werden nur umbenannt. Deshalb kann man das auch zur Laufzeit wieder zurücknehmen, indem man das Device löscht oder per defmod ändert.


Im Falle von DaySchedule wird die Originalfunktion ja sogar auch weiterhin verwendet, nur eben in einem größeren Kontext drum herum (remember, ich schrieb "dazwischen schalten").

Sorry, wenn ich das hier aufgreife, (will wie gesagt den anderen Thread nicht "mitlesen") aber das stimmt so nicht ganz (ich habe auch etwas Nachhilfe gebraucht, bis ich das verstanden hatte):

Code Auswählen Erweitern

IsWe(;$$) { my ($when, $wday) = @_; ...
Gibt man für $wday was an ( > 8 ), bekommt man tatsächlich nur $we an Feiertagen, und mit dem globalen Umschalter weekEnd kann man das auch zur default-Verhaltensweise machen.
Und 0/6 für $we zu halten, berücksichtigt die überwiegenden hiesigen Gepflogenheiten, aber nicht abweichende religiöse Vorstellungen oder andere Kulturkreise...

Die Cross-Posts gehen mir auf den Senkel. Irgendwie hast du von der Nachricht dort ja aber dann doch erfahren 


Danke aber für die Erläuterung, was man mit $wday macht. Ich bin nicht so richtig schlau daraus geworden, weshalb alle Abfragen, für die $wday gesetzt ist, auch direkt weiter von der Funktion in fhem.pl bearbeitet werden (wie gesagt, es wird ja nix überschrieben, nur umbenannt und dann auch weiter angesprochen). Deshalb funktioniert auch alles neue mit weekEnd und noWeekEnd, wenn man das denn verwenden möchte (ist IMHO nur notwendig, wenn man kein DaySchedule einsetzen möchte). Meine Aussage zu Samstag/Sonntag sollte deshalb nur beispielhaft zum Verständnis dienen, aber an der Logik von IsWe() ist wie gesagt an dieser Stelle nichts geändert.

[Beta-User]

Hallo Loredo,

vorab nochmal Danke, dass du meine Gedanken nachdenkenswert findest (z.B. mit dem Logeintrag).
Du darfst mir glauben, dass mir sehr klar ist, dass du insgesamt eine sehr viel breitere und tiefere Sicht auf praktisch alles hast, was wir hier diskutieren, und dabei insbesondere auch viele Dinge mit bedenkst, deren Existenz mir (vermutlich) auf immer verborgen sein wird. Von daher sieh' es mir bitte nach, dass ich manchmal vielleicht ungeschickt frage, nicht unbedingt zielführende Vorschläge mache oä..

Und wir diskutieren das hier im Entwickler-Board, von daher muß nicht alles schon "fertig" sein (wer mag, sollte sich aber ggf. frühzeitig entsprechend "einnorden" können). Daher: Gerne einen Schritt nach dem anderen, und auch die notwendige Zeit dafür nehmen .

Gerne auch zur Diskussion, bisher (v.a. vor dem leidigen Diesel-Thema) hatten die Menschen im In- und Ausland es durchaus zu schätzen gewußt, dass hier manches "solide" gemacht wird, und vielleicht hat das (von mir als solche empfunden) extrem stabile "Laufen" von FHEM auch was damit zu tun, dass zentrale Entwickler sehr konservativ waren, was Anpassungen anging.

Was das Cross-Posting anging, war das ursprünglich auch eine Bauentscheidung, bei der mir erst hinterher aufgegangen ist, um was es mir _auch_ ging:
Den Umgang mit dem Namespace... (ist doch der richtige Begriff, oder?)

Im ersten Post des Threads hier hatte ich ursprünglich mal zwei Funktionen vorgeschlagen, Rudi hat daraus eine gemacht (und das Ganze dann noch "garniert" mit der besagten Nebenfunktion, $wday, deren volle Tragweite ich vermutlich bis heute nicht ganz verstanden habe). Nachdem Rudi und ich neulich schon die Frage des "Namespace-Verbrauchs" (im Zusammenhang mit MQTT2-attrTemplates) mal angeschnitten hatten, kommt mir das (auch vor dem Hintergrund des "ins Gehege Kommens" von Funktionsaufrufen) immer mehr als sehr weitsichtig vor (ich selbst muß meine letzten WDT-Changes da auch nochmal ansehen, gelbe Karte!...), selbst wenn das zur Folge hat, dass die Funktion selbst nicht mehr "so einfach" benutzt werden kann oder "einleuchtend" benannt ist und ggf. sogar geringfügig mehr Ressourcen schluckt.
Unter dem Gesichtspunkt: Was spricht dagegen, aus den 4 angedachten Funktionen im main-Kontext eine zu machen und einen (weiteren?) Parameter zu nutzen, um festzulegen, auf was der Fragende eine Antwort bekommt?
Und was, (z.B. mit einem Präfix) deutlicher zu machen, aus welchem "Paket" die Funktion stammt?

Ansonsten: Ich werde versuchen, das mit den Crosspostings entweder zu lassen, oder mir mehr Mühe geben, mein Bauchgefühl zu analysieren, um es ggf. besser erklären zu können .


Danke auch, dass du dir die Zeit genommen hast, die Funktionsweise des Codes zum Ersetzen bzw. Einkapseln (?) des ursprünglichen Funktionaufrufs zu erläutern (auch im Unterschied zu apptime). Den Code hatte ich zwar kurz angesehen, aber für mich waren/sind das "böhmische Dörfer", die da stehen...

[Loredo]

Um das ganze programmatisch abfragbar zu machen, setzen Astro und DaySchedule jetzt folgende Variablen, während sie zentrale Funktionen ersetzen:

Code Auswählen Erweitern


        $data{redirectedMainFn}{'main::IsWe'}  = 'FHEM::DaySchedule::IsWe';
        $data{redirectedMainFn}{'main::sr_alt'} = 'FHEM::Astro::SUNRISE_EL';



Tatsächlich werden die Funktionen aber nicht ersetzt, sondern vorher umbenannt und stehen unter anderem Namen weiter bereit. Wenn man also weiß, warum man die alte Funktion doch einmal aufrufen will, kann man die neuen Namen der Funktionen über zwei weitere Einträge herausfinden:

Code Auswählen Erweitern


        $data{renamedFn}{'main::IsWe'}  = 'main::Main_IsWe';
        $data{renamedFn}{'main::sr_alt'} = 'main::Main_sr_alt';



Damit können andere Module zumindest programmatisch erkennen, dass dort etwas anders ist. Da die Funktionen ja die gleichen Parameter erwarten, um vollständig kompatibel zu sein, gibt es sonst keinen anderen Weg das zu erkennen, außer es zu wissen bzw. implizit über das SCOPE Internal zu ermitteln. Das fällt damit nun weg.

[rudolfkoenig]

Ich moechte betonen, dass ich das Ersetzen der fhem.pl Funktionen nicht gut finde, und werde bei Aenderungen keine Ruecksicht auf Nachahmer/Kopien nehmen, es reicht schon, dass ich zu der alten Version kompatibel bleibe. Wenn dieser Beispiel Mode macht, dann haben wir einen Support-Albtraum, weil je nach Reihenfolge der Modul-Initialisierung andere Funktionen verwendet werden.

Weiso wird den Leuten nicht nahegelegt, statt den altmodischen IsWe() den schicken DaySchedule::IsWe() zu verwenden?

[Loredo]

Na weil du es damit auf den User abschiebst, dass er nicht vergisst an allen Stellen die andere Routine aufzurufen.
Genauso brummst du anderen Modulautoren damit auf, dass sie extra Support für etwas einbauen müssen und der Benutzer muss wieder je Modul, welches er einsetzen möchte, entscheiden, woher nun die Daten kommen. Das hat mit Datenkonsistenz wenig zu tun.


Das ganze soll auch keine Einladung sein es mir nachzutun. Wenn jemand den Code (1-zu-1) klaut, dann sorgt die Logik im Code dafür, dass kein zweites Modul die gleiche Prozedur für die selbe Subroutine noch einmal machen kann. Marko habe ich vorgeschlagen die Subroutinen für das Redirecten einer Subroutine, wie ich es jetzt mal lieber nenne, in GPUtils.pm aufzunehmen. Ob man das als Einladung verstehen mag, oder nicht, sei dahingestellt. Zumindest hilft es klar zu dokumentieren, was passiert und dass nix doppelt passiert.


Aber um es klar zu sagen: Mein Favorit wäre eine Lösung einen Data Provider für etwas zentral angeben zu können. Nachdem du bei SUNRISE_EL/sr_alt aber dafür schon nicht offen warst denke ich nicht, dass du bei IsWe nun empfänglicher bist. Daher bleibt nichts als an fhem.pl vorbei an Lösungen zu suchen, da mir dort keine andere angeboten wird.
Wenn du dich hier bewegen könntest und konstruktiv mit überlegst, wie man das besser machen kann, dann bin ich absolut offen dafür.

[rudolfkoenig]

Ich habe jetzt sehr haeufig bis zehn gezaehlt, damit ich auf die vielen persoenlichen Schuldzuweisungen nicht eingehe.

Wenn du meinst, dass Bedarf fuer ein "Ist-denn-jetzt-Wochenende-Framework" existiert, dann erfinde und bewerbe bitte dein Eigenes, und kapere bitte nicht eine vorhandene Funktion.

[Loredo]

Ich nehme Abstand von der gefundenen Lösung. Es tut mir leid für Beta-User und andere, aber über das Gesamtsystem mit den selben Daten zu arbeiten ist somit nicht machbar. Mit Abweichungen muss man also leben bzw. den fehlenden Einstellungsmöglichkeiten.

[Beta-User]

[...] Es tut mir leid für Beta-User und andere, aber über das Gesamtsystem mit den selben Daten zu arbeiten ist somit nicht machbar. [...]

Hmm, also für mich muß dir das m.E. nicht leid tun, ich kann mit der zentralen IsWe() bislang jedenfalls gut leben.

Ist zwar hier leicht OT, aber dennoch eine Anmerkung zu dem Schluß von SUNRISE_EL auf IsWe():
Das irritiert mich sehr, ich empfinde das als nicht ausschließlich sachliches Argument, und wir sollten bitte (v.a.) solche Dinge gerade im Interesse der Konsistenz sachlich besprechen (da ich aber nicht den Sachverstand besitze, um das alles ohne einen für mich riesigen Aufwand mit "harten" Argumenten zu diskutieren, muß ich mich hier darauf beschränken, kurz meine Beobachtungen und Eindrücke zu schildern, die nicht richtig sein müssen):

Der Ablauf war nach meinem Eindruck dort so: Rudi hat konkret nachgefragt, welche Verbesserungen denn gewünscht sind und um Übermittlung eines Patches gebeten, damit er sich eine Meinung bilden kann. Jedenfalls soweit ich diesen Thread verfolgt hatte, kam dazu keine weitere Info, sondern die Rückmeldung, dass sich das ganze dann erledigt hat; scheint also nicht wichtig gewesen zu sein.

Was zentrale Fragen angeht, wäre meine Erwartung, dass man darüber ggf. Argumente austauscht und (vorrangig) im Rahmen der derzeitigen Lösungen versucht, für alle Seiten passende, wartbare und konsistente Lösungen zu finden, und ich gehe auch davon aus, dass diese Erwartung alle teilen, die hier mit diskutieren. Das ist im Fall von SUNRISE_EL - aus welchen Gründen auch immer - unterblieben. Im Prinzip ist das dort auch ok, es ist CoolTux Entscheidung, etwas weiter zu verfolgen oder eben auch nicht. Aber es ist eben m.E. daher kein Argument für das hiesigen IsWe().

Was jetzt wiederum IsWe() angeht, weiß ich, dass sich darüber "normale WE"-Tage abfragen lassen und auch "echte" Feiertage, was deckungsgleich wäre mit zwei der von dir für erforderlich gehaltenen Funktionen. Ob IsWe() noch mehr liefern kann und dann noch Bedarf für weitere Logikbausteine (die 3.+4. neue Funktion) besteht, kann ich im Moment nicht beurteilen.

Zusammengefaßt wäre nach meinem bisherigen Verständnis der Vorteil der "Umleitung" daher darauf beschränkt, z.B. auch ein Calendar-Device direkt mit einbeziehen zu können.

Dass das mit Calendar ohne Diskussion darüber nicht möglich ist, an welcher Stelle jetzt was zu ändern wäre, ist halt so. Ich für mich habe das Problem dadurch gelöst, dass ich mir den Calendar (bzw. bestimmte Elemente darin) immer mal wieder automatisch in ein holiday-file exportiere. Das mag nicht die cleverste Lösung sein, funktioniert aber, von daher braucht man mich dazu nicht bedauern.
Ob es für andere hilfreich wäre, kann man ja diskutieren, und vermutlich wäre dafür auch nur eine kleinere Anpassung von IsWe() erforderlich (anderes Reading vorrangig zu state berücksichtigen), sofern Calendar entsprechend "tickt" (und wer das nicht will, kann ja einen dummy füllen...). Oder wie immer bei FHEM: vieles denkbar...

Meine Bitte wäre, das Kind nicht mit dem Bade aus den falschen Gründen auszukippen und sich jeweils die Mühe zu machen zu erklären, warum man was für zielführend hält (bei solchen zentralen Funktionen) . Bisher haben "wir" doch meistens eine Lösung gefunden und dabei hin und wieder noch was gelernt.

(Zum Lernen, auch wieder in Teilen OT, aber evtl. interessant, weil da Aspekte drin sind, auf die man mit rein naturgesetzlicher Logik nicht kommt: Da gab es zu SUNRISE_EL mal einen Thread, aus dem hervorging, dass die Anhänger mancher religiösen Gruppen eben "exaktere" Werte für erforderlich halten als SUNRISE_EL sie grade liefert. Wenn sich da jetzt aber wieder verschiedene Meinungen entgegenstehen, dann "müssen" "wir" eben mit mehreren Funktionen leben, oder sunset() mit Argumenten so ergänzen, dass wir die jeweilige korrekte Rückmeldung dafür erhalten, wenn das evangelisch, griechisch-orthodox, jüdisch, sunnitisch .... berechnet werden soll . Mir persönlich sind die 6 Minuten, die ggf. dazwischen liegen ziemlich egal, aber ohne dass man die Argumente kennt, die Unterschiede offenlegt und die Ergebnisse verglicht, kann man keine sinnvolle Entscheidung dazu fällen, was denn jetzt "default" sein soll und welche Logik man benötigen würde, um das umzusetzen ).

[Loredo]

Ganz so kann ich das nicht stehen lassen. Es ist richtig, dass ich ganz sicher keinen Roman darüber geschrieben habe, was die Anwendungsfälle alle sein können. Jeder darf auch gerne selbst die Murmel ein wenig anstrengen und sich eine Vorstellung darüber machen. Ich habe auch früher schon betont: Ich selbst bin weder religiös noch möchte ich mir unterstellen lassen aus religiösen Gründen etwas zu wollen. Ich weiß also beim besten Willen nicht, wie man auf sowas kommen kann, davon war nie die Rede. Ich sagte ja schon, dass keine der genannten Funktionen über ein FHEM Device repräsentiert wird und man kaum Einstellungsmöglichkeiten für fest definierte Werte hat. Du selbst, lieber Beta-User, hast geschrieben, dass es dir darum geht, dass Werte übereinstimmen - ganz egal ob da nun 1 Sekunde oder 3 Minuten Unterschied bestehen. Es geht dabei ums Prinzip der Datenkonsistenz und dem habe ich dir absolut beigepflichtet - offenbar (m)ein großer Fehler.

Ich nehme für mich mit: Beta-User nicht allzu ernst nehmen und auf keinen Fall versuchen seine Wünsche im mutmaßlichen Sinne nachzuverfolgen. Das darf er gerne selbst tun.