Weekdaytimer Verständnisproblem

[persching]

Hallo zusammen,
ich hatte die ganze Zeit zum Heizen WDT mit weekprofile, aber ich hab mittlerweile so viel Profile und dachte, es geht ja auch ohne Profile und ich schalte direkt die WDT per Condition um.
Prinzipiell ist die eingestellte Raumtemperatur abhängig vom $we oder !$we, der Anwesenheit von Familie oder dem Roommate und von einem Dummy (je Raum), der mir ein Profil vorgibt. Für diesen Dummy gibt es die Zustände "Auto, Minimal und Aus". Daraus folgen die Profile:

WDT_Raumname_Aus
WDT_Raumname_Auto_Anwesend
WDT_Raumname_Auto_Abwesend
WDT_Raumname_Minimal_Anwesend
WDT_Raumname_Minimal_Abwesend
WDT_Raumname_Verreist

Jetzt triggert aber bspw. WDT_Lena_Auto_Abwesend, obwohl rr_Lena = zuhause

OG_KiZi_Lena_T de 00:00|19.5 ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq "true")

Code: [Auswählen]

2022.05.21 21:53:52.007 4: [WDT_Lena_Auto_Abwesend] aktParam:19.5 newParam:19.5 - is not disabled
2022.05.21 21:53:52.005 5: [WDT_Lena_Auto_Abwesend] removing Timer: WDT_Lena_Auto_Abwesend_1
2022.05.21 21:53:52.005 4: [WDT_Lena_Auto_Abwesend] Update   - past timer activated
2022.05.21 21:53:52.005 5: [WDT_Lena_Auto_Abwesend] condition evaluation returned:
2022.05.21 21:53:52.004 5: [WDT_Lena_Auto_Abwesend] evaluated condition: { ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq "true") }
2022.05.21 21:53:52.003 4: [WDT_Lena_Auto_Abwesend] checking condition: ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq "true")
2022.05.21 21:53:52.003 5: [WDT_Lena_Auto_Abwesend] result of check days: 1
2022.05.21 21:53:52.003 5: [WDT_Lena_Auto_Abwesend] check days:  my $days = {} ; map{ $days->{$_} = 1 }() ; defined $days->{$wday} ||  $we
2022.05.21 21:53:52.002 4: [WDT_Lena_Auto_Abwesend] check days:7
2022.05.21 21:53:52.002 5: [WDT_Lena_Auto_Abwesend] sensor 'OG_KiZi_Lena_Fensterkontakt' Reading/Attribute 'state' is 'closed'
2022.05.21 21:53:52.002 4: [WDT_Lena_Auto_Abwesend] list of window sensors found: 'WDT_Lena_Auto_Abwesend OG_KiZi_Lena_Fensterkontakt'
2022.05.21 21:53:52.002 4: [WDT_Lena_Auto_Abwesend] time=00:00/1653084000 delay=78832, nextDelay=78900, nextRetry=1653162900
2022.05.21 21:53:52.002 5: [WDT_Lena_Auto_Abwesend] removing Timer: WDT_Lena_Auto_Abwesend_delayed
2022.05.21 21:53:52.001 5: [WDT_Lena_Auto_Abwesend] setting  Timer: WDT_Lena_Auto_Abwesend_1 2022-05-21 00:00:00
2022.05.21 21:53:52.001 4: [WDT_Lena_Auto_Abwesend] OG_KiZi_Lena_T 2022-05-21 00:00:00 78832s
2022.05.21 21:53:47.873 5: [WDT_Lena_Auto_Abwesend] setting  Timer: WDT_Lena_Auto_Abwesend_midnight 2022-05-22 00:00:05
2022.05.21 21:53:47.873 5: [WDT_Lena_Auto_Abwesend] setting  Timer: WDT_Lena_Auto_Abwesend_delayed 2022-05-21 21:53:52
2022.05.21 21:53:47.873 4: [WDT_Lena_Auto_Abwesend] past timer on OG_KiZi_Lena_T at 2022-05-21 00:00:00 with  19.5 activated
2022.05.21 21:53:47.873 5: [WDT_Lena_Auto_Abwesend] sensor 'OG_KiZi_Lena_Fensterkontakt' Reading/Attribute 'state' is 'closed'
2022.05.21 21:53:47.873 4: [WDT_Lena_Auto_Abwesend] list of window sensors found: 'WDT_Lena_Auto_Abwesend OG_KiZi_Lena_Fensterkontakt'
2022.05.21 21:53:47.872 4: [WDT_Lena_Auto_Abwesend] time=00:00/1653084000 delay=78827, nextDelay=78900, nextRetry=1653162900
2022.05.21 21:53:47.862 5: [WDT_Lena_Auto_Abwesend] result of check days: 1
2022.05.21 21:53:47.861 5: [WDT_Lena_Auto_Abwesend] check days:  my $days = {} ; map{ $days->{$_} = 1 }(0,1,2,3,4,5,6) ; defined $days->{$wday}
2022.05.21 21:53:47.861 4: [WDT_Lena_Auto_Abwesend] check days:0,1,2,3,4,5,6
2022.05.21 21:53:47.858 4: [WDT_Lena_Auto_Abwesend] Heating recognized - switch in the past activated
2022.05.21 21:53:47.857 4: [WDT_Lena_Auto_Abwesend] device type heating recognized, setModifier:desiredTemperature
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 6: Samstag)
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 5: Freitag)
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 4: Donnerstag)
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 3: Mittwoch)
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 2: Dienstag)
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 1: Montag)
2022.05.21 21:53:47.839 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 0: Sonntag)
2022.05.21 21:53:47.758 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 6: Samstag)
2022.05.21 21:53:47.758 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 5: Freitag)
2022.05.21 21:53:47.758 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 4: Donnerstag)
2022.05.21 21:53:47.758 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 3: Mittwoch)
2022.05.21 21:53:47.758 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 2: Dienstag)
2022.05.21 21:53:47.757 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 1: Montag)
2022.05.21 21:53:47.757 4: [WDT_Lena_Auto_Abwesend] 00:00:00 19.5,  (Profil 0: Sonntag)
2022.05.21 21:53:47.754 4: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq "true") - NOT accepted, must be command or condition
2022.05.21 21:53:47.754 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq "true")  - trying to accept as a switchtime
2022.05.21 21:53:47.754 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq  - unbalanced brackets (: 6 ): 5 {: 0 }: 0
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto") eq  - trying to accept as a switchtime
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto")  - unbalanced brackets (: 6 ): 5 {: 0 }: 0
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq "Auto")  - trying to accept as a switchtime
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq  - unbalanced brackets (: 6 ): 4 {: 0 }: 0
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto") eq  - trying to accept as a switchtime
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto")  - unbalanced brackets (: 6 ): 4 {: 0 }: 0
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and (ReadingsVal("WDT_Lena_Profile","state","Auto")  - trying to accept as a switchtime
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and  - unbalanced brackets (: 4 ): 3 {: 0 }: 0
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true") and  - trying to accept as a switchtime
2022.05.21 21:53:47.753 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true")  - unbalanced brackets (: 4 ): 3 {: 0 }: 0
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq "true")  - trying to accept as a switchtime
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq  - unbalanced brackets (: 4 ): 2 {: 0 }: 0
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false") eq  - trying to accept as a switchtime
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false")  - unbalanced brackets (: 4 ): 2 {: 0 }: 0
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" || ReadingsVal("Nachtabsenkung","state","false")  - trying to accept as a switchtime
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" ||  - unbalanced brackets (: 3 ): 1 {: 0 }: 0
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend" ||  - trying to accept as a switchtime
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend"  - unbalanced brackets (: 3 ): 1 {: 0 }: 0
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq "abwesend"  - trying to accept as a switchtime
2022.05.21 21:53:47.752 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq  - unbalanced brackets (: 3 ): 1 {: 0 }: 0
2022.05.21 21:53:47.751 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause") eq  - trying to accept as a switchtime
2022.05.21 21:53:47.751 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause")  - unbalanced brackets (: 3 ): 1 {: 0 }: 0
2022.05.21 21:53:47.751 5: [WDT_Lena_Auto_Abwesend] ((ReadingsVal("rr_Lena","state","zuhause")  - trying to accept as a switchtime
2022.05.21 21:53:47.751 4: [WDT_Lena_Auto_Abwesend] 00:00|19.5 - accepted
2022.05.21 21:53:47.751 5: [WDT_Lena_Auto_Abwesend] 00:00|19.5  - trying to accept as a switchtime
2022.05.21 21:53:47.749 5: [WDT_Lena_Auto_Abwesend] removing Timer: WDT_Lena_Auto_Abwesend_midnight
Kann oder soll das so funktionieren? Oder geht es nur mit weekprofile?

[Beta-User]

Kann oder soll das so funktionieren? Oder geht es nur mit weekprofile?

Es kann schon so funktionieren, allerdings erschließt sich mir der Sinn der letzten 'eq "true"'-Abfrage nicht. Wirf mal die Einzelteile wie z.B.

Code: [Auswählen]

ReadingsVal("Nachtabsenkung","state","false") eq "true" in das FHEM-Kommando-Feld und schau, was da für ein Ergebnis kommt.

Ob die Verkettung in der high+ low-level-Variante das ergibt, was du haben willst, wäre auch noch so eine Frage ("||"+"and"). PBP mag sowas jedenfalls nicht.

Ansonsten glaube ich immer noch, dass sowas besser geht mit weekprofile. Besser =
- weniger gleichzeitig von FHEM zu verwaltende Timer (alles, was "delayed" ist, wird jede Minute geprüft, du hast also immer 5 zusätzliche Timer, die du eigentlich nicht brauchst)
- deutlich übersichtlicher, weil es immer nur ein aktives Profil geben kann (!), und welches es ist, sieht man direkt am WDT. Bei solchen komplizierteren Konstruktionen besteht sonst immer die Gefahr, dass doch zwei oder mehr WDT gleichzeitig aktiv sind, wenn ein Syntax- oder Logikfehler vorliegt (qed).

[persching]

ok, das "eq = "true" das ist noch ein überbleibsel aus diversen Versuchen und natürlich falsch - hatte ich übersehen. Ich hatte alle Bedingungen in ein if gepackt und das eben auf eq = "true" geprüft, was aber auch nicht funktioniert hat.

Gut, wenn das mit den weekprofiles besser gehen soll, dann mache ich mir mal Gedanken, ob ich die vielleicht anders/sinnvoller gruppieren kann. Bisher hatte ich immer Probleme, dass bei einem "restore Topic" auch Räume geschaltet wurden, die derzeit gar nicht hätten geschaltet werden sollen. Z.b. Wenn meine Frau von der Arbeit kam und die beiden Kinder noch nicht zuhause waren, dann wurde dort auch schon die hohe Temperatur gesetzt. Ich hab ja nun Zeit bis zur nächsten Heizperiode das zu optimieren.

[Beta-User]

Na ja, es gibt afaik noch keine nachvollziehbare "Musterlösung" mit Residents und Co.

Von daher können wir gerne versuchen, mal ein notify+Perl-Code zu basteln, das aus den gegebenen Rahmenbedingungen die passenden Befehle ableitet.
Wenn ich da helfen soll, müßtest du mal darlegen, welche Eingangsbedingungen (Events) es gibt. Scheinbar sind das Anwesenheiten bei Residents (bzw. auch dran hängende Gruppen), sowie eben für einzelne Räume noch ein "Modus-Schalter" sowie ggf. noch "Nachtabsenkung" (und vermutlich ein globaler Schalter, mit dem man alles deaktiviert?)?

Soweit würde ich mal behaupten, dass das eine Art "allgemeingültiger Standard" wäre, den man dann auch woanders mit kleinen Anpassungen gut verwenden können sollte .

[persching]

Also, dann beschreibe ich mal, was meine Anforderungen und Gegebenheiten bisher sind:

4 Bewohner, 2 Eltern, 2 Kinder abgebildet in Residents und Roommate, dort aber nur die Zustände "zuhause", "abwesend" und "verreist".
Abfrage der Zustände über Presence der Handys in der Fritzbox.

Geschaltet werden die Topics über Homemode bei eintretenden Zustandsänderungen.

Dann gibt es eben die Räume in verschiedenen Kategorien:
Allgemeine Räume: Wohnzimmer, Küche, Bäder, Flur
Schlafräume: Schlafzimmer, Kinderzimmer1 und Kinderzimmer2

Dazu kommt noch ein "Profilumschalter" je Raum bei dem man auswählen kann zwischen "Auto", "Minimal" und "Aus".
Auto = Heizperiode ca. Oktober bis März
Minimal = Übergangszeit, morgens und abends heizen, dazwischen die Thermostate runterfahren und wenn die durchschnittliche Ventilstellung klein genug ist, dann auch die Heizung umschalten auf "nur Warmwasser".
Aus = Thermostat wird auf 5°C gesetzt

Und seit Corona kommt noch eine weitere Komplikation dazu:
Homeoffice. Das kann ich erfassen, wenn mein Geschäftslaptop per Presence online ist und der Zwischenstecker an meinem Monitor mehr als 15 Watt ausgibt.

Dafür ist eine andere Komplikation rausgefallen: der Kachelofen darf nicht mehr genutzt werden und darum entfällt das Topic Kachelofen...

Die erwähnte Nachtabsenkung ist ein umgebauter Fensterkontaktschalter, der parallel zur Umwälzpumpe der Heizung hängt. Ohne diese Erfassung hatte ich das Problem, dass die verwendeten MAX!Thermostate versucht haben immer weiter zu regeln, obwohl die Gasheizung in der Nachtabsenkung war (die Heizung macht das wiederum Außentemperaturabhängig). Das führte dann dazu, dass es regelmäßig sehr warm wurde, wenn die Heizung zugeschaltet hat. Die Thermostate sind leider sehr träge.
Aber man könnte es natürlich auch als "Eco-Schalter" oder so sehen/realisieren, weil es ist letztendlich nur eine true/false Abfrage.

Zusätzlich hatte ich dann noch unterschieden zwischen "Arbeitstag" und "Kein Arbeitstag" als Topic. Das ergibt eben jede Menge Topics und war letztendlich der Anlass das neu zu machen. Arbeitstag und kein Arbeitstag will ich z.B. schonmal über $we und !$we. Und eben genau aus diesem Grund dachte ich, dass ich mit den Conditions bei den weekdaytimern das einfacher regeln kann. Aber so eine richtige Lösung hab ich nicht gefunden.

[Beta-User]

Hmm, Homemode kenne ich jetzt wiederum (noch) nicht, ich gehe aber davon aus, dass das bei Eintreten eines Ereignisses eben auch im Prinzip beliebigen Perl-Code "abfeuern" kann?

Grundsätzlich kann WDT auch bei weeprofile-Integration $we anders behandeln als normale Tage unter der Woche - dafür gibt es das "true"-Argument . Damit entfällt schon mal die Hälfte der "befürchteten" Topics.

Was es einigermaßen kompliziert macht, ist das mit dem Profilumschalter pro Raum. Warum ist der pro Raum und nicht "global"? Abgefragt werden doch im Wesentlichen nur äußere Einflüsse, die überall gleich sind. Lediglich ein manuelles "Aus" wäre hier "speziell" und könnte dann (als vorübergehendes manuelles Ausschalten gedacht) dann auch über eine disableCondition im WDT geregelt werden?

Dann könnte man doch jedem Resident "seine" Thermostate zuordnen und dann (nur für diesen) Topics wie  rr_kind1_verreist,  rr_kind1_abwesend und rr_kind1_anwesend vorsehen, entsprechendes für gemeinsame Räume nur der Kinder ( rgr_kind_verreist, ... für das gemeinsame Kinder-Bad) usw.. Ist der Hauptschalter aus und das Topic "Aus" gesetzt, passiert eben gar nichts (das wäre dann im Homemode-Device zu vercoden).

Das "homeoffice" bekommt eine eigene Anwesenheit oä., auch darauf kann man reagieren und dann eben den Topic homeoffice_active, homeoffice_inactive, ... setzen, was sich dann ggf. eben nur auf den einen Heizkörper im Büro auswirkt (der Rest müßte eh' über "normales presence" abgedeckt sein)?

Dabei ist es nicht zwingend, dass man für jedes Profil auch wirklich spezielle Daten eingibt, das könnte auch eine Profil-Referenz innerhalb weekprofile sein (damit z.B. rr_kind1_anwesend und rr_kind2_anwesend effektiv gleich laufen).

Vielleicht nochmal ganz anders gesagt: nicht jeder Thermostat/WDT muss jedes Topic "kennen", im Gegenteil: Er sollte jeweils nur auf die für ihn relevanten Topics "reagieren".

Weiß jetzt aber nicht, ob dir das wirklich weiterhilft?

[persching]

Hmm, Homemode kenne ich jetzt wiederum (noch) nicht, ich gehe aber davon aus, dass das bei Eintreten eines Ereignisses eben auch im Prinzip beliebigen Perl-Code "abfeuern" kann?

Ja genau

Was es einigermaßen kompliziert macht, ist das mit dem Profilumschalter pro Raum. Warum ist der pro Raum und nicht "global"? Abgefragt werden doch im Wesentlichen nur äußere Einflüsse, die überall gleich sind. Lediglich ein manuelles "Aus" wäre hier "speziell" und könnte dann (als vorübergehendes manuelles Ausschalten gedacht) dann auch über eine disableCondition im WDT geregelt werden?

Das hängt vielleicht auch ein wenig mit meinen Anforderungen im Haus zusammen. Schlafzimmer ist im Altbau und dort wird es bei Sonne relativ schnell warm und im Winter eben auch schnell kalt. Darum ist dort eine Heizung notwendig. Da das aber ein 4m langer Heizkörper ist (war früher mal eine Wohnküche) powert der gewaltige wärme, wenn er sich einschaltet. Also ist der relativ schnell auf "Minimal". Ebenso das Badezimmer, das eigentlich nur morgens und abends genutzt wird.
Die Kinderzimmer und das Wohnzimmer haben hingegen eine Nordausrichtung und müssen relativ lange beheizt werden, weil keine Sonne rein kommt... die bleiben also auf Auto.
Die Frage ist nur, ob das über das Jahr gesehen lohnenswert ist hier zu unterscheiden. Denn meistens ist die Umstellungsphase in 2-3 Wochen für alle Thermostate gemacht. Also könnte man das zur "Entschlackung der Topics" opfern und das nur noch Zentral steuern.

Dann könnte man doch jedem Resident "seine" Thermostate zuordnen und dann (nur für diesen) Topics wie  rr_kind1_verreist,  rr_kind1_abwesend und rr_kind1_anwesend vorsehen, entsprechendes für gemeinsame Räume nur der Kinder ( rgr_kind_verreist, ... für das gemeinsame Kinder-Bad) usw.. Ist der Hauptschalter aus und das Topic "Aus" gesetzt, passiert eben gar nichts (das wäre dann im Homemode-Device zu vercoden).

Das "homeoffice" bekommt eine eigene Anwesenheit oä., auch darauf kann man reagieren und dann eben den Topic homeoffice_active, homeoffice_inactive, ... setzen, was sich dann ggf. eben nur auf den einen Heizkörper im Büro auswirkt (der Rest müßte eh' über "normales presence" abgedeckt sein)?

Dabei ist es nicht zwingend, dass man für jedes Profil auch wirklich spezielle Daten eingibt, das könnte auch eine Profil-Referenz innerhalb weekprofile sein (damit z.B. rr_kind1_anwesend und rr_kind2_anwesend effektiv gleich laufen).

Vielleicht nochmal ganz anders gesagt: nicht jeder Thermostat/WDT muss jedes Topic "kennen", im Gegenteil: Er sollte jeweils nur auf die für ihn relevanten Topics "reagieren".

Weiß jetzt aber nicht, ob dir das wirklich weiterhilft?

Die Kinderzimmer sind weniger das Problem, hier ist ja eine klare Zuordnung von Bewohner und Raum möglich. Komplizierter wird es bspw. wenn im Homeoffice alle Gemeinschaftsräume um 1 Grad abgesenkt werden und dann meine Frau von der Arbeit kommt (vor den Kindern, aber während des Homeoffices) und somit dann quasi wieder das normale Automatiktopic Anwesenheit triggert. Das würde mir dann das Homeoffice Topic überschreiben. Zumindest ist es im Moment so, weil ich einfach über eine Perlfunktion auswerte welches Topic jetzt kommen muss und das dann setze. Und ein restore_Topic wirkt ja immer auf alle. Außerdem möchte ich von dieser Perlfunktion eigentlich weg. Ich denke immer, es müsste doch einfacher möglich sein, das alles zu steuern.

Über gleiche Topics für verschiedene Räume habe ich auch schon nachgedacht. Aber irgendwie sind die Anforderungen im Form von der persönlichen Wohlfühltemperatur doch immer ein wenig anders. Wobei man das vielleicht noch ausgleichen kann, wenn man zwar die gleiche Temperatur als Solltemperatur bspw. für beide Kinderzimmer vorgibt, aber in einem der beiden Zimmer den Temperaturoffset des Thermostates um 0,5 Grad anpasst. Gerade die Kinderzimmer sind im Winter grund verschieden. Unter dem einen Zimmer ist das Wohnzimmer = wärmster Raum und unter dem anderen ist die Garage, also unbeheizt und dazu ist das noch der letzte Raum im Heizkreislauf. Das bekommen die Thermostate einfach nicht so doll geregelt. 

[Beta-User]

Hmm, also ziemlich viele Einflussgrößen von außen her gedacht und auf der anderen Seite sehr viele Möglichkeiten, wie man das in FHEM umsetzen könnte.

Ein paar Gedanken:
- Der HK im Schlafzimmer klingt überversorgt, was den hydraulischen Abgleich angeht. Vielleicht versuchst du mal, den zu "beschränken", also (wenn vorhanden) die Begrenzung im Ventil zuzumachen (notfalls geht das auch über die Schraube im Rücklauf, die in jedem Fall vorhanden sein sollte).
- Gleicher Topic bedeutet nicht, dass das auch ein identisches Profil sein müßte.
- Für das Bad und das Schlafzimmer könntest du überlegen, ob du intern je zwei "Echt-Profile" generierst, die du dann mit dem "Zimmerschalter" umreferenzierst, so dass jeweils der "Auto"-Topic auf das für diesen HK passende Sub-Profil "zeigt". Ein Umschalten für den Raum von "Auto" auf "Minimal" würde dann bedeuten: erst "Umbiegen" der Referenz für diesen HK, dann Neuverteilen des ("Auto")+sonstige Rahmenbedingungen-Topics an alle (ggf. verzögert, damit erst alle Umreferenzierungen durch sind, bis das passiert).
- Entsprechendes gilt dann für die "längerphasigen" Räume (Kinderzimmer/Wohnzimmer), und vielleicht auch für "Homeoffice" (den Raum) innerhalb des "Frau-ist-da"-Topics.
- Prinzipiell stellt sich die Frage, ob "Homeoffice" (der Raum) beeinflusst sein soll von "Frau ist da" - wenn nein, kannst du den Raum einfach aus diesem Topic rauslassen. Es müssen ja nicht alle Räume/WeekdayTimer alle Topics kennen. Dann wird der Rest umgestellt, der eine bleibt halt wie er ist...

- Was "ein Profil" (auf weekprofile-Seite) und effektive Regelung angeht, kannst du auch "mappen" (innerhalb WDT), und z.B. dann im einen Raum "21.5" mit "daytemp" übersetzen und in dem Thermostaten dann eine andere daytemp eingestellt haben oder das auf 23 Grad im WDT umstellen und die Einstellungen auf der Hardware  nicht anfassen.

Prinzipiell wirst du aber nicht umhinkommen, für deine komplexe Regelungsanforderung auch entsprechend Aufwand in Konfiguration und Logik zu stecken.

Hilft dir das weiter?

[persching]

Hmm, also ziemlich viele Einflussgrößen von außen her gedacht und auf der anderen Seite sehr viele Möglichkeiten, wie man das in FHEM umsetzen könnte.

Ein paar Gedanken:
- Der HK im Schlafzimmer klingt überversorgt, was den hydraulischen Abgleich angeht. Vielleicht versuchst du mal, den zu "beschränken", also (wenn vorhanden) die Begrenzung im Ventil zuzumachen (notfalls geht das auch über die Schraube im Rücklauf, die in jedem Fall vorhanden sein sollte).

Das wurde bei der Heizungsmodernisierung gemacht. Damals musste ich das machen lassen, weil die KfW das gefordert hatte. Den eingestellten Wert am Thermostatventil hab ich dann nochmal reduziert. Insofern denke ich, ich bin da schon relativ weit unten. Es muss halt ein Kompromiss sein, dass man tagsüber auch in einer annehmbaren Zeit eine gute Temperatur erreicht, weil das Schlafzimmer eben auch gleichzeitig Büro ist. Vielleicht wäre ein schneller regelnder Thermostat schon des Rätsels Lösung. Nachdem ich im Wohnzimmer den defekten MAX Thermostat gegen einen Homematic Thermostat getauscht habe, habe ich festgestellt, dass der Homematic viel besser regelt. Der macht zwar erstmal 100% auf, dann aber auch innerhalb kurzer Abstände regelt er auch wieder runter. Der MAX Thermostat macht auf und dann passiert 2 Stunden lang nix. Ich finde es allerdings nicht besonders nachhaltig noch funktionierende Dinge zu entsorgen...

- Gleicher Topic bedeutet nicht, dass das auch ein identisches Profil sein müßte.
- Für das Bad und das Schlafzimmer könntest du überlegen, ob du intern je zwei "Echt-Profile" generierst, die du dann mit dem "Zimmerschalter" umreferenzierst, so dass jeweils der "Auto"-Topic auf das für diesen HK passende Sub-Profil "zeigt". Ein Umschalten für den Raum von "Auto" auf "Minimal" würde dann bedeuten: erst "Umbiegen" der Referenz für diesen HK, dann Neuverteilen des ("Auto")+sonstige Rahmenbedingungen-Topics an alle (ggf. verzögert, damit erst alle Umreferenzierungen durch sind, bis das passiert).
- Entsprechendes gilt dann für die "längerphasigen" Räume (Kinderzimmer/Wohnzimmer), und vielleicht auch für "Homeoffice" (den Raum) innerhalb des "Frau-ist-da"-Topics.

Ehrlich gesagt, weiß ich nicht, wie das funktionieren soll. Kannst du das mit einem Beispiel grob skizzieren??

- Prinzipiell stellt sich die Frage, ob "Homeoffice" (der Raum) beeinflusst sein soll von "Frau ist da" - wenn nein, kannst du den Raum einfach aus diesem Topic rauslassen. Es müssen ja nicht alle Räume/WeekdayTimer alle Topics kennen. Dann wird der Rest umgestellt, der eine bleibt halt wie er ist...

Ja, prinzipiell ja schon. Aber es ist halt davon abhängig, ob die Ankunft meiner Frau die Temperatur im Schlafzimmer beeinflusst. Hier vielleicht mal mit Zahlen:
Kein Homeoffice Tag, alle Bewohner abwesend, wird die Schlafzimmertemperatur auf 18.5 Grad gesenkt. Kommt nun ein Bewohner heim, wird wieder die normale Temperatur in allen Räumen reaktiviert, also im Beispiel Schlafzimmer 19.5 Grad.
Bei einem Homeofficetag werden alle Räume ein wenig abgesenkt (sagen wir 1 bis 1,5 Grad), aber das Schlafzimmer wird dagegen auf 21 Grad erhöht. Also sogar mehr, als einem normalen Anwesenheitstag. Somit muss das Schlafzimmer ja beide Topics kennen... Oder habe ich noch irgendwo einen Denkfehler?

- Was "ein Profil" (auf weekprofile-Seite) und effektive Regelung angeht, kannst du auch "mappen" (innerhalb WDT), und z.B. dann im einen Raum "21.5" mit "daytemp" übersetzen und in dem Thermostaten dann eine andere daytemp eingestellt haben oder das auf 23 Grad im WDT umstellen und die Einstellungen auf der Hardware  nicht anfassen.

Das hört sich vielversprechend an und ich hab es gleich mal ausprobiert. So könnte man mit dem $EVENT "comfort" oder "eco" 2 feste Temperaturen hinterlegen, die in Zimmer A und B völlig unterschiedlich sein können. Super, das hat mir auf alle Fälle weitergeholfen.
Was irgendwie auch noch cool wäre, wenn man relative Temperaturangaben machen könnte. Also quasi "$we|09:00|eco+1" oder "!$we|10:00|comfort-2"... so könnte man relativ einfach eine absenken der Raumtemperatur bei Abwesenheit um 2 Grad umsetzen. Aber ich befürchte, dass sich das nicht umsetzen lässt.

Prinzipiell wirst du aber nicht umhinkommen, für deine komplexe Regelungsanforderung auch entsprechend Aufwand in Konfiguration und Logik zu stecken.

Hilft dir das weiter?

Ja da bin ich ja dabei, aber gerade weil viele Wege nach Rom führen ist es nicht ganz so einfach den idealen Weg zu finden. Generell muss ich die Komplexität reduzieren, aber ich glaube das wird auch klappen.

[Beta-User]

Insofern denke ich, ich bin da schon relativ weit unten. Es muss halt ein Kompromiss sein, dass man tagsüber auch in einer annehmbaren Zeit eine gute Temperatur erreicht, weil das Schlafzimmer eben auch gleichzeitig Büro ist. [...] Ich finde es allerdings nicht besonders nachhaltig noch funktionierende Dinge zu entsorgen...

OK, dann erzähle ich dir ja prinzipiell nichts neues mit der Hydraulik... Ein angenehmes Regelungsverhalten würde ich dann höher bewerten als das Erhaltungsinteresse, zumal du den MAX ja ggf. auch noch woanders einsetzen könntest. (Ich bin prinzipiell aber auch sehr für gegen Wegwerfen!).

Ehrlich gesagt, weiß ich nicht, wie das funktionieren soll. Kannst du das mit einem Beispiel grob skizzieren??

Ich versuchs - vielleicht etwas allgemeingültiger. Man nehme einen Bewohner, der in rollierenden Schichten an allen Wochentagen arbeiten kann - wenn keine Schicht angesagt ist, ist entweder "Tagschicht" (wie alle anderen Berufstätigen im Haushalt) oder eben eine Art "Urlaub zu hause". Die letzten beiden Fälle lasse ich mal weg, hier also mal die drei Schichtprofile:

Code: [Auswählen]

Frühschicht:Kind1
{"Sun":{"temp":["18.0","21.0","18.0","21.0","18.0"],"time":["05:00","05:30","14:00","22:30","24:00"]},"Fri":{"temp":["18.0","21.0","18.0","21.0","18.0"],"time":["05:00","05:30","14:00","22:30","24:00"]},"Wed":{"temp":["18.0","21.0","18.0","21.0","18.0"],"time":["05:00","05:30","14:00","22:30","24:00"]},"Tue":{"time":["05:00","05:30","14:00","22:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]},"Mon":{"time":["05:00","05:30","14:00","22:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]},"Sat":{"time":["05:00","05:30","14:00","22:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]},"Thu":{"time":["05:00","05:30","14:00","22:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]}}

Spätschicht:Kind1
{"Sun":{"temp":["18.0","21.0","18.0","19.5","18.0"],"time":["07:00","13:00","22:00","23:00","24:00"]},"Fri":{"temp":["18.0","21.0","18.0","19.5","18.0"],"time":["07:00","13:00","22:00","23:00","24:00"]},"Wed":{"time":["07:00","13:00","22:00","23:00","24:00"],"temp":["18.0","21.0","18.0","19.5","18.0"]},"Tue":{"time":["07:00","13:00","22:00","23:00","24:00"],"temp":["18.0","21.0","18.0","19.5","18.0"]},"Mon":{"time":["07:00","13:00","22:00","23:00","24:00"],"temp":["18.0","21.0","18.0","19.5","18.0"]},"Thu":{"time":["07:00","13:00","22:00","23:00","24:00"],"temp":["18.0","21.0","18.0","19.5","18.0"]},"Sat":{"time":["07:00","13:00","22:00","23:00","24:00"],"temp":["18.0","21.0","18.0","19.5","18.0"]}}

Spätschicht:Kind1
{"Sun":{"temp":["18.0","21.0","18.0","21.0","18.0"],"time":["06:00","07:30","14:00","21:30","24:00"]},"Wed":{"time":["06:00","07:30","14:00","21:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]},"Fri":{"time":["06:00","07:30","14:00","21:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]},"Mon":{"temp":["18.0","21.0","18.0","21.0","18.0"],"time":["06:00","07:30","14:00","21:30","24:00"]},"Tue":{"temp":["18.0","21.0","18.0","21.0","18.0"],"time":["06:00","07:30","14:00","21:30","24:00"]},"Thu":{"time":["06:00","07:30","14:00","21:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]},"Sat":{"time":["06:00","07:30","14:00","21:30","24:00"],"temp":["18.0","21.0","18.0","21.0","18.0"]}}
Wenn man jetzt eine Referenz für default:Kind1 auf eines dieser Profile zeigen läßt:

Code: [Auswählen]

set weekprofiles reference_profile Spätschicht:Kind1 default:Kind1
liefert weekprofile dann für den "Thermostat" "Kind1" effektiv das Spätschichtprofil aus, wenn danach der default-Topic gesetzt wird. Ergo kann man - jetzt übertragen auf deinen Fall - für das "Schlafzimmer" die "Effektiv-Profile" "Auto", "Minimal", "Homeoffice-auto" und "Homeoffice-minimal" anlegen, und dann dem "Eltern-present"-Topic für das Schlafzimmer jeweils eines dieser 4 zuordnen. Dann ändert der allgemeine Wechsel von "Homeoffice" auf "Eltern-present" für das Schlafzimmer nichts.

Klarer?

Nachteil ist nur, dass dann nicht unmittelbar irgendwo außerhalb der Profilanalyse zu erkennen ist, was effektiv zur Anwendung kommt (wenn man mal einen Fehler macht oder so).

Das hört sich vielversprechend an und ich hab es gleich mal ausprobiert. So könnte man mit dem $EVENT "comfort" oder "eco" 2 feste Temperaturen hinterlegen, die in Zimmer A und B völlig unterschiedlich sein können. Super, das hat mir auf alle Fälle weitergeholfen.

Ja, so herum geht natürlich auch. Ich _glaube_, es ist anders herum sogar einfacher: Du legst dich auf eine "Tagtemperatur" fest (z.B. 21.5), und immer, wenn die beim WDT ankommt, macht der daraus dann (beim Absenden des Befehls) dann "day" (oder "eco"), und der Thermostat selbst setzt das dann in "seine" Tagtemperatur um. Das können 22.5 oder 18 Grad sein... Dann kann ein Profil für mehrere Thermostate verwendet werden, ohne die Grunddaten anzufassen (das will man ja (abgesehen von der Umreferenzierung oben) in der Regel eher selten haben).

Was irgendwie auch noch cool wäre, wenn man relative Temperaturangaben machen könnte. Also quasi "$we|09:00|eco+1" oder "!$we|10:00|comfort-2"

An sich ist das eine smarte Idee, allerdings sind relative Angaben in der Tat nicht vorgesehen. ABER: Bei der Ausführung wird das Kommando so an fhem.pl übergeben, dass vermutlich "Set Magic" geht. Prinzipiell alle Temperaturen für einen Thermostat um denselben Wert anheben sollte daher gehen:

Code: [Auswählen]

attr WDT commandTemplate set $DEVICE {($EVENT + 2)}(Müßte man ausprobieren, vermutlich ginge auch beliebiger Perl-Code, aber das wird dann andererseits auch sehr kompliziert...)

(OT: Ist für mich auch eine Gelegenheit, mich mal intensiver damit zu befassen, und ich finde es immer toller, was sich da für Möglichkeiten ergeben...).

[persching]

Also mit all den Infos muss ich jetzt mal an einem konkreten Thermostat rumspielen. So richtig hab ich das mit dem referenzieren noch nicht verstanden, aber ich denke, ich werde da dahinter kommen, wenn ich es versuche umzusetzen.

Erstmal danke für die Inspirationen.

[persching]

Jetzt ist die Euphorie schon wieder ein wenig eingebremst:
1. scheint der Homematic Thermostat im Wohnzimmer zwar dayTemp und nightTemp zu kennen, aber ich bekomme sie per FHEM nicht geschaltet. Laut wiki ändert das wohl nur etwas, wenn man das per Buttons am Thermostat selbst umschaltet.
2. bisher habe ich die weekprofiles immer per Widget verabeitet. Aber in dem Widget habe ich ja nur ein DropDown Menü, das mir die Temperaturen von 5.0-30.0 in 0.5 Grad Schritten bereitstellt. Wie kann ich das sonst noch bearbeiten???

Ich würde gerne Thermostate zu Uhrzeiten zusammenfassen und dann bspw. zu den Uhrzeiten keine Temperaturen vorgeben, sondern "eco" und "comfort". Wieviel Grad das für diesen Thermostat bedeutet würde ich direkt am Thermostat einstellen.

[MadMax-FHEM]

Wie hast du deine Thermostate (HM-CC-RT-DN?) eingebunden?
CUL_HM oder HMCCU?

Wenn mit CUL_HM, dann gibt es (zumindest bei mir) ein set HKT_Clima controlMode day/night

Bei einem WDT (HM-TC-IT-WM-W-EU) wäre es dann im _Climate Kanal.

Gruß, Joachim

[persching]

Wie hast du deine Thermostate (HM-CC-RT-DN?) eingebunden?
CUL_HM oder HMCCU?

Wenn mit CUL_HM, dann gibt es (zumindest bei mir) ein set HKT_Clima controlMode day/night

Bei einem WDT (HM-TC-IT-WM-W-EU) wäre es dann im _Climate Kanal.

Gruß, Joachim

Hallo Joachim,
ja es ist ein HM-CC-RT-DN und er ist per CUL_HM eingebunden. Aber wenn ich dort im _Climate Kanal ein

set HKT_Climate controlMode night

Schicke, dann kommt folgendes:

Code: [Auswählen]

Unknown argument controlMode, choose one of regBulk regSet inhibit peerBulk getConfig burstXmit clear sysTime getRegRaw sign

[MadMax-FHEM]

Hast du wirklich

set HKT_Climate controlMode night

eingegeben?

Naja, du musst schon DEIN Device nehmen!
EDIT: bzw. LESEN!!! Beim Heizkörperthermostat ist es der _Clima Kanal, beim Wandthermostaten ist es der _Climate Kanal!
EDIT: wenn man zum Device/Kanal auf der Weboberfläche geht, sieht man was man setzen kann...

EDIT: habe es eben getestet, geht (bei mir) wunderbar...

Gruß, Joachim