[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

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

#1
Könnte so aus schauen


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

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

nils_

Zitat von: Beta-User am 15 März 2019, 13:13:56
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".
viele Wege in FHEM es gibt!

Beta-User

@CoolTux

Danke!

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

ReplaceEventMap( $h2we, [ $h2we, ReadingsVal($h2we,'holiday_today',0) // ReadingsVal($h2we,'state',0) ], 0 );
Zitat von: nils_ am 15 März 2019, 13:52:37
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?  :)
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

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
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

CoolTux

Zitat von: Wuppi68 am 15 März 2019, 14:00:45
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  :)
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

CoolTux

Zitat von: Beta-User am 15 März 2019, 13:57:35
@CoolTux

Danke!

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

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

Kann ich mir erst heute Abend in Ruhe anschauen.
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

Wuppi68

Zitat von: CoolTux am 15 März 2019, 14:15:38
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
Jetzt auf nem I3 und primär Homematic - kein Support für cfg Editierer

Support heißt nicht wenn die Frau zu Ihrem Mann sagt: Geh mal bitte zum Frauenarzt, ich habe Bauchschmerzen

nils_

#8
beitrag/code entfernt, weil ungetestet......
viele Wege in FHEM es gibt!

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



@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 8) .
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

nils_

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



viele Wege in FHEM es gibt!

Beta-User

Zitat von: nils_ am 15 März 2019, 17:01:41
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...
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

nils_

#12
Zitat von: Beta-User am 15 März 2019, 17:17:35
- erstens schreibt man es fairerweise dazu, dass es ungetesteter code ist...
sorry hab ich ehrlich vergessen. hab den code entfernt.

Zitat von: Beta-User am 15 März 2019, 17:17:35
- 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...

Zitat von: Beta-User am 15 März 2019, 17:17:35
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)

Zitat von: Beta-User am 15 März 2019, 17:17:35
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!

Zitat von: Beta-User am 15 März 2019, 17:17:35
In diesem Forenbereich ist also volle Ernsthaftigkeit gefragt, ....
mmmmh, scheint mir zu fehlen.

Zitat von: Beta-User am 15 März 2019, 17:17:35
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.
viele Wege in FHEM es gibt!

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

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.