Ankündigung+Testversion: Überarbeitung WeekdayTimer

Begonnen von Beta-User, 21 Mai 2020, 18:28:26

Vorheriges Thema - Nächstes Thema

Beta-User

Hallo zusammen,

nachdem die anderen von mir als Maintainer betreuten Module erst mal soweit durch sind, geht es mit dem WeekdayTimer weiter.

Anbei eine erste Testversion, die insbesondere manche Irritationen beseitigen sollte in den Fällen, in denen es die User zu gut gemeint hatten und "78" oder "$we,!$we" als "profile" angegeben hatten. Weiter sind einige weitere kleine (und hoffentlich auf programmiertechnisch größere) Verbesserungen eingeflossen, wie zwei "erlegte eval" und ein perlSyntaxCheck für die "delayedExecutionCond". Das sind leider sehr viele kleinere und (für mich) größere Umbauarbeiten gewesen, so dass es schwierig ist, das zu 100% durchzutesten, und fertig ist die Reise leider auch noch nicht.

Wie immer würde es mich freuen, wenn jemand mittesten würde, ansonsten: Es wird ggf. in näherer Zukunft eingecheckt, ebenso eventuelle weitere Schritte in diese Richtung, falls es nicht genug Freiwillige gibt. Wer also nicht mittesten will, sollte excludefromupdate nutzen... Entwarnung folgt dann zu gegebener Zeit.

Grüße,

Beta-User

Edit:
22.05.: aktualisierte Fassung mit etwas anderer Logik betr. IsHeating.
22.05. #2: aktualisierte Fassung mit "vollst. PBP-konformen eval".
22.12. erste package-Fassung incl. WDT_sendDelay und WDT_eventMap
02.01.21: bereinigte package-Fassung. Braucht unbedingt einen FHEM-restart!
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

juemuc

Hallo Beta-User,

mit dem neuen Modul erhalte ich bei einem "Schaltvorgang" folgende Log-Einträge:
2020.05.21 22:15:00 1: PERL WARNING: Use of uninitialized value $setModifier in string gt at ./FHEM/98_WeekdayTimer.pm line 1166.
2020.05.21 22:15:00 1: PERL WARNING: Use of uninitialized value $n in hash element at fhem.pl line 4483.
2020.05.21 22:15:01 1: PERL WARNING: Use of uninitialized value in hash element at fhem.pl line 1709.


und hier die Definition:
defmod Nachtlampe_WT WeekdayTimer FBDECT_FB_08761_0230141 de 1234560|22:15|on 12345|06:10|off 1234560|{sunrise_abs(0,"00:00","23:59")}|off
attr Nachtlampe_WT commandTemplate set $NAME  $EVENT
attr Nachtlampe_WT devStateStyle style="text-align:right"
attr Nachtlampe_WT disable 0
attr Nachtlampe_WT event-on-change-reading .*
attr Nachtlampe_WT group Schaltzeitpunkte
attr Nachtlampe_WT room Schaltzentrale,Statuszentrale


Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Hallo Jürgen,

vorab mal Danke fürs Testen!

"Eigentlich" ist der Teil rund um Zeile 1166 nicht verändert, es sollte also schon früher was ähnliches (vermutlich mit anderer Zeilennummer, aber immer mit $setModifier) im Log aufgetaucht sein?
Jedenfalls ist die aktuelle Fassung im ersten Post (v.a.) an der Stelle etwas modifiziert.

Die beiden anderen Meldungen bekomme ich nicht auf die Schnelle zu WDT gebrückt:
Zeile 4483 in fhem.pl gehört zu ReadingsNum(), und das benutzt WDT gar nicht (evtl. FB_DECT beim Schalten?), und Zeile 1709 zu CommandSave(). Da bin ich dann vollends ratlos, wo der Zusammenhang sein könnte (immer unterstellt, die Zeilennummern gehören zur aktuellen fhem.pl).
Aber evtl. hast du ja eine Idee?
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

Beta-User

Noch ein update im ersten Post.

Damit wäre das eigentliche Ziel vermutlich geschafft, die eval rauszuwerfen/bzw. zu entschärfen :) .
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

juemuc

Hallo Beta-User,

mit der aktuellen Version erhalte ich nun diese Meldungen:

