[neues feature] WeekdayTimer mit weekprofile steuern

[Beta-User]

Hallo zusammen,

nachdem immer mal wieder gefragt wird, ob man nicht auch für FHEMWEB ein Eingabewidget für den WeekdayTimer basteln könnte, von meiner Seite die Gegenfrage, inwieweit Interesse besteht, für Heizungs-Devices das Modul "weekprofile" als Input-Option zu nutzen. (Selbst bin ich jedenfalls im Moment nicht in der Lage, was völlig freies auch für andere Schaltbefehle zu basteln, aber wer das außerhalb FTUI beisteuern mag: feel free).

Anbei eine Testversion, die als Schaltzeitpunkt (neben dem Üblichen) auch "weekprofile:<device-name>[:<profilname>][:<true>]" akzeptiert.

"weekprofile" wird als Schlüsselbegriff verwendet und muß so vorangestellt werden, dann kommt der Name des weekprofile-Devices, danach der (optionale) Profilname.

EDIT: erfolgt nun durch das Attribut "weekprofile"!

Ist kein Profilname angegeben, wird "default" verwendet, ist das letzte (optionale) Argument "true", wird das Sonntags-Profil für $we verwendet (also auch für Sa., wenn man nichts spezielles über holiday2we eingestellt hat; das überschreibt/ergänzt also ggf. auch die Angaben im Sat.-Profil).

Als erste Schaltzeit wird 00:10 Uhr verwendet, da der WDT erst selbst die eigene Tagesauswertung fahren muß, bevor anschließende Timer für den Tag gesetzt werden können.

Demnach wären z.B. folgende WDT-Definition möglich (die Sinnhaftigkeit der Befehlskombi sei mal dahingestellt):
defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 !$we|05:50|on-till:06\:00 $we|06:55|on 12:30|on !$we|14:06|on-till:14\:07 16:00|on 7|17:04|off 8|17:09|off \
weekprofile:wprof_test:neu_1:true\
{}

Code: [Auswählen]

defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 !$we|05:50|on-till:06\:00 $we|06:55|on 12:30|on !$we|14:06|on-till:14\:07 16:00|on 7|17:04|off 8|17:09|off \
weekprofile:wprof_test:true\
{}

Code: [Auswählen]

defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_testdefmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test::true

Code: [Auswählen]

defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test:trueTheoretisch können auch mehrere Profile kombiniert werden (bisher nicht getestet; EDIT: sinnvoll ist das vermutlich auch nicht!), da weekprofile seinerseits nur Temperaturprofile kann (aber die dann an diverse unterschiedliche Hardware verteilen), ist das ganze nur für Temperaturlisten tauglich.

Bei einer "kaputten" weekprofile-Angabe (z.B. das Device oder Profil existiert nicht) sind derzeit alle Timer weg.

Im Moment gibt es (außer der Änderung der DEF des WDT) noch keine Möglichkeit, dem WDT updates mitzuteilen, die man in weekprofile gemacht hat, aber das einzubauen dürfte bei entsprechendem Interesse kein Problem sein EDIT: erledigt (müßte aber sinnvollerweise auch von weekprofile aus angestoßen werden, also im dortigen Code ggf. ergänzt, was aber auch kein Problem sein dürfte).

Ich nutze das selbst (im Moment) noch nicht, (also weder den WDT zur Steuerung von Heizungs-Devices noch weekprofile) und kann daher nur bedingt was zur Praxistauglichkeit des Konzepts an sich sagen. Der Vorteil liegt m.E. darin, dass man damit eine zentrale Stelle für alle Arten von Heizungsthermostaten haben kann, die alle Profile verwaltet (ohne dass man Textfiles direkt selbst editieren muß) und das dann an sehr unterschiedliche Device-Typen verteilt (CUL_HM, HMCCUDEV, MAX ...), und mittelbar (über den WDT) dann die Option besteht, das auch an Typen weiterzugeben, die selbst intern gar keine Profile unterstützen (evtl. z.B. ZWave-Thermostate). Interessant ist das evtl. auch für die, die $we-Fähigkeiten an den HK-Thermostaten vermissen.

Also: Feedback und Ideen sind willkommen, und wenn ich damit auf dem Holzweg bin oder einen besseren Weg übersehen habt, laßt es mich wissen...

