Heating Control: Unterschied zwischen den Versionen

Heating_Control
Zweck / Funktion
	Heizungssteuerung über ein Wochen-Heizprofil
Allgemein
Typ	Hilfsmodul
Details
Dokumentation	EN / DE
Support (Forum)	Unterstuetzende Dienste
Modulname	98_Heating_Control.pm
Ersteller	Beta-User (Forum /Wiki)
	Wichtig: sofern vorhanden, gilt im Zweifel immer die (englische) Beschreibung in der commandref!

Aktuelle Version vom 25. Oktober 2021, 08:49 Uhr

Heating Control ist deprecated und wird ab featurelevel 6.0 nur noch in contrib verfügbar sein. Es wird empfohlen, die betreffenden Devices auf WeekdayTimer umzustellen, wobei dieser seit 11/2019 auch die Option bietet, das jeweils aktive Temperaturprofil von weekprofile zu beziehen, was die Verwaltung mehrerer Temperaturprofile für ein Thermostat - z.B. je nach aktuellem Anwesenheitsszenarium - deutlich vereinfachen kann. Mehr dazu in Testversion - Heating_Control und weekprofile und WeekdayTimer gemeinsam nutzen

Seit 18.01.2020 ist das Modul aus dem Modul-Verzeichnis entfernt. Wer das Modul unbedingt weiter nutzen will, kann das Modul aus contrib laden, z.B. mit { Svn_GetFile("contrib/deprecated/98_Heating_Control.pm", "FHEM/98_Heating_Control.pm") }. Weiter wird eine alte Version von WeekdayTimer benötigt: { Svn_GetFile("contrib/deprecated/98_WeekdayTimer.pm", "FHEM/98_WeekdayTimer.pm") }. Um die Heating_Control-Devices wieder zu aktivieren, muß FHEM anschließend mit der bisherigen fhem.cfg gestartet werden. Danach kann man das entweder so weiter laufen lassen, muss dann aber unbedingt WeekdayTimer, dessen Funktionen intern verwendet wurden von allen künftigen updates ausschließen. Es wird daher empfohlen, diesen Zwischenschritt dazu zu nutzen, die Umstellung auf WeekdayTimer vorzunehmen und dann hinterher Heating_Control wieder aus dem Modulverzeichnis zu löschen. Siehe auch den Abschnitt "Umstellung auf WeekdayTimer"

Heating Control ist ein FHEM-Erweiterungsmodul zur Heizungssteuerung über ein Wochen-Heizprofil.

Voraussetzungen

Keine.

Anwendung

Define

Das Heizprofil wird angelegt mit

define <name> Heating_Control <device> [<language>] <profile> <command>|<condition>

Attribute

Ausführung

Die Kommandos zur Steuerung werden mit dem Befehl

set <device> (desired-temp|desiredTemerature) <temp>

zum definierten Zeitpunkt an das Gerät gesendet.

Anwendungsbeispiele

Vorstellung einer Lösung im FHEM Forum, die Heating Control und HCS miteinander kombiniert.

Grundsätzlich nutzte ich FHZ1300, FHT8b mit Fensterkontakten an FHEM. Die Steuerung der Heizung erfolgt komplett über FHEM, die FHTs laufen alle auf manuell.

Erweiterung: Mittlerweile migriere ich von FHT auf HM und somit ergeben sich ein paar Änderungen am Code, welche ich hier angefügt habe. Auch nutze ich immer mehr das Modul DOIF, weswegen sich zusätzlich einige Codes geändert haben (allerdings um einiges einfacher).

Den Code zum definieren der FHTs/HMs spare ich mir jetzt, das sollte Grundverständnis sein.

Als erstes Modul meiner Steuerung nutze ich das Modul Heating_Control für jedes Zimmer/jeden FHT/jedes HM:

define HCB Heating_Control FHT_Bad 12345|06:00|22 12345|07:30|19 67|08:30|22 67|10:00|19 18:00|21 22:00|14 (ReadingsVal("HCAutomatik", "state", "") eq "on")
attr HCB alias Bad
attr HCB group Heizplan
attr HCB room Heizung