Zitat2020.05.23 15:12:14 1: PERL WARNING: Argument "($element =~ tr/"//)" isn't numeric in modulus (%) at ./FHEM/98_WeekdayTimer.pm line 547.
2020.05.23 15:12:14 1: PERL WARNING: Argument "($element =~ tr/'//)" isn't numeric in modulus (%) at ./FHEM/98_WeekdayTimer.pm line 547.
2020.05.23 15:12:14 1: PERL WARNING: Argument "($element =~ tr/}//)" isn't numeric in subtraction (-) at ./FHEM/98_WeekdayTimer.pm line 561.
2020.05.23 15:12:14 1: PERL WARNING: Argument "($element =~ tr/{//)" isn't numeric in subtraction (-) at ./FHEM/98_WeekdayTimer.pm line 561.
2020.05.23 15:12:14 1: PERL WARNING: Argument "($element =~ tr/)//)" isn't numeric in subtraction (-) at ./FHEM/98_WeekdayTimer.pm line 561.
2020.05.23 15:12:14 1: PERL WARNING: Argument "($element =~ tr/(//)" isn't numeric in subtraction (-) at ./FHEM/98_WeekdayTimer.pm line 561.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Danke für die Rückmeldung.

Jetzt sollte es wirklich gefixt sein, vorher war da vermutlich doch noch ein ganz anderer Wurm drin...
Aus der Doku zu (u.a.) tr:
ZitatBecause the transliteration table is built at compile time, neither the SEARCHLIST nor the REPLACEMENTLIST are subjected to double quote interpolation.  That means that if you want to use variables, you must use an eval()
Da eval raus sollte, habe ich jetzt den Code "etwas mehr zu Fuß" umgestellt.

Fragen (mir spucken grade noch zwei Dinge im Kopf rum, weiß noch nicht, ob ich das angehen will/soll und wieviel Aufwand das ggf. wäre):
- Würde es Sinn machen, auch dem WDT ein "set ... inactive" zu spendieren?
- Heute bin ich über FILTER gestolpert (:FILTER=STATE!=$EVENT), siehe https://forum.fhem.de/index.php/topic,111436.msg1056799.html#msg1056799. Könnte man ggf. auch per Attribut automatisiert in den Command einbauen (?). Gibt es Meinungen dazu?
Server: HP-elitedesk@Debian 12, aktuelles FHEM@ConfigDB | CUL_HM (VCCU) | MQTT2: MiLight@ESP-GW, BT@OpenMQTTGw | MySensors: seriell, v.a. 2.3.1@RS485 | ZWave | ZigBee@deCONZ | SIGNALduino | MapleCUN | RHASSPY
svn: u.a MySensors, Weekday-&RandomTimer, Twilight,  div. attrTemplate-files

juemuc

Hallo Beta-User,

für Leute, die den Filter nutzen, würde es wohl Sinn machen. Ich nutze es nicht.
Was mich viel mehr stört ist der Statuswechsel obwohl disabled auf 1 steht.

Viele Grüße
Jürgen
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Hmm, mal schauen...

Also: das mit dem Statuswechsel müßte eigentlich "schon immer" so gewesen sein. Ergo dürfte es ein paar Leute geben, die das "irgendwie" in ihren Installationen berücksichtigen, was im Ergebnis bedeutet, dass es keine gute Idee ist, das Verhalten direkt zu ändern.

Was genau stört dich an dem Verhalten?
(Mich stört, dass die Timer im Hintergrund verwaltet werden und damit eine gewisse (geringe) unnötige Last erzeugt wird.)

Die Sache mit "inactive" könnte evtl. ein Ausweg sein, weil dann der state dauerhaft auf "inactive" bleiben sollte, bis man den WDT aktiviert. "Blöd" ist dabei nur, dass die Info "inactive" im Moment auch als Zwischenstatus genutzt wird, aber das ist zum einen noch nicht so lange so (=potentiell weniger Betroffene), und zum anderen ist das eigentlich nur eine Art "Übergangswert" ohne wirklichen Informationsgehalt für den User. Später könnte man dann ggf. feature-Level-abhängig auch das "disable"-Verhalten ändern...
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

juemuc

#8
Hallo Beta-User,

ich synchronisere den Status (currValue) meiner WT mit den dazugehörige Geräten (zur schöneren Anzeige). Anbei ein Beispiel. Der Rollo wird auf 50% gesetzt. Dann setze ich den Status von "ROLLO_WT" ebenfalls auf 50%. Wenn nun aber der WT um 20:00 Uhr den Rollo auf 0% setzen würde, dann geht der Status auf 0% obwohl der WT auf disabled steht. Ich bin hier der Meinung, dass sich ein Status bei  disabled nicht ändern darf (durch das Device).

Und ja das ist schon immer so  ::)

Ideal wäre, wenn in state oder in einem anderen Readings der Status "aktiv" bzw "inaktiv" stehen würde.

Viele Grüße
Jürgen