Gruß, Beta-User

EDIT: aktuelles Modul siehe neuerer Beitrag

[sledge]

Habe ich bisher immer wieder mal vermisst, aber nicht als "feature-Wunsch" in den Raum geworfen.

Werde es mal mit einem Test-Raum ausprobieren.

[Beta-User]

  Das klingt gut...

Achtung: ich habe vorhin festgestellt, das es in weekprofile sowas wie "Topics" gibt. Das "kann" die jetzige Version (noch) nicht, es dürfte aber nicht so schwer einzubauen sein.
Allerings muss das "true" für die WE-Steuerung dann woanders hin (evtl. direkt als "weekprofileWE").

[sledge]

Hi,

also gerade mal einzwei Fälle getestet (an einem Dummy) - funktioniert IMHO einwandfrei. Habe ein paar Schaltzeiten / Heizabschnitte im weekprofile angelegt, dann den weekdaytimer neu "initialisiert" via defmod und bei verbose 5 zugeschaut. Funktioniert.

Spaßeshalber auch noch "switchInThePast" gesetzt - geht auch.

Also den ersten Test hat es bei mir überstanden.

Werde ggf am Wochenende mal einzwei WDT umstellen auf weekprofile und beobachten.

Danke für die Umsetzung - schöne Idee. Könnte generell für alle Heiz-Devices gemacht werden ;-) Hätte man ein einheitliches UI...

[Beta-User]

So, kleiner update von meiner Seite:

Nachdem ich mich etwas in die topic/profile-Sache eingelesen habe, ist es vermutlich für die updates aus weekprofile heraus einfacher, wenn wir die dort üblichen Mechanismen nutzen. Das erwartet ein Attribut namens "weekproflie", in dem der Name des Profils drinsteht, also gibt's das seit neuestem .

Demnach verkürzt sich die Angabe in der DEF auf "weekprofile:<device-name>[:<true>]", also z.B.

Code: [Auswählen]

defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 !$we|05:50|on-till:06\:00 $we|06:55|on 12:30|on !$we|14:06|on-till:14\:07 16:00|on 7|17:04|off 8|17:09|off \
weekprofile:wprof_test:true\
{}
attr Timer_Umwaelzpumpe WDT_Group test3
attr Timer_Umwaelzpumpe commandTemplate set $NAME  $EVENT
attr Timer_Umwaelzpumpe switchInThePast 1
attr Timer_Umwaelzpumpe weekprofile neu_1
So wie ich das verstanden habe, müßte der WDT dann bereits (bei topic-Verwendung in weekprofile) das zum gerade eingestellten Topic passende Profil erhalten.

Um updates auszulösen, gibt es einen neuen setter: "restart" Dieser löst eine komplette Neuinitialisierung des WDT aus und sollte sich damit eigentlich ohne weiteres zum "Anschubsen" seitens weekprofile eignen, wenn das "seinen Abnehmern" Änderungen mitteilen will.

Kann aber noch nicht sagen, ob das alles noch unbedachte Nebenwirkungen hat, glaub's aber im Moment nicht...

Was bei einigem Nachdenken vermutlich nach wie vor nicht optimal sein dürfte: Ich gehe davon aus, dass Samstags zu viele Timer generiert werden, wenn die $we-true-Option gesetzt ist. Das kann dazu führen, dass Timer unbeabsichtigt geskipped werden usw.. Bitte darauf mal ein kritisches Augenmerk legen, ein Hilfsmittel zur Ansicht der Timer ist hier zu finden: https://forum.fhem.de/index.php/topic,104167.msg992793.html#msg992793.

Wenn, dann ist das aber eigentlich ein allgemeines Thema beim WDT, das auch schon lange bestand. Aber evtl. ist auch der Code schon immer schlauer als von mir grade angenommen...

Gruß und Danke für den Mut zum Testen!

[sledge]

Hi,

also die neue Version runtergeladen, ein neues Profil im weekprofile angelegt und das im Attribut hinterlegt - einwandfrei.

Damit kann ich mir vorstellen, am Wochenende mal einzwei echte Räume / Heizprofile umzustellen.

