Ankündigung+Testversion: Überarbeitung WeekdayTimer

[Wardancer]

Hi,

leider war da sonst nix ... hier mal der Auszug aus dem Log mit dem Eintrag vor dem umsetzen der Topics:

Code Auswählen Erweitern

2021.01.13 14:50:24 2: ROOMMATE set rr_Susanne home
2021.01.13 15:33:09 3: [HCKWZ2] set HCKWZ2 weekprofile heatingprofile:default:Wohnzimmer
2021.01.13 15:33:09 3: [HCGWC] set HCGWC weekprofile heatingprofile:default:GästeWC
2021.01.13 15:33:09 3: [HCFLU] set HCFLU weekprofile heatingprofile:default:Flur
2021.01.13 15:33:09 3: [HCBZ] set HCBZ weekprofile heatingprofile:default:Babyzimmer
2021.01.13 15:33:09 3: [HCKUC] set HCKUC weekprofile heatingprofile:default:Küche
2021.01.13 15:33:10 3: [HCKWZ1] set HCKWZ1 weekprofile heatingprofile:default:Wohnzimmer
2021.01.13 15:33:10 3: [HCTZ] set HCTZ weekprofile heatingprofile:Waltraud:Turmzimmer
2021.01.13 15:33:10 3: [HCBHT] set HCBHT weekprofile heatingprofile:default:Bad
2021.01.13 15:33:10 3: [HCAZ] set HCAZ weekprofile heatingprofile:default:Arbeitszimmer
2021.01.13 15:33:10 3: [HCB2] set HCB2 weekprofile heatingprofile:Waltraud:Bad2
2021.01.13 15:33:10 3: [HCB] set HCB weekprofile heatingprofile:default:Bad
2021.01.13 15:33:14 3: [HCKWZ2] set HCKWZ2 weekprofile heatingprofile:default:Wohnzimmer
2021.01.13 15:33:14 3: [HCGWC] set HCGWC weekprofile heatingprofile:default:GästeWC
2021.01.13 15:33:14 3: [HCFLU] set HCFLU weekprofile heatingprofile:default:Flur
2021.01.13 15:33:15 3: [HCBZ] set HCBZ weekprofile heatingprofile:default:Babyzimmer
2021.01.13 15:33:15 3: [HCKUC] set HCKUC weekprofile heatingprofile:default:Küche
2021.01.13 15:33:15 3: [HCKWZ1] set HCKWZ1 weekprofile heatingprofile:default:Wohnzimmer
2021.01.13 15:33:15 3: [HCTZ] set HCTZ weekprofile heatingprofile:default:Turmzimmer
2021.01.13 15:33:15 3: [HCBHT] set HCBHT weekprofile heatingprofile:default:Bad
2021.01.13 15:33:15 3: [HCAZ] set HCAZ weekprofile heatingprofile:default:Arbeitszimmer
2021.01.13 15:33:15 3: [HCB2] set HCB2 weekprofile heatingprofile:default:Bad2
2021.01.13 15:33:15 3: [HCB] set HCB weekprofile heatingprofile:default:Bad
2021.01.13 15:33:21 0: [HCTZ] profile heatingprofile:default:Turmzimmer, item 32 seems to be somehow damaged or incomlete!
2021.01.13 15:33:21 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1150.
2021.01.13 15:33:21 1: PERL WARNING: Use of uninitialized value in concatenation (.) or string at ./FHEM/98_WeekdayTimer.pm line 1318.
2021.01.13 15:33:21 1: ERROR evaluating my $EVENT=   $evalSpecials->{'%EVENT'};my $NAME=   $evalSpecials->{'%NAME'};{ my $days={};map{$days->{$_}=1}() ;; ( (ReadingsVal("Heizung_HC1MQTT","ProgramChooseSwitch","") ne "Sommer") && ) }: syntax error at (eval 241525) line 1, near "&& ) "

Can't use an undefined value as an ARRAY reference at ./FHEM/98_WeekdayTimer.pm line 1314.
Das ganze ging auch ziemlich fix ... vielleicht war es ein Timing Problem?
OS ist auf einem Raspi 3 ein Buster mit Kernel 5.4.79 ... also Zielich aktuell ..
Perl v5.28.1 ich denke auch recht aktuell...

[Beta-User]

Na ja, da steht auf alle Fälle, dass WDT ein Problem mit dem Profil hatte:

Code Auswählen Erweitern

seems to be somehow damaged or incomlete
Und in dem zugehörigen Kommentar findet sich

Code Auswählen Erweitern

#prevent FHEM crashing when profile is somehow damaged or incomlete, forum #109164Scheinbar war der dortige Fix also nicht vollständig, oder es ist zwischendurch was passiert. Da kein Fensterkontakt oä. angegeben ist, kann es eigentlich auch kein "hängender Timer" mehr gewesen sein.

Wie hattest du den JSON erstellt? Der ist andersrum als der default (was eigentlich egal ist, zumindest hier auf meinem Testsystem). Ist da evtl. irgendein verborgenes Zeichen drin, das hier bei der Übertragung dann weg ist?

(Aber selbst wenn, das muss ich irgendwie abfangen).

[Wardancer]

Ich hatte alles über die Webgui gemacht...
Daher war mein erster Reflex auch, dass weekprofil das kaput erstellt hat. Aber sieht ja alles soweit okay aus.
Ich krieg es halt im Moment auch nicht wieder reproduziert. Sehr blöd!

[Beta-User]

Hmm, irgendwie schon blöd, aber eigentlich auch beruhigend...