PS.: Die Meldungen sind jetzt weg  ;D
3x Sonos Play 1, 1x Sonos Arc + Sub, 1 Sonos-One, 1x Sonos Playbar
FB6690 + FB7490 mit 4x Dect 200 und 3 Dect-ULE-Thermostate,  raspberry3B+, HM Funkmodul HM-MOD-RPI-PCB, HM Klingelsensor HM-Sen-DB-PCB, HM (IP) Fensterkontakte und  Amazon Echo Dot,  piVCCU, pi OS (bookworm).

Beta-User

Zitat von: juemuc am 24 Mai 2020, 11:38:16
PS.: Die Meldungen sind jetzt weg  ;D
Danke für die Info.

Werde heute abend auch nochmal meine logs ansehen, ob da was kritisches zu sehen ist und dann vermutlich schon diese Version einchecken (evtl. nach etwas Kosmetik).

Wer also noch rechtzeitig "in Deckung gehen will": feel free ;D .

ZitatUnd ja das ist schon immer so  ::)

Ideal wäre, wenn in state oder in einem anderen Readings der Status "aktiv" bzw "inaktiv" stehen würde.
Na ja, dann werde ich das jetzt erst mal nicht ändern. Vielleicht meldet sich ja noch jemand zu "inactive", ich selber brauche das nicht und setze meine WDT auch in der Regel nicht auf "disable 1".

In jedem Fall: Vielen Dank für's Testen @juemuc!
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

Beta-User

Da zumindest bis dato keine Probleme gemeldet wurden, gebe ich mal vorsichtig Entwarnung...
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

Beta-User

#11
Hallo zusammen,

da ich neulich Bedarf hatte, etwas anderes im state zu haben als "open window", wenn die delayedExecutionCond zutrifft, gibt es an der Stelle mal wieder eine Testversion, die - wenn der Rückgabewert was anderes als undef/0 ist - entweder weiter "open window" anzeigt, wenn man sich brav an die commandref gehalten hat, und eine 1 (oder true) zurückgibt, oder eben das, was der Code der delayedExecutionCond zurückgibt...
Beispiel:
attr rr_Mann_Presence_Timer delayedExecutionCond {return "absent" if ReadingsVal("$NAME",'smartphone','absent') eq 'absent';; return "present" if ReadingsVal("$NAME",'smartphone','absent') eq 'present' and "$EVENT" eq 'absent' }

Da das "offene Fenster" auch eine Reminiszenz an die Zeiten ist, in denen das Modul als Heating_Control entwickelt wurde, an der Stelle nochmal die Ankündigung, dass der WDT-Code vermutlich in näherer Zukunft einer Überarbeitung unterzogen wird und danach Heating_Control nur noch funktionieren wird, wenn man eine "alte" Version (also im Prinzip dann die hier angehängte) verwendet. (An die 89+ User, die das lt Statistics noch im Einsatz haben: Dass es mAn. keinen Sinn macht, weiter an Heating_Control festzuhalten, sei an der Stelle nochmal angemerkt, bitte nutzt die einfach zu handhabende Umstellungsoption und macht eben aus den HC-Devices eine oder mehrere Gruppen von WeekdayTimern...).

Grüße, 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

Beta-User

Zitat von: Beta-User am 10 Oktober 2020, 13:57:31
an der Stelle nochmal die Ankündigung, dass der WDT-Code vermutlich in näherer Zukunft einer Überarbeitung unterzogen wird und danach Heating_Control nur noch funktionieren wird, wenn man eine "alte" Version [...] verwendet.

Die nähere Zukunft hat begonnen...

Im ersten Post findet ihr wieder eine Version zum Testen. Die ist jetzt tatsächlich inkompatibel mit Heating_Control, weil auf package umgestellt, so dass über den main-namespace nur noch die beiden explizit in der Doku erwähnten Perl-Funktionen aufgerufen werden können.

Das ganze ist noch nicht "schön", und manches will ich noch ändern.

Warum solltet ihr jetzt mittesten:
- erfahrungsgemäß ist das Leben bunter wie die Vorstellungskraft eines einzelnen Maintainers ::) . Manche Probleme kommen eben erst zum Vorschein, wenn bestimmte Konstellationen gegeben sind...
- Es gibt "news", die ggf. dem einen oder anderen das Leben erleichtern können bzw. Probleme vermeiden könnten...
-- WDT_sendDelay fügt zu den Schaltzeiten an das Device immer die betreffende Anzahl an Sekunden hinzu. Es gab zwar auf [Nötig?] WeekdayTimer und delays bei der Übertragung von Änderungen keine (!) Rückmeldung auf meine diesbezügliche Anfrage, aber nach meinen Erfahrungen mit ZWave-Rollladenaktoren und AutoShuttersControl und den ersten Praxiserfahrungen mit der Kombi weekprofile+WeekdayTimer+ZWave-Thermostat meine ich, das ist sinnvoll.
-- WDT_eventMap erlaubt es, _innerhalb des WeekdayTimer_ $EVENT "umzubiegen", um z.B. aus Temperaturvorgaben (weekprofile) dann "spezielle" Schaltanweisungen zu machen, wie sie insbesondere KNX zu benötigen scheint (es ginge wohl genauso mit ZWave, aber da ist der Bedarf wohl geringer).