Was die von Dir geäußerte Befürchtung angeht bzgl. der zuvielen Timer - ich werde einen Raum mit einem speziellen $we Profil mit in den Test einbeziehen. Mal sehen, ob mir was auffällt.

Soweit schonmal danke - läuft gut bisher.

Gruß,

Tom

[Beta-User]

Danke schon mal für's feedback bis hierher!

Wenn du Lust hast, kannst du gerne auch die commandref (und später evtl. etwas Wiki) dazu beisteuern; bei den Wechselwirkungen mit weekprofile ist es vermutlich besser, wenn das jemand macht, der es auch nutzt. Bei mir werden das eher nur ein paar dürre Worte .

Und bitte wirf' ein Augenmerk darauf, dass auch der letzte Timer am Tag wirklich abgearbeitet wird. Es gab dazu vorhin einen neuen Beitrag, der aber schon wieder geschlossen war, bevor ich dazu gekommen bin nachzuhaken, welche Version der TE überhaupt nutzt...

EDIT: die Probleme mit $we dürfte v.a. dann auftreten, wenn es um ein switchInThePast-Device geht (oder eines, das als Heizung automatisch erkannt wird).

[sledge]

Kann ich machen. Muße zum Schreiben habe ich derzeit zwar eher weniger (gibt da noch ein paar Baustellen...), aber da kann ich gerne was beisteuern.

Die Frage ist, wie eng man das Zusammenspiel mit weekprofile verzahnen möchte - zB könnte ja auch der "send to device" Mechanismus von weekprofile benutzt werden, um das Attribut "weekprofile" im Zieldevice (also dem Weekdaytimer) zu setzen.... dann entfällt mW sogar das restart - zumindest hat wer bei mir mit setzen des Attributes sofort die Config aus dem weekprofile gezogen.

Müsste man mal mit "risiko" sprechen. Aber auch so finde ich das Zusammenspiel ganz nett - mir zumindest lieber als die Zeiten beim Define direkt mit angeben zu müssen... Werde ich direkt bei den von mir betreuten FHEM-Installationen umsetzen, sollte die Testphase erfolgreich abgeschlossen sein und das Ding in die Serie gehen ;-)

Das mit dem "letzten Timer am Tag" habe ich auch - aber eben eher nicht-deterministisch. Meistens klappt es, aber gelegentlich wurde halt eine Temperatur nicht entsprechend gesetzt (bei 16 WDT in meinem Produktivsystem). Also nie "alle am selben Tag", sondern bisher eher "zufällig". Hatte aber noch keine Muße, dem mit "verbose 5" hinterherzusteigen.

[Beta-User]

Wegen der Verzahnung hatte ich Risiko heute morgen mal angeschrieben, ich nehme an, er wird sich schon bei Gelegenheit melden.

Wenn ich den weekprofile-Code richtig deute, sucht sich das Modul die Devices zusammen, die bestimmten TYPEs sind (WDT fehlt da noch) und das "weekprofile"-Attribut gesetzt haben; es setzt das aber nicht selbst, sondern es wird vorausgesetzt (aber ab jetzt ja vorhanden). Dazu benötigt es noch eine "Command"-Info, aber das sollte einfach sein.

Zum Verständnis der aktuellen Version noch:
Setzt man das Attribut im WDT, führt das unmittelbar auch zu einer Anfrage an das weekprofile-Device aus der DEF (via "restart"), deswegen "wirkt" das auf dich so "nahtlos" .

Was das "nicht-deterministische" Verhalten angeht, gibt es sicher eine Logik, und ich habe den dringenden Verdacht, dass das mit switchinthepast und $we zusammenhängt; die Lösung müßte sein, irrelevante Timer gar nicht erst zu setzen, also z.B. die $we-Timer eben nur am $we (das war eine Zeitlang anders), und eben ggf. auch umgekehrt (deswegen ist der Samstag m.E. in der Kombination weekprofile und WDT besonders spannend...).
Vermutlich muß dazu noch eine globalere Lösung her, mit der man dann zwischen einer "normalen" Wochentagsangabe und einer duch $we zu verdrängenden unterscheiden kann. Im ersteren Fall wird "additiv" vorgegangen (so ist das bisher, wenn ich es richtig deute), im anderen verdrängt $we das normale Tagsprofil (das ist in der Regel gewollt, vermute ich; und wer iVm. weekprofile "true" setzt, will das ausdrücklich...). Ich habe dazu eine Idee, aber so richtig im Code angeschaut/getestet ist es noch nicht.