Denn: Das ist m.E. nichts, was wirklich mit der aktuellen Überarbeitung zu tun hat, sondern - soweit ich das im Moment überblicken kann - eher irgendein zufälliges Zusammentreffen von unglücklichen Umständen, das auch anderen passieren könnte.

Ich habe mal ein paar fixes eingebaut, um scheinbar (?) korrupte Profile besser abfangen zu können, und es gibt dann auch ein counter-Reading, aus dem man erkennen kann, ob bzw. wie oft sowas passiert (erscheint nur dann, wenn es passiert!).

Wie immer wären Tests willkommen...

[Wardancer]

Habs mal eingespielt.
Also ich glaube auch nicht, dass es hier an der ganz neuen Version liegt.
Ich hab ja quasi direkt nach dem Einspielen mit der Umstellung auf weekprofile begonnen. Witzigerweise wurden die Topics auch in den beiden Tagen zu vor mehrfach immer mal wieder vor und zurück getauscht. Aber halt in größeren (normalen) zeitlichen Abständen.
Mal schauen ob die zusätzlichen Logausgaben Licht ins dunkle bringen, falls es wieder auftritt.

[Beta-User]

An sich dürfte nach meinem Verständnis die "Geschwindigkeit" keine Rolle spielen.
FHEM arbeitet streng linear (single-threaded), wenn man nicht absichtlich was anderes macht (fork), von daher war anscheinend die Rückgabe von weekprofile einfach kaputt, warum auch immer (könnte auch ein Lesefehler von der Karte gewesen sein, oder sonst eine externe Ursache).

Jedenfalls hat WDT ja sogar gemerkt, dass was nicht stimmt (=>log-Eintrag, jetzt auch sichtbarer Zähler), allerdings dann trotzdem versucht rauszufinden, ob der nicht vorhandene Timer ein gültiger Timer ist. Das letztere sollte (!) jetzt auch an den beiden Stellen, wo das noch Folgewirkungen haben könnte "erkannt" werden und der "Timer" dann (durch die veränderten direkten Rückgaben) als "heute ungültig" verworfen werden. Da das nur in Ausnahmefällen vorkommen kann, bin ich mal gespannt, wie lange es dauert, bis da jemand nachfragt, woher dieses ominöse Reading kommt.... Erst dann wissen wir, ob die jetzt eingebauten Sicherungen funktionieren oder ob es doch irgendein "feature" in WDT ist, die korrekten Profile gelegentlich nicht richtig auszuwerten .

[Mitch]

Ich habe mal eine Frage zu disable.
Wurde glaube ich schon vor langer Zeit mal darüber geschrieben.

Wenn ich disable 0 und 1 nutze kommt ja immer das ?, weil es eine Änderung an der cfg gibt.
Kann man das ändern?
Wäre schön ein temporäres disable nutzen zu können.

[amenomade]

"set ... disable" statt "attr ... disable 1"

Und es gibt auch den Parameter "condition"

[Mitch]

Condition is klar, nutze ich auch.

Aber ein set <device> disable macht bei mir ein attr <device> disable 1 und somit habe ich eine ungesicherte Änderung.
Enable genau das gleiche.

[amenomade]

Ok, diese Besonderheit von WDT wusste ich nicht.

Als Workaround kannst Du immer ein reading mit "setreading" setzen, und dieses Reading in der "condition" mit einbauen.

[Mitch]

Jein, geht schon aber es muss dann immer auch ein Update gemacht werden.

[Beta-User]

Ich habe mal eine Frage zu disable.
Wurde glaube ich schon vor langer Zeit mal darüber geschrieben.

Wenn ich disable 0 und 1 nutze kommt ja immer das ?, weil es eine Änderung an der cfg gibt.
Kann man das ändern?

Na ja, soweit ich das beurteilen kann, stammt das ursprüngliche Verhalten noch aus einer Zeit, als man allg.  temporäte Änderungen an der cfg nicht als "kritisch" angesehen hat.
Ich fand das auch nicht optimal, aber eine bessere - rückwärtskompatible! - Lösung ist mir bisher auch nicht eingefallen, eigentlich bin ich ganz zufrieden, jetzt mit der Möglichkeit der jederzeitigen Re-Initiatilisierung eine Option dafür im Angebot zu haben und mit weekprofile/Topic-Wechsel auch eine Variante, mit der man zumindest Heizungsgeräte einfacher verwalten kann...

Für Code-Vorschläge bin ich offen, werde diesen Teilaspekt aber von meiner Seite nicht aktiv bearbeiten.


@all: Die "Sicherheitsgurte" für "kaputte" Profile sind eingecheckt.

[Mitch]

Verstehe ich.

Vielleicht gibt es für meinen Usecase ja eine andere Möglichkeit.
Was ich mache/machen will: wenn die Harmony meldet, es wird geschaut, geht die Heizung um 1 Grad hoch und der Heizplan über den WeedkayTimer wird pausiert/gedisbaled.
Wenn die Activity beendet ist, wird der Heizplan wieder aktiviert und die Temperatur daraus gesetzt/upgedated.

[juemuc]

Hi Mitch,

ich habe hierfür ein notify, welches dann ein "save" absetzt.

Viele Grüße
Jürgen

[Mitch]

ja, hatte ich auch früher, ab save geht ja nicht mehr per notify/DOIF. Oder hat sich da was geändert?

Ich habe einen Workarround über ein Dummy-Fenster, welches ich dazu auf Open setzte, dann schaltet WDT ja auch nicht.