Wie immer ist feedback willkommen :) .

Grüße, 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

ToKa

Hallo Beta-User,

das klingt super, da ich auch Z-Wave Thermostate im Einsatz habe. Die Verzögerung macht absolut Sinn, damit nicht zu viel gleichzeitiger Funkverkehr entsteht. Bislang habe ich mir damit beholfen jeden WDT mit "krummen" Uhrzeiten zu versehen, so dass diese alle nacheinander die Thermostate gesteuert haben.

Bzgl. der WDT_eventMap habe ich noch Fragen. Bedeutet das im Zusammenhang mit den Z-Wave Thermostaten z.B. dem Eurotronic Spirit, dass ich diesem auch ein "set tmHeating" oder "tmEnergySaveHeating" schicken kann? Dann könnte ich das doch mit weekprofile kombinieren, weil man dort ja nur Temperaturen hinterlegen kann - zumindest über die Weboberfläche, wenn ich es richtig verstanden habe. Über json hatte ich probiert und es ging auch ein String z.B. eco.

Planst Du da mit beiden Modulen noch eine "bessere" Integration bzw. weitere Features, die es erlauben nicht nur Temperaturen zu verwenden?

Beste Grüße
Torsten
RaspberryPi3 mit RaZberry2 und Conbee II
Fibaro: FGWPE/F-101 Switch & FIBARO System FGWPE/F Wall Plug Gen5, FGSD002 Smoke Sensor
EUROtronic: SPIRIT Wall Radiator Thermostat Valve Control
Shelly2.5 Rollladenaktoren
Zipato Bulb 2, Osram und InnrLight

Beta-User

Hi ToKa,

das mapping für ZWave sollte mit der im ersten Post angehängten Version ohne weiteres gehen:
attr <wdt> WDT_eventMap 18.0:tmEnergySaveHeating 22.0:tmHeating 19.0:desired-temp+17.0
sollte bewirken, dass eine 18.0 im Profil (das auch aus weekprofile kommen kann) dann effektiv ein
set $NAME tmEnergySaveHeating
zur (ggf. verzögerten...) Schaltzeit "raushaut" bzw. dann eben auf "19.0" reagiert mit einem
set $NAME desired-temp 17.0
Das hat den Vorteil, dass man einheitlich "normale" Temperaturlisten für alle möglichen Devices pflegen kann, egal, ob es jetzt CUL_HM, ... oder eben "ZWave via WDT"-Hardware ist und dann ggf. die "lokalen Besonderheiten" eben durch die Einstellung am Device selbst und/oder dem WDT eingehen kann...
Das direkte Editieren der JSON geht natürlich auch, ist aber m.E. in der laufenden Pflege umständlicher wie das Berücksichtigen von "speziellen Temperaturen".

Da weekprofile nicht meine Baustelle ist, habe ich da keine weiteren Pläne, was "nicht-Temperaturlisten" angeht, das wäre beim Maintainer Risiko einzukippen. Ich sehe das aber - vielleicht abgesehen von weiteren "heizungstypischen Keywords" wie etwa "eco" - auch eher als nicht vordringlich an.

Was aus meiner Sicht (neben der Finalisierung des WDT-Codes) noch offen ist, sind noch ein oder zwei Beispiele für weekprofile+MQTT2_DEVICE. Für die "China-zigbee2mqtt"-Dinger gibt es bereits Code (aber noch keine Rückmeldung, ob das funktioniert), und bei ebus scheint es keinen Bedarf zu geben, jedenfalls war es da bisher still...

Letzteres ist aber kein WDT-Thema, sondern eher eine Frage, wie man  Heizungsgeräte ggf. "hausweit" synchron halten kann.

Tendenziell glaube ich auch, dass es mit der WDT_eventMap nunmehr auch genug Möglichkeiten gibt, alles mögliche abzubilden, mehr Optionen sind am Ende vermutlich auch eher verwirrend wie hilfreich.

Wir werden sehen ;D .
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