Wird also vermutlich noch etwas dauern, bis es "svn-fähig" wird, aber an sich sehe ich im Moment jedenfalls auch für den Code bis dahin keine gravierenden Hürden für einen produktiven Einsatz. Im Prinzip sind es ein paar zusätzliche Kleinigkeiten und ein Parser, der die Rückmeldung von weekprofile in die "WDT-Sprache" übersetzt; letzterer scheint zu funktionieren, ab da (konkret: wenn es korrekt übersetzt im Internal "SWITCHINGTIMES" steht) ist es "wie gehabt"...

[Beta-User]

...und noch ein update...

Das kann funktional nicht mehr als die andere, aber es ist jedenfalls bis dahin gediehen, dass man erkennen kann, welche Timer eigentlich nicht gesetzt werden sollen, wenn gleichzeitig $we ist. Leider bekomme ich es jedenfalls im Moment nicht hin, diese Info auch so auszuwerten, dass die betreffenden Timer gar nicht gesetzt werden; vielleicht hat jemand eine Idee, der Code ist (auch) an der Stelle unglaublich vertrackt (jedenfalls mit meinen Kenntnissen betrachtet).

Gruß, Beta-User

[Karflyer]

Hallo Beta-User,

nach dem Einspielen der neuen Programmversion habe ich nun folgende Fehlermeldung beim Neustart von FHEM im Log:

Code: [Auswählen]

2019.11.22 10:17:52 1: PERL WARNING: Use of uninitialized value $st[3] in string eq at ./FHEM/98_WeekdayTimer.pm line 360.
Gruß
Stefan

[Beta-User]

Thx.

Ist zum Glück nur ein Warning, bitte mal so ändern:

Code: [Auswählen]

$overrulewday = 1 if defined $st[3] && $st[3] eq "w";

[Karflyer]

Thx.

Ist zum Glück nur ein Warning, bitte mal so ändern:
Code: [Auswählen]
$overrulewday = 1 if defined $st[3] && $st[3] eq "w";

Jetzt sieht es gut aus. Keine Fehlermeldung beim Neustart. Danke.

Gruß
Stefan

[Beta-User]

Anbei eine aktualisierte Fassung, die das warning beseitigt und vor allem (hoffentlich) eine Lösung für den "verlorenen" letzten Timer vom Vortag enthält.

Manko, das ich beim Testen festgestellt habe: Der Schaltzeitpunkt wird vom "nachgeholten" Timer übernommen, ändert man was an der DEF, wirkt sich das nicht auf diesen Schaltzeitpunkt aus, kann also sein, dass da noch Verbesserungspotential besteht. Aber besser ein (wahrscheinlich richtiger) Timer, der auch schaltet, als ein "vergessener"...

Viel Spaß beim Testen...

[Beta-User]

Und wieder eine Aktualisierung:

Die sollte folgendes leisten:
- Es gibt einen anderen neuen setter "weekprofile". Der nimmt als Argument "<weekprofile-device>:<topic>:<profile>"
- Hat man mindestens eine weekprofile-Angabe in der DEF, gibt es ein Reading namens "weekprofiles" (ja, mit "s", sonst kommt da immer der aktuelle Readingwert, was nicht ganz optimal wäre, s.u.); das enthält beim Start mindestens eine Angabe mit dem Namen des ersten weekprofile in der DEF und :default:default" dahinter.
- Nutzt man später den setter, wird für jedes gültige weekprofile-Device (Name und TYPE passen) dann das triplett wie oben angegeben da reingeschrieben, das ganze für mehrere weekprofile-Devices Leerzeichen-separiert, wobei immer nur ein Eintrag pro weekprofile-Device gültig ist.
Ungültige Angaben/Versuche findet man mit verbose-3-Level im log.

Ist bisher nur kurz auf Funktionalität getestet, scheint aber soweit zu klappen, groß logs ausgewertet habe ich auch noch nicht...

Um nachzusehen, ob ein Topic- oder Profilwechsel jeweils geklappt hat, sollte man auch die lists des WDT jeweils ansehen.

Gruß, Beta-User