Heating Control: Unterschied zwischen den Versionen
Mitch (Diskussion | Beiträge) |
(WeekdayTimer-Abhängigkeit aktualisiert) |
||
(14 dazwischenliegende Versionen von 6 Benutzern werden nicht angezeigt) | |||
Zeile 1: | Zeile 1: | ||
{{Hinweis|[[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 {{Link2Forum|Topic=100179|LinkText=Testversion - Heating_Control}} und {{Link2Forum|Topic=105521|LinkText=weekprofile und WeekdayTimer gemeinsam nutzen}}}} | |||
{{Hinweis|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 <code>{ Svn_GetFile("contrib/deprecated/98_Heating_Control.pm", "FHEM/98_Heating_Control.pm") }</code>. Weiter wird eine alte Version von WeekdayTimer benötigt: <code>{ Svn_GetFile("contrib/deprecated/98_WeekdayTimer.pm", "FHEM/98_WeekdayTimer.pm") }</code>. 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"}} | |||
{{Infobox Modul | {{Infobox Modul | ||
|ModPurpose=Heizungssteuerung über ein Wochen-Heizprofil | |ModPurpose=Heizungssteuerung über ein Wochen-Heizprofil | ||
|ModType=h | |ModType=h | ||
|ModCmdRef=Heating_Control | |ModCmdRef=Heating_Control | ||
|ModForumArea=Unterstuetzende Dienste | |||
|ModTechName=98_Heating_Control.pm | |ModTechName=98_Heating_Control.pm | ||
|ModOwner= | |ModOwner=Beta-User ({{Link2FU|9229|Forum}}/[[Benutzer Diskussion:Beta-User|Wiki]]) | ||
}} | }} | ||
[[Heating Control]] ist ein | [[Heating Control]] ist ein FHEM-Erweiterungsmodul zur Heizungssteuerung über ein Wochen-Heizprofil. | ||
== Voraussetzungen == | == Voraussetzungen == | ||
Zeile 26: | Zeile 30: | ||
== Anwendungsbeispiele == | == Anwendungsbeispiele == | ||
* Vorstellung einer Lösung im {{Link2Forum|Topic=23783|LinkText= | * Vorstellung einer Lösung im {{Link2Forum|Topic=23783|LinkText=FHEM Forum}}, die [[Heating Control]] und [[HCS]] miteinander kombiniert. | ||
Zeile 32: | Zeile 36: | ||
Die Steuerung der Heizung erfolgt komplett über FHEM, die FHTs laufen alle auf manuell. | Die Steuerung der Heizung erfolgt komplett über FHEM, die FHTs laufen alle auf manuell. | ||
Erweiterung: | 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. | Den Code zum definieren der FHTs/HMs spare ich mir jetzt, das sollte Grundverständnis sein. | ||
Zeile 42: | Zeile 46: | ||
attr HCB group Heizplan | attr HCB group Heizplan | ||
attr HCB room Heizung</pre> | attr HCB room Heizung</pre> | ||
Wobei gilt: <Wochentage 1-7>|<Uhrzeit hh:mm>|<Temperatur in °C> | |||
Den Heizplan kann ich über einen Dummy ein- und ausschalten: | Den Heizplan kann ich über einen Dummy ein- und ausschalten: | ||
Zeile 86: | Zeile 92: | ||
attr HCS_System valveThresholdOn 35 | attr HCS_System valveThresholdOn 35 | ||
define | define Vaillant CUL_HM 123456 | ||
attr | attr Vaillant IODev HMLan | ||
attr | attr Vaillant alias Vaillant Therme | ||
attr Vaillant autoReadReg 4_reqStatus | |||
attr | |||
attr Vaillant devStateIcon on:general_an off:general_aus | 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 group HCS | ||
attr Vaillant icon sani_boiler_temp | 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 room Heizung | ||
attr Vaillant webCmd on:off | attr Vaillant subType switch | ||
attr Vaillant webCmd on:off</pre> | |||
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). | |||
Zeile 155: | Zeile 148: | ||
Diese ECO-Schalter triggere ich auch über das Modul [[PRESENCE]] und Geofancy | 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: | ||
<pre> | <pre> | ||
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()}</pre> | 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</pre> | |||
Zusätzlich trigger ich ECO über die Aussentemperatur. Wird 22 Grad erreicht oder überschritten, wird ECO aktiviert. Unterhalb 22 Grad wieder deaktiviert: | Zusätzlich trigger ich ECO über die Aussentemperatur. Wird 22 Grad erreicht oder überschritten, wird ECO aktiviert. Unterhalb 22 Grad wieder deaktiviert: | ||
Zeile 169: | Zeile 163: | ||
define Aussentemp.Check DOIF ([Wetterstation:temperature] >= "22") (set Sonnenindikator on) DOELSE (set Sonnenindikator off)</pre> | define Aussentemp.Check DOIF ([Wetterstation:temperature] >= "22") (set Sonnenindikator on) DOELSE (set Sonnenindikator off)</pre> | ||
Für meine neuen HM Thermostate musste ich dann noch etwas bzgl. Fenster ändern, da | 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 | 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: | Um das zu umgehen, habe ich eine einfach Abfrage eingebaut: | ||
Zeile 180: | Zeile 174: | ||
Dies soll als "Denkanstoss" dienen. Ich habe mir auch alles zu FHEM aus diesem Forum "gezogen". | Dies soll als "Denkanstoss" dienen. Ich habe mir auch alles zu FHEM aus diesem Forum "gezogen". | ||
Nachbau erlaubt und erwünscht. | Nachbau erlaubt und erwünscht. | ||
{{Todo|Screenshots ergänzen}} | {{Todo|Screenshots ergänzen}} | ||
<!-- Detaillierte Beispiele bitte als eigenen Abschnitt (=== Überschrift ===) einfügen --> | <!-- Detaillierte Beispiele bitte als eigenen Abschnitt (=== Überschrift ===) einfügen --> | ||
== 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 == | == Links == | ||
* {{Link2Forum|Topic=23783|LinkText=Thread zum | * {{Link2Forum|Topic=10011|LinkText=Thread zum Modul}} im FHEM Forum | ||
* {{Link2Forum|Topic=23783|LinkText=Thread zum Anwendungsbeispiel}} im FHEM Forum | |||
* Modulbeschreibung zu [[HCS]] | * Modulbeschreibung zu [[HCS]] | ||
* [http://www.fischer-net.de/hausautomation/fhem/54-fhem-modul-hcs-ueberarbeitet.html HCS Modul] auf fischer-net.de | * [http://www.fischer-net.de/hausautomation/fhem/54-fhem-modul-hcs-ueberarbeitet.html HCS Modul] auf fischer-net.de | ||
[[Kategorie:Heizungssteuerung]] |
Aktuelle Version vom 25. Oktober 2021, 08:49 Uhr
{ 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 | |
---|---|
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! |
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