Dienstag, 4. Januar 2022

Regelung der Luftfeuchtigkeit mit FHEM

In meiner Küche betreibe ich einen Luftentfeuchter der Firma Midea. Das Gerät hat zwar WLAN integriert, es lässt sich aber leider nur über eine proprietäre App steuern. Zudem läuft der Lüfter dauernd. Das ist anscheinend bei neueren Geräten jetzt generell so, weil der Feuchtigkeitssensor auf diese Weise dauernd von der Raumluft umströmt wird. Leider verbraucht der Lüfterbetrieb auf der niedrigsten Stufe bereits 25 W. Ich habe daher eine eigene Regelung auf meinem FHEM-Server angelegt.

An zusätzlichen Geräten verwende ich eine Devolo-Schaltsteckdose und einen kombinierten Temperatur- und Feuchtesensor der Firma Eurotronic. Beide Zusatzgeräte werden über Z-Wave an den FHEM-Server angebunden. Der Luftentfeuchter hat den Vorteil, dass er sich seinen Betriebszustand bei einem Stromausfall merkt. Daher kann man ihn über die Schaltsteckdose ohne Weiteres schalten. Es ist nur wichtig, dass der Entfeuchter auf Dauerbetrieb eingestellt wird.

Das Bild unten zeigt einen Ausschnitt aus dem FHEM-Raum Küche der Gruppe Feuchtigkeit und das Übersichtsdiagramm mit den gemessenen Feuchtigkeitswerten (rot) und dem Schaltzustand der Steckdose (grün) und damit des Luftentfeuchters an.

Regelung der Luftfeuchtigkeit

Ku_Luftfeuchtigkeit ist ein Dummy Device. Es hat nur die Aufgabe, die Luftfeuchtigkeit anzuzeigen. Zusätzlich zu group und room habe ich nur noch das Attribut stateFormat definiert.

Attribute von Ku_Luftfeuchtigkeit

"state %" zeigt den Status - hier die Luftfeuchtigkeit - mit einem angehängten Prozentzeichen an.

Befüllt wird der Dummy mit einem notify, das auf Ereignisse des Feuchtigkeitssensors reagiert.

 

notify zur Aktualisierung der Luftfeuchteanzeige

Die Definition für das notify leitet sich aus den Events ab, die der Sensor liefert.

Screenshot des Event Monitor's für den Sensor Ku_Thermometer

Wenn die Luftfeuchtigkeit gemessen wird, soll der Zahlenwert an den Dummy Ku_Luftfeuchtigkeit übergeben werden. Der Definitionsteil DEF des notify's lautet daher:

Ku_Thermometer:humidity.* set Ku_Luftfeuchtigkeit $EVTPART1

Wenn ein Ereignis des Device's Ku_Thermometer auftritt, das mit dem Ausdruck "humidity" beginnt, dann wird der Status des Dummy's Ku_Luftfeuchtigkeit auf den Wert der Variablen  $EVTPART1 gesetzt. Das Reading des letzten Ereignisses ist in der Variablen $EVENT gespeichert, die einzelnen Teile des Ereignisses in den Variablen $EVTPART0, $EVTPART1, ... In $EVENT steht also "humidity: 62 %", in $EVTPART0 "humidity:", in $EVTPART1 "62" und in $EVTPART2 "%".

Ku_Luftentfeuchter_ein_aus ist ein weiterer Dummy, mit dem die Regelung der Luftfeuchtigkeit ein- und ausgeschaltet werden kann. Hier sind die Attribute des Dummy's:

Attribute von Ku_Luftentfeuchter_ein_aus

devStateIcon definiert das Symbol in der DeviceOverview. "on:taster@red off:taster@blue" bedeutet, dass das Symbol taster rot angezeigt wird, wenn der Zustand des Dummy's "on" ist; das Symbol wird blau, wenn der Zustand "off" ist. Mit dem Attribut setList werden die möglichen Zustände des Dummy's - "on" und "off" - definiert. webCmd erhält den Wert ":". Damit wird verhindert, dass außer dem Tastersymbol in der DeviceOverview auch noch "on" und "off" angezeigt werden.

Das physikalische Device, das den Luftentfeuchter schaltet (der Steckdosenschalter), ist mit Ku_Luftentfeuchter bezeichnet. Das Attribut stateFormat habe ich auf "power" gesetzt, weil mich die Leistungsaufnahme des Entfeuchters interessiert. Weil im Reading power die Leistung bereits als Zahlenwert mit dem Buchstaben "W" für "Watt" gespeichert wird, erübrigt sich eine weitere Formatierung. webCmd wurde wieder auf ":" gesetzt, um zu verhindern, dass in der DeviceOverview "on" und "off" angezeigt werden. Schließlich soll die Regelung ja nur über Ku_Luftentfeuchter_ein_aus aktiviert bzw. deaktiviert werden.

Für den Regelalgorithmus verwende ich das DOIF-Device Ku_Feuchteregelung. Die allgemeine Syntax für DOIF lautet:

define <name> DOIF (<condition>) (<commands>) DOELSEIF (<condition>) (<commands>) DOELSEIF ... DOELSE (<commands>)

Definition des DOIF's 

Wenn das Reading humidity von Ku_Thermometer größer als 60 ist und der Status von Ku_Luftentfeuchter_ein_aus gleich "on" ist, dann wird Ku_Luftentfeuchter eingeschaltet. Das "d1", das hinter humidity steht, gibt an, dass nur der Zahlenwert des Readings auf eine Nachkommastelle genau für den Vergleich verwendet werden soll. Mit der Und-Verknüpfung wird also erreicht, dass der Luftentfeuchter nur eingeschaltet wird, wenn die Regelung eingeschaltet worden ist.

Wenn der erste Teil des DOIF's nicht erfüllt ist, wird die DOELSEIF-Bedingung geprüft: Wenn die Luftfeuchtigkeit unter 55 % fällt oder die Regelung ausgeschaltet worden ist, dann wird Ku_Luftentfeuchter ausgeschaltet.

Mit den beiden Schwellwerten 60 % und 55 % wird eine Hysterese von größer 5 % festgelegt. Damit wird verhindert, dass das System bei kleinen Schwankungen der Luftfeuchtigkeit dauernd ein- und ausschaltet.

Bleibt mir nur noch übrig zu erklären, wie das Tropfensymbol in die Anzeige kommt. Dazu setze ich wieder das Attribut devStateIcon. 

Attribute für Ku_Feuchteregler    

Die Status eines DOIF's werden automatisch mit cmd_1, cmd_2, cmd_... durchnummeriert. Die Definition "cmd_1:humidity@red cmd_2:humidity@green" bedeutet also: Wenn die Bedingung cmd_1 (Luftfeuchtigkeit über 60 % und Regelung eingeschaltet) erfüllt ist, dann zeige das Symbol humidity in Rot an, wenn die Bedingung cmd_2 (Luftfeuchtigkeit unter 55 % oder Regelung ausgeschaltet) gilt, dann zeige das Symbol in Grün an. Die verfügbaren Symbole findet man übrigens in der Detailübersicht zu den Devices über den Link Select icon in der untersten Zeile.

Wie ich zu der Grafik komme, beschreibe ich in einem anderen Beitrag.

 



 

Keine Kommentare:

Kommentar veröffentlichen