Wobei gilt: <Wochentage 1-7>|<Uhrzeit hh:mm>|<Temperatur in °C>

Den Heizplan kann ich über einen Dummy ein- und ausschalten:

define HCAutomatik dummy
attr HCAutomatik alias Heizungsautomatik
attr HCAutomatik devStateIcon on:general_an off:general_aus
attr HCAutomatik group Automatik
attr HCAutomatik icon sani_heating_automatic
attr HCAutomatik room Heizung
attr HCAutomatik sortby 1
attr HCAutomatik webCmd on:off

Die neuen HM Theromstate habe ich in eine Structur gepakt

define Heizungsventile structure Heizungen HZ_Bad_Clima HZ_Dachboden_Clima HZ_Flur_unten_Clima HZ_Klo_Clima HZ_Flur_oben_Clima

Hier die Abfrage des Dummys

define HeatingControl.Aktivator DOIF ([HCAutomatik] eq "on") (set HCS_System on) DOELSE (set FHT_.* desired-temp 14.0,set Heizungsventile desired-temp 14.0,set HCS_System off,set Pushover msg 'FHEM' 'Heizplan ausgeschalten')

Bei einer Deaktivierung werden alle FHTs/HMs auf 14 Grad eingestellt und es wird mir zu Info eine Pushnachricht geschickt.

Als nächstes habe ich das Modul HCS integriert:

define HCS_System HCS Vaillant
attr HCS_System alias Vaillant Steuerung
attr HCS_System devStateIcon demand:sani_heating_temp idle:sani_heating_manual off:general_aus
attr HCS_System deviceCmdOff off
attr HCS_System deviceCmdOn on
attr HCS_System event-on-change-reading state,devicestate,eco,overdrive
attr HCS_System icon sani_heating_manual
attr HCS_System idleperiod 5
attr HCS_System interval 5
attr HCS_System loglevel 5
attr HCS_System mode thermostat
attr HCS_System room Heizung
attr HCS_System thermostatThresholdOff 0.5
attr HCS_System thermostatThresholdOn 0.5
attr HCS_System valveThresholdOff 40
attr HCS_System valveThresholdOn 35

define Vaillant CUL_HM 123456
attr Vaillant IODev HMLan
attr Vaillant alias Vaillant Therme
attr Vaillant autoReadReg 4_reqStatus
attr Vaillant devStateIcon on:general_an off:general_aus
attr Vaillant expert 2_full
attr Vaillant firmware 1.6
attr Vaillant group HCS
attr Vaillant icon sani_boiler_temp
attr Vaillant model HM-LC-SW1-BA-PCB
attr Vaillant msgRepeat 1
attr Vaillant peerIDs 00000000,
attr Vaillant room Heizung
attr Vaillant subType switch
attr Vaillant webCmd on:off

Hiermit steuere ich meine Vaillant Heizung potentialfrei über einen HM Empfänger an. Das Relais ist so angeschlossen, dass die Heizung an ist, wenn das Relais abgefallen ist (dies hat den Vorteil, dass auch bei einem Defekt des Empfängers die Heizung funktioniert).

Des weiteren habe ich mir einen "ECO-Script" angelegt (vielen Dank an das Forum für die Hilfe), welcher alle FHTs um 2 Grad runter setzt und zwar von dem im Moment anliegenden Wert:

define HZ.Absenkung dummy
attr HZ.Absenkung alias ECO Mode - Heizungsabsenkung 2 Grad
attr HZ.Absenkung devStateIcon on:general_an off:general_aus
attr HZ.Absenkung group Automatik
attr HZ.Absenkung icon time_eco_mode
attr HZ.Absenkung room Heizung
attr HZ.Absenkung webCmd on:off

Dann habe ich dazu folgendes in meiner 99_myUtils.pm angelegt:

sub ecomode {
 my @FHT=devspec2array("TYPE=FHT");
 foreach(@FHT)
 {
  my $tp = ReadingsVal("$_", "desired-temp", "")-2;
  if (ReadingsVal("$_", "desired-temp", "") > "16") {
   fhem("set $_ desired-temp ".$tp)
  }
 }
} 

sub ecomodeHM {
my @HM_HT=devspec2array("HZ_.*._Clima");
 foreach(@HM_HT)
{
  my $tpHM = ReadingsVal("$_", "desired-temp", "")-2;
  if (ReadingsVal("$_", "desired-temp", "") > "16") {
   fhem("set $_ desired-temp ".$tpHM)
  }
 }
}

Diese ECO-Schalter triggere ich auch über das Modul PRESENCE und Geofancy an. Der "watchdog" wird bei Abwesenheit aktiviert und läuft 30 Minuten. Wenn bis dahin niemand zurück hin, wird ECO aktiviert:

define ECO.Mode.Aktivator DOIF([Anwesenheit] eq "Unterwegs") ({ecomode},{ecomodeHM}) DOELSEIF ([HZ.Absenkung] eq "on" or [Sonnenindikator] eq "on") ({ecomode},{ecomodeHM}) DOELSE ({Heating_Control_SetAllTemps()}
attr ECO.Mode.Aktivator wait 3600

Zusätzlich trigger ich ECO über die Aussentemperatur. Wird 22 Grad erreicht oder überschritten, wird ECO aktiviert. Unterhalb 22 Grad wieder deaktiviert:

define Sonnenindikator dummy
attr Sonnenindikator devStateIcon on:sun27 off:sun7
attr Sonnenindikator group HCS
attr Sonnenindikator icon clear3

define Aussentemp.Check DOIF ([Wetterstation:temperature] >= "22") (set Sonnenindikator on) DOELSE (set Sonnenindikator off)

Für meine neuen HM Thermostate musste ich dann noch etwas bzgl. Fenster ändern, da FHEM beim setzten der Temeratur das Thermostat übersteuert. Somit kann es z.B. vorkommen, dass ein Fenster noch offen ist, wenn FHEM eine neue Temperatur schickt und die Heizung hoch heizt, obwohl das Fenster noch offen ist.

Um das zu umgehen, habe ich eine einfach Abfrage eingebaut:

define Fenster.Status.Bad DOIF ([Fenster_Bad] eq "open") (set HCB disbale) DOELSE (set HCB enable)

Dies soll als "Denkanstoss" dienen. Ich habe mir auch alles zu FHEM aus diesem Forum "gezogen". Nachbau erlaubt und erwünscht.

Todo: Screenshots ergänzen

Umstellung auf Weekdaytimer

Sollte man auf WeekdayTimer umstellen?

Unbedingt, denn selbst, wenn man es wieder zum laufen bekommt (z.B. mit der svn-contrib-Version), ist das nur eine Übergangslösung. Der Heatin_Control-Code wird nicht mehr supporten und es sit jederzeit damit zu rechnen, dass die Kompabilität des Codes mit der aktuellen WeekdayTimer-Version nicht mehr gegeben ist!

Hat das Nachteile?

Nicht wirklich. Es gibt ein paar Punkte, die man wissen sollte:

Heating_Control (HC) nutzt intern zu 80+% WeekdayTimer (WDT)-Code. Alles, was HC konnte, kann WDT auch.

Beide Module enthalten Perl-Kommandos, mit denen man jeweils nur die Devices vom Typ HC oder WDT ansprechen konnte. Da zukünftig dann alles WDT sind, muß man - zum einen dann den Aufruf auf die WDT-Syntax umstellen und - zum anderen die betreffenden "Gruppen" irgendwie auseinanderhalten. Dafür gibt es (vermutlich nur) im WDT das betreffende Attribut.

Hat das Vorteile oder ist das nur Aufwand?

Zum Aufwand: HC nutzt eine (eingeschränkte) WDT-Syntax im define, man kann also die bisherigen Definitionen aus der cfg 1:1 weiterbenutzen, man muß nur den Modulnamen ändern (wie das konkret am einfachsten geht: s.u.). Der effektive Umstellungs-Aufwand ist daher relativ gering, wer unbedingt die alte Aufrufsyntax aus HC beibehalten will, kann das auch über einen eigenen myUtils-Wrapper oä. machen.

Die Umstellung hat dann aber v.a. für bisherige HC-Nutzer auch Vorteile: - Man kann über die Gruppen-Option einfacher Teilgruppen ansprechen, das ganze ist ja nicht auf die Unterscheidung zwischen WDT und (ehemaligen) HC beschränkt... - Vermutlich funktioniert das weekprofile-feature nur mit WDT. Damit kann dann auch das Nebeneinander zwischen vielen HC-Devices für unterschiedliche Szenarien entfallen, man tauscht einfach das betreffende Profil über WDT oder weekprofile aus (bitte ggf. erst mal die commandref konsultieren).

Wie macht man die Umstellung konkret?

a) Check deine Spracheinstellungen: WDT alt war default auf DE eingestellt, WDT heute zieht die Spracheinstellung aus global, wenn sie nicht lokal codiert wurde (was weiter möglich ist). Wichtig ist halt, dass ggf. die "Buchstaben-Tage" auch zur jeweils aktiven Spracheinstellung paßt. Der Entwickler empfielt Umstellung auf nummerische Syntax, also z.B. Di/Tue=>2.

