FHEM - Hausautomations-Systeme > Kalendermodule

[neues feature] WeekdayTimer mit weekprofile steuern

(1/17) > >>

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: ---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\
{}
--- Ende Code ---

--- Code: ---defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test
--- Ende Code ---
defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test::true
--- Code: ---defmod Timer_Umwaelzpumpe WeekdayTimer MYSENSOR_98 weekprofile:wprof_test:true
--- Ende Code ---
Theoretisch 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: ---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
--- Ende Code ---

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!

Navigation

[0] Themen-Index

[#] Nächste Seite

Zur normalen Ansicht wechseln