b) Man kann dann entweder das HC-Modul aus dem contrib holen. Macht dann Sinn, wenn alles up-to-date ist und die HC-Devices nicht mehr geladen wurden. Nach dem Kopieren des Modulcodes FHEM neu starten und dann die Umstellungsroutine starten. Zukünftig kann es erforderlich werden, zusätzlich auch den letzten kompatiblen WeekdayTimer-Code aus dem contrib-Verzeichnis zu holen! In diesem Fall ist es einfacher, die betreffenden Konfigurationsabschnitte manuell zu ändern, wie unter c) erläutert!

Dann noch die Aufruf-Frage aus dem alten HC-Modul klären und auf WDT umstellen und checken, ob das Löschen der alten HC-Devices irgendwo anders Nebenwirkungen hat - dies kann z.B. vorkommen, wenn man LightScene nutzt und darin HC anspricht. Das registriert nämlich das Löschen des Geräts und entfernt es dann auch aus der LightScene. Kann man reparieren, indem man die config des Moduls aus einem Backup holt bzw. vorher wegspeichert und dann wieder drüberkopiert.

c) Wer vor dem Umdate mit "list -r TYPE=Heating_Control" eine Teilkopie der Konfiguration rauszieht, kann einfach dann das update machen, in den define/defmod-Anweisungen Heating_Control durch WeekdayTimer ersetzen und sollte dann bei jedem (ehemaligen) HC-Gerät noch ein passendes Gruppen-Attribut setzen. Weiter heißt das Attribut windowSensor im WeekdayTimer WDT_delayedExecutionDevices, die entsprechenden Inhalte können auch hier 1:1 übernommen werden.

d) Wer den setAllTemps-Befehl auch bei WDT genutzt hatte, sollte ggf. dann auch hier die Gruppenfunktion verwenden.

Done...

Was sollte man dann noch tun, wenn man von einer älteren Installation her kommt?

WeekdayTimer bietet einige neue Optionen und defaults: - weekprofile (links s.o.) - Spracheinstellung checken (s.o.) - WDT kann seit einiger Zeit auch Wochentage an $we-Tagen übersteuern, das ist der optionale letzte Parameter "w" in den Schaltzeitpunkten bzw. das "true" bei weekprofile-DEF.

Links

Thread zum Modul im FHEM Forum
Thread zum Anwendungsbeispiel im FHEM Forum
Modulbeschreibung zu HCS
HCS Modul auf fischer-net.de