Raumklima im Smart Home mit FHEM verbessern: Taupunktoptimiertes Lüften

IM EINSATZ?

Dann schau dir UNSEREN LOXKURS an und profitiere von unserem Wissen!

Hohe Luftfeuchte kann langfristig zu Schimmelbildung führen, was sich nicht nur negativ auf die Bausubstanz, sondern vorallem auch auf die Gesundheit auswirken kann. Aber auch ohne kontrollierte Be- und Entlüftungsregelung lässt sich im Smart Home durch günstige Klimasensoren und intelligentes Lüften die Luftfeuchtigkeit effektiv regulieren und damit das Schimmelrisiko dauerhaft senken.

Was es beim Lüften zu beachten gilt und wie sich in diesem Zusammenhang die automatische Taupunktberechnung in FHEM nutzen lässt, um die idealen Lüftungsintervalle herauszufinden, ist Inhalt des nachfolgenden Blogposts.

Zusammenhang von Temperatur, Luftfeuchte, Taupunkt und Niederschlag

Mithilfe von Klimasensoren lässt sich neben der Temperatur auch die relative Luftfeuchtigkeit einzelner Räume messen und mit Messwerten im Freien in Relation setzen, um ermitteln zu können, ob es gerade sinnvoll ist zu Lüften oder nicht.

Um die Messwerte bei unterschiedlichen Temperaturen miteinander vergleichen zu können, wird jedoch zusätzlich der Taupunkt benötigt, welcher aus Temperatur und relativer Luftfeuchtigkeit errechnet werden kann. Er gibt ab, unterhalb welcher Raumtemperatur die Luftfeuchtigkeit beginnt sich niederzuschlagen.

Hintergrund ist, dass Luft in Abhängigkeit der Temperatur jeweils nur eine gewisse Höchstmenge an Wasserdampf aufnehmen kann. Die relative Luftfeuchtigkeit, die ein Klimasensor gewöhnlich misst, gibt dabei das Verhältnis des momentanen Wasserdampfgehalts zum maximal möglichen Wasserdampfgehalt für die aktuelle Temperatur (und den aktuellen Druck) an.

Das bedeutet im Klartext: Misst der Klimasensor bspw. in einem geschlossenen Raum eine Temperatur von 20 °C und 60 % relative Luftfeuchtigkeit, führt das reine Abkühlen des Raums auf 16,4 °C zu einer Erhöhung der relativen Luftfeuchtigkeit auf 100 %. Das entspricht der maximalen Sättigung der Luft mit Wasserdampf, was gleichzeitig dem Taupunkt entspricht. Sinkt die Temperatur noch weiter ab, schlägt sich der überschüssige Wasserdampf in Form von Wasser nieder, da die Luft bei sinkender Temperatur die Menge des enthaltenen Wasserdampf nicht mehr komplett binden kann.

Dieser Umstand kann gerade bei winterlichen Außentemperaturen und wenig beheizten bzw. belüfteten Kellerräumen mit höherer Luftfeuchtigkeit zu Niederschlag und infolgedessen zu Schimmelbildung führen, sobald die Räme auskühlen und die Taupunkttemperatur längere Zeit unterschritten wird.

Besonders betroffen können dabei schlecht gedämmte Außenwände und Fenster sein, deren Oberflächen kälter sind als die gemessene Raumtemperatur. Auch wenn der Raum durchschnittlich gesehen noch warm genug ist, um den Wasserdampf komplett zu binden, kommt es bei kälteren Oberflächen viel früher zu Niederschlag, wie man auch an nachfolgende Tabelle sieht.

Temperatur Änderung relative Luftfeuchte Taupunkt maximale Feuchte absolute Feuchte
20 °C Referenzwert 80 % 16,4 °C 17,3 g/m3 13,8 g/m3
19 °C – 1 °C 85 % 16,4 °C 16,3 g/m3 13,8 g/m3
18 °C – 2 °C 90 % 16,4 °C 15,4 g/m3 13,8 g/m3
17 °C – 3 °C 96 % 16,4 °C 14,5 g/m3 13,8 g/m3
16 °C – 4 °C 100 % + 1 % Niederschlag 16 °C 13,6 g/m3 13,6 g/m3 + 0,2 g/m3 Niederschlag
15 °C – 5 °C 100 % + 8 % Niederschlag 15 °C 12,8 g/m3 12,8 g/m3 + 1 g/m3 Niederschlag
14 °C – 6 °C 100 % + 14 % Niederschlag 14 °C 12,1 g/m3 12,1 g/m3 + 1,7 g/m3 Niederschlag
13 °C – 7 °C 100 % + 22 % Niederschlag 13 °C 11,3 g/m3 11,3 g/m3 + 2,5 g/m3 Niederschlag
12 °C – 8 °C 100 % + 29 % Niederschlag 12 °C 10,7 g/m3 10,7 g/m3 + 3,1 g/m3 Niederschlag

Um dem Niederschlag entgegenzuwirken, gilt es die Luftfeuchtigkeit in den betroffenen Räumen durch intelligentes Lüften zu verringern, um gleichzeitig auch den Taupunkt zu senken und damit das Niederschlagsrisiko zu verringern. Dazu kann der ermittelte Taupunkt im Raum mit dem Taupunkt im Außenbereich verglichen werden. Ist der Taupunkt außen geringer als innen, macht es Sinn zu lüften, da sich der höhere Taupunkt innen durch den Luftaustausch an den geringeren Taupunkt außen angleicht. Ein sinkender Taupunkt im Raum ist dann natürlich gut, da auch kältere Bereiche des Raums bei geringer Temperatur dann weniger Niederschlag bilden.

Zusammengefasst kann das Schimmelrisiko durch zwei Faktoren verringert werden:

  • Zuführung von Luft mit geringerer Taupunkttemperatur
  • Aufheizen des Raums, um die Differenz zwischen Raumtemperatur und Taupunkttemperatur zu erhöhen

Benötigte Komponenten

Gemessen werden die benötigten Messwerte bspw. mit dem HomeMatic Temperatur-/Luftfeuchtesensor, innen (Affiliate-Link), der neben der Temperatur auch die relative Luftfeuchtigkeit einzelner Räume messen und mit den Messwerten im Außenbereich, z.B. ermittelt über den an der Nordseite angebrachten HomeMatic Temperatur-/Feuchte-Sensor, außen (Affiliate-Link), in Relation setzt.

In nachfolgendem Fall wird für die Ermittlung der Außen-Messwerte eine HomeMatic-Wetterstation (Affiliate-Link) genutzt, welche bereits im Blogpost HomeMatic FHEM-Wetterstation per UDP in Loxone integrieren vorgestellt wurde.

Automatische Berechnung des Taupunkts per FHEM

Die Berechnung des Taupunkts ist zwar kein Hexenwerk, aber dennoch nicht trivial. Auf wetterochs.de gibt es die Formeln und einen einfachen Taupunktrechner, mit dem man etwas herumspielen kann, um ein Gefühl für die Zusammenhänge zu bekommen.

Praktisch bei der Nutzung von FHEM ist, dass ein fertiges Modul namens dewpoint (Englisch für Taupunkt) bereits existiert. Es übernimmt die Berechnung des Taupunkts und ergänzt Klimasensoren automatisch um das gleichlautende Reading “dewpoint”, welches auch im Status (“state”) angezeigt werden kann. Dafür notwendig sind lediglich zwei Einträge in der fhem.cfg.

Mit dem Eintrag

define dewpointToAllDeviceReadings dewpoint dewpoint .* temperature humidity dewpoint

werden alle Devices, die bereits mit den Readings temperature und humidity ausgestattet sind, zusätzlich um das Reading dewpoint ergänzt.

FHEM Wetterstation Reading dewpoint

Weiterhin werden mit dem Eintrag

define dewpointToAllDeviceStates dewpoint dewpoint .* T H D

alle Devices, die als Status temperature und humidity in der Form “T: 25.1 H: 57” besitzen mit dem zusätzlichen Statuswert dewpoint erweitert.

FHEM Klimasensor Status dewpoint

Wer – wie ich – auch noch andere Devices mit dem Reading “dewpoint” versorgen möchte (hier BZ.KlimaClimate), welche die gemessene Temperatur nicht standardmäßig in das Reading “temperature” speichern, sondern stattdessen in das Reading “measured-temp”, kann die Berechnung auch manuell über nachfolgenden Code anstoßen, welcher in die fhem.cfg eingefügt wird.

attr BZ.KlimaClimate userReadings dewpoint { my $dp;; my $temperature = ReadingsVal($name,"measured-temp",0);; my $humidity = ReadingsVal($name,"humidity",0);; my $A = 17.2694;; my $B = ($temperature > 0) ? 237.3 : 265.5;; my $es = 610.78 * exp( $A * $temperature / ($temperature + $B) );; my $e = $humidity/ 100 * $es;; if ($e == 0) { Log 1, "Error: dewpoint() e==0: temp=$temperature, hum=$humidity";; return 0 } my $e1 = $e / 610.78;; my $f = log( $e1 ) / $A;; my $f1 = 1 - $f;; if ($f1 == 0) { Log 1, "Error: dewpoint() (1-f)==0: temp=$temperature, hum=$humidity";; return 0 } $dp = $B * $f / $f1;; $dp = sprintf("%.1f",$dp) }

Zusätzlich muss dann lediglich noch das Device, in diesem Fall “BZ.KlimaClimate”, angepasst werden.

So wird dann auch das Homematic Funkthermostat (Affiliate-Link) mit dem gewünschten Reading “dewpoint” versorgt.

FHEM Thermostat measured-temp dewpoint

Regelbestimmung für intelligentes Lüften

Jetzt, da alle Klima-Devices mit dem passenden “dewpoint”-Reading zur Bestimmung des Taupunkts ausgestattet sind, kann über einen Dummy pro Raum visualisiert werden, ob das Lüften gerade sinnvoll ist oder nicht.

Nachfolgend wird für das Badezimmer ein Dummy namens “BZ.Lueften” definiert, welcher später Auskunft darüber gibt, ob gelüftet werden sollte.

define BZ.Lueften dummy
attr BZ.Lueften room Badezimmer
attr BZ.Lueften event-on-change-reading state

Der Dummy “BZ.Lueften” zeigt später folgende Statusmeldungen an:

  • open – Fenster sollte geöffnet werden
  • opened – Fenster kann geöffnet bleiben
  • close – Fenster sollte geschlossen werden
  • closed – Fenster kann geschlossen bleiben

Dadurch können praktischerweise zwei Informationen in einem Staus zusammengeführt werden. So ist ersichtlich, ob das Fenster gerade geöffnet oder geschlossen ist und gleichzeitig, ob dieser Zustand weiterhin angestrebt oder geändert werden sollte. Das entspricht zwar nicht dem “FHEM-Standard”, welcher gewöhnlich nur “open” und “closed” als Zustände kennt, erscheint mir in diesem Zusammenhang jedoch praktikabel.

Jedes Mal, wenn das Device “BZ.KlimaClimate” ein neues Event erzeugt, wird der Status von “BZ.Lueften” geprüft und – falls notwendig – aktualisiert. Neben den oben angesprochenen Klimasensoren wird hier noch ein Fenstersensor “BZ.Fenster.Geschlossen” genutzt, um die Information zu nutzen, ob das Fenster gerade geschlossen (closed) bzw. nicht geschlossen (open) ist.

Verwendet wird in diesem Beispiel der vielfach bewährte optische HomeMatic Fensterkontakt (Affiliate-Link), der auch schon im Artikel Howto: Elektrische Rolläden per FHEM und HomeMatic automatisieren näher beschrieben wurde.

Mit der Variable “dewpoint_buffer” wird die Differenz zwischen aktueller Temperatur im Badezimmer und der berechneten Taupunkttemperatur ermittelt. Als Schwellwert wird 3 °C verwendet, was als “Temperaturpuffer” genutzt wird, um den Niederschlag im Badezimmer an kälteren Stellen (Fenster, Außenwände) zu verhindern.

define BZLueften notify (BZ.KlimaWeather.*|BZ.Fenster.Geschlossen:(open|closed)) {\
 my $temperature_bz = ReadingsVal("BZ.KlimaWeather", "temperature", "-1");;\
 my $dewpoint_bz = ReadingsVal("BZ.KlimaWeather", "dewpoint", "-1");;\
 my $temperature_te = ReadingsVal("TE.Wetterstation", "temperature", "-1");;\
 my $dewpoint_te = ReadingsVal("TE.Wetterstation", "dewpoint", "-1");;\
 my $dewpoint_buffer = $temperature_bz - $dewpoint_bz;;\
 my $fenster_bz = ReadingsVal("BZ.Fenster.Geschlossen", "state", "undefined");;\
 {fhem ("\
 setreading BZ.Lueften temperature_bz $temperature_bz;;\
 setreading BZ.Lueften dewpoint_bz $dewpoint_bz;;\
 setreading BZ.Lueften temperature_te $temperature_te;;\
 setreading BZ.Lueften dewpoint_te $dewpoint_te;;\
 setreading BZ.Lueften dewpoint_buffer $dewpoint_buffer;;\
 setreading BZ.Lueften fenster_bz $fenster_bz\
 ")};;\
 if ($fenster_bz eq "closed" && $dewpoint_buffer >= 3) {\
 fhem ("set BZ.Lueften closed")\
 }\
 elsif ($fenster_bz eq "closed" && $dewpoint_buffer < 3 && $dewpoint_te <= $dewpoint_bz) {\
 fhem ("set BZ.Lueften open")\
 }\
 elsif ($fenster_bz eq "closed" && $dewpoint_buffer < 3 && $dewpoint_te > $dewpoint_bz) {\
 fhem ("set BZ.Lueften closed")\
 }\
 elsif ($fenster_bz eq "open" && $dewpoint_buffer >= 3) {\
 fhem ("set BZ.Lueften opened")\
 }\
 elsif ($fenster_bz eq "open" && $dewpoint_buffer < 3 && $dewpoint_te <= $dewpoint_bz) {\
 fhem ("set BZ.Lueften opened")\
 }\
 elsif ($fenster_bz eq "open" && $dewpoint_buffer < 3 && $dewpoint_te > $dewpoint_bz) {\
 fhem ("set BZ.Lueften close")\
 }\
 else {\
 fhem ("set BZ.Lueften kA")\
 }\
}

Die Logik beinhaltet sieben Regeln, um je nach Umgebungsvariablen den Status des Dummies “BZ.Lueften” zu setzen. Gleichzeitig erhält der Dummy noch verschiedene Readings der betreffenden Sensoren, um alle relevanten Informationen auf einmal einsehen und kontrollieren zu können.

FHEM BZ.Lueften Dummy

Update vom 29.08.2015: Christian wollte wissen, wie man das Ganze am besten umsetzt, wenn zwei Fensterkontakte (hier: BZ.Fenster1.Geschlossen und BZ.Fenster2.Geschlossen) in einem Raum genutzt werden. Spontan würde ich das so machen, dass die Variable fenster_bz in Abhängigkeit von fenster1_bz und fenster2_bz gesetzt wird. Sofern beide Fenster geschlossen sind, wird auch die Variable fenster_bz auf geschlossen gesetzt, ansonsten auf open. Damit wird dann die bereits oben genutzte Abfragelogik gefüttert:

define BZLueften notify (BZ.KlimaWeather.*|BZ.Fenster(1|2).Geschlossen:(open|closed)) {\
 my $temperature_bz = ReadingsVal("BZ.KlimaWeather", "temperature", "-1");;\
 my $dewpoint_bz = ReadingsVal("BZ.KlimaWeather", "dewpoint", "-1");;\
 my $temperature_te = ReadingsVal("TE.Wetterstation", "temperature", "-1");;\
 my $dewpoint_te = ReadingsVal("TE.Wetterstation", "dewpoint", "-1");;\
 my $dewpoint_buffer = $temperature_bz - $dewpoint_bz;;\
 my $fenster1_bz = ReadingsVal("BZ.Fenster1.Geschlossen", "state", "undefined");;\
 my $fenster2_bz = ReadingsVal("BZ.Fenster2.Geschlossen", "state", "undefined");;\
 if ($fenster1_bz eq "closed" && $fenster2_bz eq "closed") {\
 my $fenster_bz = closed\
 };;\
 else {\
 my $fenster_bz = open\
 };;\
 {fhem ("\
 setreading BZ.Lueften temperature_bz $temperature_bz;;\
 setreading BZ.Lueften dewpoint_bz $dewpoint_bz;;\
 setreading BZ.Lueften temperature_te $temperature_te;;\
 setreading BZ.Lueften dewpoint_te $dewpoint_te;;\
 setreading BZ.Lueften dewpoint_buffer $dewpoint_buffer;;\
 setreading BZ.Lueften fenster_bz $fenster_bz\
 ")};;\
 if ($fenster_bz eq "closed" && $dewpoint_buffer >= 3) {\
 fhem ("set BZ.Lueften closed")\
 }\
 elsif ($fenster_bz eq "closed" && $dewpoint_buffer < 3 && $dewpoint_te <= $dewpoint_bz) {\
 fhem ("set BZ.Lueften open")\
 }\
 elsif ($fenster_bz eq "closed" && $dewpoint_buffer < 3 && $dewpoint_te > $dewpoint_bz) {\
 fhem ("set BZ.Lueften closed")\
 }\
 elsif ($fenster_bz eq "open" && $dewpoint_buffer >= 3) {\
 fhem ("set BZ.Lueften opened")\
 }\
 elsif ($fenster_bz eq "open" && $dewpoint_buffer < 3 && $dewpoint_te <= $dewpoint_bz) {\
 fhem ("set BZ.Lueften opened")\
 }\
 elsif ($fenster_bz eq "open" && $dewpoint_buffer < 3 && $dewpoint_te > $dewpoint_bz) {\
 fhem ("set BZ.Lueften close")\
 }\
 else {\
 fhem ("set BZ.Lueften kA")\
 }\
}

Pushover-Benachrichtigung einrichten

Je nach Statusänderung des Dummies “BZ.Lueften” kann dann eine entsprechende Mitteilung bspw. per Pushover verschickt werden mit der Information, ob es sinnvoll ist zu lüften bzw. wann das Fenster besser wieder geschlossen werde sollte, um die Niederschlagsgefahr zu minimieren.

Sofern noch nicht geschehen, wird der Pushover-Dienst erst einmal in der fhem.cfg definiert.

#PushoverJay
define PushoverJay Pushover au5SMKWXRJey7ApemEaLSg21Xxxxxx u4zDygNRGFbQUSmcxXj6fGsWJxxxxx

Danach fehlen noch die passenden Pushover-Befehle, die je nach Statusänderung des Dummies auslösen:

define BZLueftenPushover notify BZ.Lueften.* {\
 my $bzlueften = ReadingsVal("$NAME", "state", "-1");;\
 my $temperature_bz = ReadingsVal("$NAME", "temperature_bz", "-1");;\
 my $dewpoint_bz = ReadingsVal("$NAME", "dewpoint_bz", "-1");;\
 if ($bzlueften eq "open") {\
 fhem ("set PushoverJayFHEM msg 'Badezimmer $temperature_bz °C' 'Bitte Fenster öffnen\nTaupunkt $dewpoint_bz °C muss gesenkt werden' '' 0 ''")\
 }\
 elsif ($bzlueften eq "close") {\
 fhem ("set PushoverJayFHEM msg 'Badezimmer $temperature_bz °C' 'Bitte Fenster schließen\nTaupunkt $dewpoint_bz °C wird sonst erhöht' '' 0 ''")\
 }\
}

Und schon wird eine Pushover-Mitteilung verschickt, sobald sich der Status entsprechend ändert.

FHEM Pushover Bitte fenster oeffnen AppleWatch

Aus meinem täglichen Leben

Lange Zeit habe ich nach einem praktikalen Weg gesucht, um auf Basis der Temperatur und Luftfeuchtigkeit intelligent Lüften zu können. Der reine Vergleich der Luftfeuchtigkeit, wie ich es im Artikel Bessere Raumluftqualität durch FHEM und Homematic-Adapter beschrieben hatte, schien mir schon damals nicht wirklich schlüssig. Denn kaum unterscheidet sich die Außentemperatur von der Raumtemperatur, sind die relativen Luftfeuchtigkeitswerte nicht mehr miteinander vergleichbar.

Mit der Taupunktberechnung in FHEM habe ich nun endlich die perfekte Lösung gefunden, um für den nächsten Winter gerüstet zu sein. Danke an dieser Stelle an die FHEM-Community, welche das passende dewpoint-Modul bereits im Jahr 2013 konzipiert und umgesetzt hat.

Als nächstes wird dann noch der CO2-Wert genutzt, um mit der Information zur aktuellen Luftqualität das Lüften noch ein wenig smarter zu machen.

Neben der oben beschriebenen Pushover-Funktion werde ich nun auch noch den Lüfter im Bad automatisch ansteuern, um erhöhte Luftfeuchtigkeit schnellstmöglich wieder abzuführen, die vorallem beim Duschen entsteht und schnell zu Niederschlag führt. Dazu nutze ich evtl. direkt das Modul “dewpoint fan“, welches den Taupunkt automatisch zur Ansteuerung des Lüfters einbezieht.

Weiterhin werde ich noch die Heizung ansteuern, um gerade im Winter notfalls die Temperatur erhöhen zu können, was zwar nicht den Taupunkt senkt, aber dennoch dafür sorgt, dass die Luftfeuchtigkeit bei erhöhter Temperatur nicht mehr niederschlägt. Hier könnte sich auch das Modul “dewpoint alarm” anbieten.

Zur Not kann man im Keller auch einen Luftentfeuchter (Affiliate-Link) einsetzen, welcher über einen HomeMatic Funk-Zwischenstecker (Affiliate-Link) mit FHEM angesteuert wird.

In Kürze werde ich das Ganze auch einmal mit mehreren günstigen Klimasensoren ausgiebig testen, für die ein JeeLink zum Einsatz kommt. Christoph hat darüber bereits im Artikel FHEM mit JeeLink: Luftfeuchte und Temperatur zum Low-Cost-Tarif messen berichtet. Die Sensoren kosten nur knapp 15 Euro und liefern valide Messwerte, die für diesen Einsatzzweck perfekt geeignet sind…

101 Kommentare
  1. Klasse! Wollte mir sowas auch schon bauen, jetzt muss ich es nur “übernehmen” 🙂

    Mich interessiert gerade jedoch am meisten: Wie bekommt Ihr das FHEM-Logo in die Pushover-Nachricht???

    1. Hi C0mmanda,
      du loggst dich mit deinem Account auf pushover.net ein und wählst deine Anwendung im Menüpunkt “Your Applications” aus. Ganz oben klickst du dann auf “Edit or Delete Application” und hier kannst du dann unter “New Icon” ein Logo hochladen. Das Logo hab ich einfach gegoogelt und dann noch etwas per Photoshop freigestellt, um den Rand wegzubekommen.

      Grüße
      Jörg

    2. Hm, das habe ich soweit auch eingerichtet und das Icon wird mir auch in der Pushover-App angezeigt, jedoch nicht in der Pushnachricht selbst wie auf dem Screenshot 🙁

      Muss mir das wohl mal genauer ansehen 🙂

      Danke!

    3. Der Screenshot stammt von der Apple Watch. Auf dem iPhone wird mir das Icon in der Pushnachricht bspw. auch nicht angezeigt.

    1. Hi Michael,
      danke für dein Feedback! Freut mich zu hören, dass dir der Inhalt weiterhilft.
      Ich möchte selbst auch spätestens bis zum Winter alle noch fehlenden Räume mit der Logik ausstatten. Aber bis dahin dauert es ja glücklicherweise noch etwas… 🙂

      Grüße
      Jörg

  2. Wieder ein sehr cooler Beitrag. Das werde ich auf jeden Fall umsetzen. Ich habe übrigens die günstigen Temperatur/Feuchtigkeitssensoren seit längerem im Einsatz. Funktionieren super und ich habe z.B. Im Bad einen Entfeuchter über die Werte gesteuert. Bislang halt nur so PI mal Daumen. Werde jetzt das ganze mal mit DEWPOINT und Lüften unterstützen.

  3. Hallo Jörg,
    danke für den Beitrag. Ich habe mich sofort daran gemacht es in mein System zu übernehmen.
    Ich habe aber ein Verständnisproblem mit dem 1.Fall vom BZLueften notify.

    Wenn das Fenster geschlossen ist und der dewpoint_buffer > 3 soll in deinem Programm das Fenster geöffnet werden.

    Ich finde gerade in diesem Fall, sollte das Fenster geschlossen bleiben. Der Taupunkt ist doch in diesem Fall weit unterhalb der Temperatur im Raum. Der Raum hat das perfekte Raumklima und müsste erst sehr weit abkühlen bevor es zum Niederschlag kommt.
    Oder habe einen Denkfehler?

    Gruß
    Stefan

    1. Hi Stefan,
      das hast du alles richtig verstanden. Meine Logik sieht aktuell eben vor, dass so oft gelüftet werden sollte, wie nur möglich. Aber wie du schon richtig anmerkst, kann es auch Sinn machen das zu ändern und den Wert der ersten if-Abfrage von “open” auf “closed” zu setzen. Da bin ich selbst auch noch am testen, was am geschicktesten ist. Bin schon gespannt auf den kommenden Winter, da wird sich sicher zeigen, welche Logik am besten geeignet ist.

      Grüße
      Jörg

    1. Hi Chrisian,
      guter Punkt, den sicherlich auch andere umsetzen möchten! Habe den Blogpost deshalb entsprechend ergänzt, sodass die Logik auch mit mehr als einem Fenster in einem Raum funktionieren sollte (siehe Update von heute). Hoffe das hilft dir weiter.

      Grüße
      Jörg

  4. Dank dieses Beitrages kann ich endlich meine Raumklima Überwachung optimieren. Da ich das Modul Dewpoint bisher nicht kannte habe ich mich bisher laienhaft an Temperatur und relativer Luftfeuchtigkeit orientiert, was allerdings nicht immer optimal/zufriedenstellend funktioniert hat. Jetzt werde ich deinen Ansatz mit meinem kombinieren, um für mich die optimale Lösung zu bauen.
    Ich werde mich hauptsächlich am Dewpoint orientieren und zusätzlich die Außentemperatur berücksichtigen, um keine warme Luft (im Sommer) in die Wohnung zu bekommen. Im Winter soll dann natürlich nur entsprechend kurz gelüftet werden, hier habe ich bereits eine Pushover-Benachrichtigung, die ich nun anpassen werden. Zudem möchte ich nur lüften, wenn die relative Luftfeuchtigkeit einen bestimmten Wert überschreitet.
    Stefans Hinweis zur ersten Fall würde ich bestätigen, denn dann steigt ja die relative Luftfeuchtigkeit im Raum, was eigentlich nicht gewünscht ist.

    1. Hallo Sören,

      könntest du mir deinen Code mal zukommen lassen? Ich habe ganz frisch die Sensoren installiert und oben beschriebenen Code implementiert. Aber mir geht es wie dir: wenn’s nach der Programmlogik geht, wird es im Bad saukalt 😉
      Danke und lieber Gruß,
      Kristof

  5. Hallo Jörg,
    Danke für die schnelle Umsetzung! Leider bekomme ich jetzt eine Fehlermeldung: BZLueften return value: Global symbol “$fenster_bz” requires explicit package name at (eval 19905) line 15.
    Gruß
    Christian

  6. Hallo Jörg, ich habe bisher fast nur Loxone air Temperatur und Luftfeuchtigkeits Sensoren, nur ein MySensors selbstbau Sensor und eine Homematic Wetterstation in Fhem.
    Gibt es eine Möglichkeit, von Loxone die Werte der Sensoren per udp an Fhem zu senden, diese einzubinden um den Taupunkt zu bestimmen?

    Gruss

    Marco

    1. Hi Marco,
      vor dieser Frage stehe ich auch gerade. Am besten wäre ja, wenn Loxone selbst den Taupunkt aus Temperatur und Luftfeuchte berechnen würde. Eigentlich auch komisch, dass eine so zentrale Funktion nicht standardmäßig implmenetiert ist. Könnte man evtl. mal ein Ticket aufmachen und um diese Funktion bitten. In der Zwischenzeit müsste man aber wohl ein kleines Loxone-Progrämmchen in PicoC schreiben. Dafür fehlt mir jedoch (noch) das notwendige Wissen.
      Man könnte die Sensorwerte von Loxone aber auch recht einfach per TCP-Mitteilungen an FHEM senden. Wie das funktioniert, habe ich im Blogpost Integration: Date zwischen Loxone und FHEM austauschen beschrieben. Dann könnte man es wieder per UDP von FHEM an Loxone zurückschicken und entsprechend visualisieren.
      Grundsätzlich könnte man die Daten an FHEM auch per UDP senden (so wie von dir angemerkt), jedoch ist das dann nicht so wirklich performant, da FHEM dann immer jede Sekunde nachsehen müsste, ob ein neues Paket eingegangen ist. Für diesen Anwendungsfall würde das wohl ausreichen, für schnelle Schaltwechsel wäre das aber sicherlich nicht sonderlich praktikabel. Evtl. geht das auch besser, das habe ich mir aber auch noch nicht genauer angesehen, da es mit TCP von Loxone nach FHEM bisher super funktioniert.

      Grüße
      Jörg

  7. Hi Jörg
    Ich habe mal eben ein Ticket aufgemacht!………Aber das kann ja noch etwas dauern!
    Leider sind die Mitarbeiter nicht die schnellsten!
    Ich versuche mal etwas über den Formel Baustein zu basteln!

    Gruss

    Marco

    1. Hi Marco,
      die Berechnung ist doch einigermaßen komplex. Sobald du es geschafft hast, würde ich mich freuen, wenn du deine Erkenntnisse teilst.

      Grüße
      Jörg

  8. Hallo Jörg,

    ich setze einen Homematic Fenster-Drehgriffkontakt ein und habe das Problem, dass das Reading fenster_bz undefined ist.
    Ich habe die Änderung wie folgt gemacht:
    define BZLueften notify (BZ.TF.*|BZ.FK.Rechts:(open|closed)) {\

    Kannst Du mir eventuell bei meinem Problem helfen?

    1. Hi Dirk,
      ich würde den Fenster-Drehgriffkontakt aus der Config entfernen und versuchen neu anzulernen. Evtl. ist das Reading dann korrekt.

      Grüße und viel Erfolg
      Jörg

  9. Hallo Jörg,

    Ich habe deinen neuen Code nochmal getestet. Leider bekomme ich folgende Fehlermeldungen:
    PERL WARNING: “my” variable $fenster_bz masks earlier declaration in same scope at (eval 2228) line 35.
    PERL WARNING: “my” variable $dewpoint_buffer masks earlier declaration in same scope at (eval 2228) line 35.
    PERL WARNING: “my” variable $dewpoint_te masks earlier declaration in same scope at (eval 2228) line 35.
    PERL WARNING: “my” variable $dewpoint_bz masks earlier declaration in same scope at (eval 2228) line 35.

    Gruß
    Christian

  10. Hallo Jörg,

    Ich habe das Problem mit zwei Fensterkontakten mit einem Dummy (BZ.Fenster_Status) gelöst.

    define BZ.Fenster_Status dummy
    attr BZ.Fenster_Status event-on-change-reading state
    attr BZ.Fenster_Status room Badezimmer
    define BZ.Fenster_open_closed notify (BZ.Fenster(1|2).Geschlossen:(opened|closed)) {\
    my $fenster1_bz = ReadingsVal(“BZ.Fenster1.Geschlossen”, “state”, “undefined”);;\
    my $fenster2_bz = ReadingsVal(“BZ.Fenster2.Geschlossen”, “state”, “undefined”);;\
    if ($fenster1_bz eq “closed” && $fenster2_bz eq “closed”) {\
    fhem (“set BZ.Fenster_Status closed”)}\
    elsif ($fenster1_bz eq “open” || $fenster2_bz eq “open”) {\
    fhem (“set BZ.Fenster_Status open”)}\
    }

    Gruß
    Christian

    1. Hi Christian,
      das freut mich zu hören. Der von mir bereitgestellte Code hat demnach nicht funktioniert, richtig? Weil dann muss ich nochmal nachbessern.

      Grüße
      Jörg

  11. Hab gerade mal LaCrosse-Temperatur-Luftfeuchte-Sensoren (TX29DTH-IT) in Betrieb genommen. Leider scheint

    define dewpointToAllDeviceReadings dewpoint dewpoint .* temperature humidity dewpoint

    hier nicht zu funktionieren. Es wird einfach kein dewpoint ins Reading der Devices geschrieben. Hat jemand das selbe Problem oder weiss, wie man es behebt?

    Grüße
    Jörg

    PS: Über den manuellen Weg

    attr UG.WZ.Klima userReadings dewpoint { my $dp;; my $temperature = ReadingsVal($name,”temperature”,0);; my $humidity = ReadingsVal($name,”humidity”,0);; my $A = 17.2694;; my $B = ($temperature > 0) ? 237.3 : 265.5;; my $es = 610.78 * exp( $A * $temperature / ($temperature + $B) );; my $e = $humidity/ 100 * $es;; if ($e == 0) { Log 1, “Error: dewpoint() e==0: temp=$temperature, hum=$humidity”;; return 0 } my $e1 = $e / 610.78;; my $f = log( $e1 ) / $A;; my $f1 = 1 – $f;; if ($f1 == 0) { Log 1, “Error: dewpoint() (1-f)==0: temp=$temperature, hum=$humidity”;; return 0 } $dp = $B * $f / $f1;; $dp = sprintf(“%.1f”,$dp) }

    funktioniert es übrigens 1a.

    1. Hi Denis,
      danke für deinen Hinweis. Dann werde ich wohl nochmal genauer recherchieren müssen, woran das Problem liegt.

      Grüße
      Jörg

  12. Hallo Jörg,

    auch ich habe das ganze mit den TX29DTH-IT Sensoren umgesetzt. Dewpoint wird auch hier angezeigt.

    Ein “Problem” habe ich jetzt aber. Laut deiner Anleitung scheint in meinem Schlafzimmer dauergelüftet werden zu müssen. Ist das mit dem 3°C dewpoint buffer wirklich richtig? Dieser löst es aus.

    Hier einmal die aktuelle Situation:

    Schlafzimmer
    T: 19.5 H: 51 D: 9.1

    Dewpoint buffer hier also bei 10,4, er muss ja unter 3 sein damit geschlossen werden kann.
    Kann mir nicht so ganz vorstellen, dass das passt. Habe ich falsch “abgeschrieben”? Oder wird der dewpoint falsch berechnet?

    Gruß
    Marcel

    1. Hi Marcel,
      welcher Lüft-Status (Bezeichnung) wird denn genau angezeigt? Eigentlich sollte der Status auf “opened” stehen, was bedeutet, dass das Fenster geöffnet ist und auch geöffnet bleiben kann. Das heisst aber auch, dass das Fenster genauso gut auch geschlossen werden darf.

      Grüße
      Jörg

  13. Hallo Jörg,

    danke für Deine Antwort!

    Genau, wenn das Fenster offen ist steht er auf Status “opened” wenn das Fenster zu ist auf Status “open”.
    Das hat sich bisher noch nicht geändert, egal wie lange ich das Fenster offen habe. Abends wirds mir dann so langsam aber mit offenem Fenster zu kalt. 😉

    Aktueller Status im Schlafzimmer z.B.:
    20.8 H: 45 D: 8.4
    Dewpoint Buffer also bei 12.4.
    Habe den dewpoint buffer bisher noch nicht unter 9 gesehen. Wenn dieser über 3 ist, muss laut Deinem Skript geöffnet werden. Habe ich da vielleicht etwas falsch gemacht?

    Grüße
    Marcel

    1. Hi Marcel,
      ok, denke ich kann dir weiterhelfen. Mein Algorithmus ist aktuell sehr “lüftungsfreudig”. Liegt wohl daran, dass ich den Code noch im Sommer erstellt hatte und dieses Phänomen nicht auftrat. 🙂
      Alles, was du ändern musst, ist den bestehenden Codeschnipsel

      if ($fenster_bz eq “closed” && $dewpoint_buffer >= 3) {\
      fhem (“set BZ.Lueften open”)\
      }\

      umzuändern in

      if ($fenster_bz eq “closed” && $dewpoint_buffer >= 3) {\
      fhem (“set BZ.Lueften closed”)\
      }\

      und alles sollte so funktionieren, wie du es dir wünscht.

      Grüße und viel Erfolg
      Jörg

      PS: Man könnte jetzt natürlich noch die Außentemperatur in Relation zur Innentemperatur setzen und jeweils bei Über- bzw. Unterschreitung definierter Schwellwerte entsprechend “lüftungsfreundlich” oder “-feindlich” sein. Ich werde mir das Ganze aber sicherlich noch genauer ansehen je weiter der Herbst voranschreitet. 🙂

  14. Hallo Jörg,

    erstmal vielen Dank, dass du diesen sehr informativen Blog betreibst. Dadurch war es mir möglich ein funktionierendes FHEM System auf einem Raspberry Pi 2 einzurichten.
    Ich habe diesen Artikel hier auch genutzt, um das Thema taupunktoptimiertes Lüften zu realisieren.

    Allerdings habe ich eine andere Logik genutzt:
    1.) Es wird festgestellt, ob Lüftungsbedarf besteht:
    – dew_buff > 3 –> Kein Lüftungsbedarf
    – dew_buff Lüftungsbedarf

    2.) Es wird überprüft, ob die Möglichkeit zum Lüften besteht:
    – dew_te >= dew_bz –> Lüften nicht möglich!
    – dew_te Lüften möglich

    Kombiniert wird das bei mir (unabhängig vom Fensterstatus) wie folgt:

    a) Kein Lüftungsbedarf und keine Lüftungsmöglichkeit –> Schließen!
    b) Kein Lüftungsbedarf, aber Lüftungsmöglichkeit –> Egal
    c) Lüftungsbedarf, aber keine Lüftungsmöglichkeit –> Heizen!
    d) Lüftungsbedarf und Lüftungsmöglichkeit –> Öffnen!

    Im Code sieht das wie folgt aus (Nur die If Bedingungen):
    if ($dewpoint_buffer > 3 && $dewpoint_te >= $dewpoint_wz) {\
    fhem (“set WZ.Lueften Schließen!”)\
    }\
    elsif ($dewpoint_buffer > 3 && $dewpoint_te < $dewpoint_wz) {\ fhem ("set WZ.Lueften Egal")\ }\ elsif ($dewpoint_buffer <= 3 && $dewpoint_te >= $dewpoint_wz) {\
    fhem (“set WZ.Lueften Heizen!”)\
    }\
    elsif ($dewpoint_buffer <= 3 && $dewpoint_te < $dewpoint_wz) {\ fhem ("set WZ.Lueften Öffnen!")\ }\ else {\ fhem ("set WZ.Lueften kA")\ }\ } @ Marcel: Es muss nicht geöffnet werden, aber es kann geöffnet werden. Viele Grüße Max

    1. Sorry, klappt nicht.
      @ Jörg: Kannst du das vielleicht korrigieren? So kann man damit ja leider nichts anfangen…. Oder wie kann ich Code eingeben? Dein Blog verschluckt immer die Hälfte. 😉

    2. Also ich habe deinen Code jetzt mal manuell reinkopiert. Woran es liegt, dass es bei dir nicht direkt geklappt hat, verstehe ich gerade leider nicht. Welchen Browser hast du genutzt? Wobei irgendwas stimmt immer noch nicht.. hmmm

      Grüße
      Jörg

    3. Hi Jörg,
      benutze Firefox (40.0.3), gerade eben habe ich das Update auf 41.0.1 gemacht.

      Aber man erkennt ja an a) – d) wie ich es in FHEM realisiert habe. 😉

      Grüße
      Max

  15. Hallo Jörg.
    Ich habe Deinen Code auch umgesetzt. Eine Pushbenachrichtigung erhalte ich aber immer nur dann, wenn der Fensterkontakt geöffnet/geschlossen wird und nicht, wenn die Temperaturen, bzw. Status sich ändert. Das heißt, wenn ich morgens nach dem Duschen das Fenster öffne, ist das auch OK, aber über Tag sollte ich es irgendwann wieder schliessen und bekomme dazu keine Push.
    Woran könnte das liegen?

    1. Hi Andreas,
      das liegt schlicht und einfach daran, dass mein Beispielcode die von dir angedachte Logik nicht enthält. Hier musst du selbst Hand anlegen und den bestehenden Code entsprechend erweitern.

      Grüße und viel Erfolg
      Jörg

      PS: Wenn du mir erklärst, wie du dir das genau vorstellt (was soll wann passieren), kann ich mich auch einmal daran versuchen und den Code ergänzen.

    2. Hi Jörg.
      Danke für die Antwort.
      Ich stelle es mir so vor, dass wenn das Fenster geöffnet/geschlossen wird eine Pushmeldung rausgeht (Ist-Zustand und funktioniert). Wenn aber sich das Lüften nicht mehr lohnt, dann eine Pushmeldung kommt, dass das Fenster geschlossen werden kann, d.h.eine Pushmeldung kommt, ohne mein aktives verändern des Fensterstatus. Ich hoffe, Du verstehst mein anliegen.

      Gruß
      Andreas

    3. Hi Andreas,
      die Pushmitteilungen beim Öffnen/Schließen des Fensters sollten eigentlich recht einfach möglich sein:

      define BZFensterOpenPushover notify BZ.Fenster.Geschlossen:open {fhem (“set PushoverJayFHEM msg ‘Badezimmer Fenster’ ‘Fenster geöffnet’ ” 0 ””)

      define BZFensterClosedPushover notify BZ.Fenster.Geschlossen:closed {fhem (“set PushoverJayFHEM msg ‘Badezimmer Fenster’ ‘Fenster geschlossen’ ” 0 ””)

      Bzgl. deiner zweiten Anforderung wird es schon kniffliger. Welche Bedingung(en) soll(en) denn explizit erfüllt sein, dass sich ein “Lüften nicht mehr lohnt”?
      Ich habe übrigens auch vor künftig einen CO2-Sensor mit in die Logik einzubeziehen, um die aktuelle Luftqualität als weiteren Parameter zu nutzen. Daneben macht natürlich auch die Berücksichtigung des Temperaturunterschieds (Innen-Außen) Sinn, damit der Raum nicht auskühlt. Vermutlich ging deine Anfrage in diese Richtung, oder?
      So oder so wird die Reihe (der Blogpost ist ja aktuell lediglich der erste Teil, siehe Titel) fortgesetzt, sobald ich wieder etwas mehr Zeit finde.

      Grüße
      Jörg

    4. Hi Jörg. Die Push bei Statusänderung Fenster habe ich.
      Ist es nicht möglich, das der BZ.Lueften Dummy seinen “state” ändert und dann eine Meldung rausgibt? Er nimmt doch alle Werte auf und gibt dann die Info “open,opened,close,closed”, wodurch dann eine Push gesendet wird. Evtl. über ein “at” zeitlich antriggern?
      Gruß
      Andreas

  16. Hallo Jörg,

    okay habe das geändert. Nur ändern können hätte ich es direkt selber, es soll ja sinnvoll bleiben. Mich interessiert daher auch der Sinn dahinter. Wieso jetzt einmal von open auf closed? Du hattest dir dabei ja schon was gedacht.

    1. Ich nochmal hallo Jörg,

      Gibt es eigentlich kein editieren bei den Beiträgen?

      Habe mir den Code noch einmal angeschaut. Jetzt wird der Status mit ziemlicher Sicherheit immer closed bei geschlossenem und opened bei geöffnetem Fenster sein. Macht ja auch irgendwie keinen Sinn, oder? Möchte ja ganz gerne wissen, wann ich öffnen und wann ich schließen soll.

      Wie gesagt habe ich meinen dewpoint_buffer noch nie unter 3 gesehen, bewegt sich bei mir immer so um 8-10. Da scheint noch etwas nicht ganz zu passen.

      Viele Grüße
      Marcel

    2. Hi Marcel,
      je nach Vorliebe kann der Code angepasst werden. Was sinnvoll ist, wird sich wohl von Anwendungsfall zu Anwendungsfall unterscheiden. Wenn du den Sinn verstehen willst, musst du dir die Regeln genauer anschauen und nachvollziehen, was in welchem Fall passiert und warum.
      Im speziellen Fall sollte das Fenster eben geöffnet werden, sobald der Taupunktpuffer größer als 3°C ist. Hintergrund war dabei schlicht, dass primär nur die Schimmelbildung im Raum verhindert werden sollte. Sobald der Puffer also groß genug ist, kann man ruhig lüften und läuft nicht Gefahr, dass es schimmelt. Deine Intention war dann eine andere und ich habe den Code entsprechend angepasst, dass bei einem Puffer größer 3°C das Fenster geschlossen bleiben kann. Das macht rein aus Sicht des Puffers nicht mehr und nicht weniger Sinn.
      Und um auf deine andere Frage einzugehen: Der Puffer von 3 war lediglich ein Testwert von mir, der nicht in Stein gemeiselt ist. Mittlerweile habe ich diesen je nach Raum auch schon angepasst bzw. versuche immer noch die jeweilgs passenden Werte zu ermitteln. Passe ihn einfach an, so wie es bei dir Sinn macht. Das gilt im Grunde für alle meine Code-Beispiele. Das sind nur Vorschläge/Denkanstöße, die jeder gerne weiterentwickeln und natürlich auch per Kommentar teilen bzw. zur Diskussion stellen darf.

      Grüße
      Jörg

    3. Hallo Jörg,

      danke für die ausführliche Info. Dann habe ich das einfach falsch verstanden. Es ist also nur ein Denkanstoß, danke.

      Viele Grüße
      Marcel

  17. Hallo,

    hab das hier auch mal mit hilfe von 2 TX29DTH-IT versucht nur leider bekomme ich bei BZ.Lueften keine reading zusammen.

    define BZLueften notify LaCrosse_32.* {
    my $temperature_bz = ReadingsVal(“LaCrosse_32”, “temperature”, “-1”);
    my $dewpoint_bz = ReadingsVal(“LaCrosse_32”, “dewpoint”, “-1”);
    my $temperature_te = ReadingsVal(“LaCrosse_06”, “temperature”, “-1”);
    my $dewpoint_te = ReadingsVal(“LaCrosse_06”, “dewpoint”, “-1″);
    my $dewpoint_buffer = $temperature_bz – $dewpoint_bz;
    {fhem (”
    setreading BZ.Lueften temperature_bz $temperature_bz;
    setreading BZ.Lueften dewpoint_bz $dewpoint_bz;
    setreading BZ.Lueften temperature_te $temperature_te;
    setreading BZ.Lueften dewpoint_te $dewpoint_te;
    setreading BZ.Lueften dewpoint_buffer $dewpoint_buffer;
    “)};
    if ($dewpoint_buffer > 3 && $dewpoint_te >= $dewpoint_bz) {\ fhem (“set BZ.Lueften Schließen!”)\ }
    elsif ($dewpoint_buffer > 3 && $dewpoint_te < $dewpoint_bz) {\ fhem ("set BZ.Lueften Egal")\ }
    elsif ($dewpoint_buffer = $dewpoint_bz) {\ fhem (“set BZ.Lueften Heizen!”)\ }
    elsif ($dewpoint_buffer <= 3 && $dewpoint_te < $dewpoint_bz) {\ fhem ("set BZ.Lueften Öffnen!")\ }
    else {\ fhem ("set BZ.Lueften kA")\ }\ }

    Danke

  18. Hallo Jörg, bisher hatte ich das Projekt auf Eis gelegt. Ich hatte 2 Prüfungen und habe mich mit Mysensors Multisensoren TempLuxMotion oder Motion Co2, Z-wave und den Dimmerstatus eines Homematic Aktor im Lichtbaustein in Loxone beschäftigt! Wobei ich den Status nicht hin bekomme, da der Lichtbaustein keinen Analogen Eingang hat!
    Ich wollte es so probieren wie es hier beschrieben ist.

    Wenn ich etwas Zeit finde werde ich es in Angriff nehmen!

    1. Danke für die Info! Ich werde mich demnächst mal mit PicoC auseinandersetzen, evtl. bekomme ich die Taupunktberechnung ja direkt in Loxone hin. Loxone selbst sieht das Thema jedenfalls als “spezielle Anwendung” (siehe Antwort auf meinen Kommentar im Loxone Blog), sodass hier wohl mit keiner Hilfe zu rechnen ist. Werde Bescheid geben, sobald ich etwas Vorzeigbares habe.

      Grüße
      Jörg

      PS: Vielleicht hilft dir ja der Baustein “EIB-Dimmer” weiter, dieser hat analoge Inputs.

    2. Also quick and dirty geht es in Loxone recht einfach über einen normalen Formelbaustein, zumindest für Temperaturen über 0 °C. Aber das sollte ja für den Innenbereich vollkommen ausreichen. Als Grundlage habe ich die DEWPOINT-Formel hier genutzt.
      Einfach Temperatur an AI1 und relative Luftfeuchte an AI2 des Loxone Formel-Bausteins hängen und als Formel

      (243,04*(ln(I2/100)+(17,625*I1)/(243,04+I1)))/(17,625-ln(I2/100)-((17,625*I1)/(243,04+I1)))

      verwenden.
      Als Output steht an AQ dann die Taupunkttemperatur zur Verfügung. Habe noch nicht viel getestet, sieht aber spontan alles korrekt aus. Von der Berechnung per PicoC-Programm habe ich mich erstmal verabschiedet, da laut Loxone Config nur (die ersten) acht Programme vom Loxone Miniserver verarbeitet werden. Da sollte man sich die Programm-Ressourcen für wichtigere Dinge reservieren.

      Grüße
      Jörg

    3. Ja das mit den 8 PiconC ist nicht so toll, zumal ich schon 4 benutze! 2 Für Farbwechseler und 2 für Mi-Light Bridges!
      Danke für den Hinweis mit dem EIB-Dimmer einzeln klappt das ja, nur in Kombination mit verschiedenen Lichtszenen leider nicht wirklich! Im Loxforum findet sich dazu auch nur, dass es bei KNX auch nicht klappt. Ich hoffe, dass bald ein Nano AIR Dimmer kommt.
      Und vielen Dank für den quick und dirty.
      Auf mein Ticket kam nur die Antwort, dass ich die Sensor Werte natürlich über eine Formel weiterverarbeiten kann!

      P.S.
      Als ich auf Euren Blog aufmerksam geworden bin, habe ich meine Frau davon überzeugt, dass ich in den nächsten 2 Jahren (stand 02/15) eine Systemauswahl für das geplante Eigenheim testen werde! Nur irgendwie ist das aus dem Ruder gelaufen, aber nicht mehr wegzudenken! xD

      Grüße
      Marco

    4. Hi Marco,
      bin gerade auch am Technik-Grobkonzept unseres angedachten Hauses. Dazu werde ich sicherlich mehrere Blogposts schreiben. Da ist dann bestimmt auch etwas für dich mit dabei, da ich viele Dinge umsetzen möchte. Dazu gehören Loxone, KNX, Onewire, DMX, Mobotix, FHEM, Anbindung kontrollierte Be- und Entlüftung, Haustürsteuerung, etc… 🙂

      Grüße
      Jörg

    5. Hallo Jörg,

      ich hab beim stöbern im Loxwiki das hier gefunden! Scheint interessant!
      Den Luftdruck messe ich mit dem Arduino (Link)!

      Gruss

  19. Hallo Jörg,

    ich habe mit viel Begeisterung gemäß Eurer Anleitung meinen RPi in Betrieb genommen und als FHEM-Server konfiguriert. Seither bastele ich im Rahmen meiner Möglichkeiten an meinem Smart Home herum. Leider habe ich zwar durchaus Programmierkenntnisse, aber eben nur im Visual Basic und SQL-Umfeld und bin weder mit den berühmt berüchtigten Regular Expressions noch mit Perl vertraut.
    Daher war ich sehr dankbar über deinen Beitrag zum taupunktoptimierten Lüften. Allerdings tut das bei mir nicht so, wie ich mir das vorstelle.
    Ich habe mir mal ein paar Gedanken zur Logik gemacht und bin zu folgendem Ergebnis gekommen, das sich doch vielleicht mit DOIF halbwegs elegant lösen lassen müsste. Weil ich das nicht richtig kann, formulier ich’s mal in Meta-Sprache.

    Geräte:
    – KlimaInnen (mit Temp, Feuchte, Taupunkt)
    – KlimaAussen (mit Temp, Feuchte, Taupunkt)
    – Fenster

    Eingangsparameter:
    – Wohlfühltemperaturbereich: minTemp, maxTemp (z.B. 20°C, 22°C)
    – Wohlfühlfeuchte: minFeuchte, maxFeuchte (z.B. 40%, 60%)
    – optional Meldezeitraum (z.B. Mo-Fr 05:45-06:45, 17:00-22:00, Sa-So 09:00-22:00)
    – optional BinAnwesend (ja = ich bin daheim – z.B. Schalter umgelegt, Handy im WLAN, …)

    Meldelogik:

    optFeuchte = (minFeuchte + maxFeuchte) / 2
    optTemp = (minTemp + maxTemp) / 2

    IF ((jetzt IN Meldezeitraum) AND (BinAnwesend = wahr)) THEN

    Meldetext = „“

    ##Fenster ist auf

    #Der Feuchte-Gehalt der Außenluft ist nicht geringer als der der Innenluft
    IF ((Fenster = auf) AND (KlimaInnen.Taupunkt – KlimaAussen.Taupunkt <= 0) AND (KlimaInnen.Feuchte >= optFeuchte)) THEN Meldetext = „Außenluft ist zu feucht – Fenster schließen!“

    #Der Feuchte-Gehalt der Außenluft ist noch niedriger als die eh schon trockene Raumluft
    IF ((Fenster = auf) AND (KlimaInnen.Taupunkt – KlimaAussen.Taupunkt > 0) AND (KlimaInnen.Feuchte <= optFeuchte)) THEN Meldetext = „Außenluft zu trocken – Fenster schließen!“ #Draußen ist es heiß und drinnen soll es kühl bleiben IF ((Fenster = auf) AND (KlimaInnen.Temp >= optTemp) AND (KlimaAussen.Temp – KlimaInnen.Temp >= 1)) THEN Meldetext = „Es wird zu warm im Raum – Fenster schließen!“

    #Draußen ist es kalt und drinnen soll es warm bleiben und der Taupunkt darf nicht zu nah an die Innentemperatur kommen
    IF ((Fenster = auf) AND ((KlimaInnen.Temp <= minTemp) AND (KlimaAussen.Temp – KlimaInnen.Temp <= -1)) OR (KlimaInnen.Temp – KlimaInnen.Taupunkt <=3)) THEN Meldetext = „Es wird zu kalt im Raum – Fenster schließen!“ ##Fenster ist zu #Der Feuchte-Gehalt der Außenluft ist niedriger als der der zu feuchten Innenluft IF ((Fenster = zu) AND (KlimaInnen.Temp – KlimaInnen.Taupunkt > 3) AND (KlimaInnen.Taupunkt – KlimaAussen.Taupunkt > 0) AND (KlimaInnen.Feuchte > maxFeuchte)) THEN Meldetext = „Trockene Außenluft hereinlassen – Fenster öffnen!“

    #Der Feuchte-Gehalt der Außenluft ist höher als der der zu trockenen Innenluft
    IF ((Fenster = zu) AND (KlimaInnen.Taupunkt – KlimaAussen.Taupunkt < 0) AND (KlimaInnen.Feuchte < minFeuchte)) THEN Meldetext = „Feuchte Außenluft hereinlassen – Fenster öffnen!“ #Taupunkt ist sicher entfernt von der Kondensation, drinnen ist es zu heiß, draußen ist es kühler IF ((Fenster = zu) AND (KlimaInnen.Temp – KlimaInnen.Taupunkt > 3) AND (KlimaInnen.Temp > maxTemp) AND (KlimaAussen.Temp – KlimaInnen.Temp <0)) THEN Meldetext = „kühle Außenluft hereinlassen – Fenster öffnen!“

    #von draußen könnte warme Luft rein, die Raumluft ist zu kalt
    IF ((Fenster = zu) AND (KlimaAussen.Temp – KlimaInnen.Temp >0) AND (KlimaInnen.Temp < minTemp)) THEN Meldetext = „warme Außenluft hereinlassen – Fenster öffnen!“ IF Meldetext <> „“ THEN hier wäre noch ein Gedanke, dass der jeweilige „Alarmzustand“ für mehr als 5 Minuten gelten muss, damit z.B. nicht bei jedem Stoßlüften im tiefen Winter sofort die „zu kalt!“-Meldung kommt. Geht doch irgendwie bei DOIF, oder?!

    END IF # in Meldezeit und anwesend

    Lässt sich das mit DOIFs halbwegs einfach lösen? Könnt ihr mir da ein Stück weiterhelfen?
    Und vor allem: Wie findet ihr die Logik?

    Gruß,
    Kristof

    1. Hi Kristof,
      danke für deinen Input! Sieht spontan machbar aus, wobei ich mich erstmal in deine Logik reindenken muss. Werde mich kommende Woche damit beschäftigen. Update folgt.

      Grüße
      Jörg

  20. Uups, ich sehe gerade, dass meine schöne Formatierung flöten ging.
    Daher nochmal die Grundstruktur:
    Äusere IF-Schleife mit “in Meldezeitraum” und “anwesend”
    Meldetext auf “”
    je 4 Fälle für Fenster auf oder Fenster zu
    Wenn das länger als 5 Minuten gilt, dann eine Nachricht auf’s Handy schicken (mache ich z.B. mit Telegram, klappt prima).

    Gruß,
    Kristof

  21. Hallo meintechblog,

    Sehr schöner Artikel, @Jörg du schriebst vom Hausbau, wann geht es los?

    Bin auch gerade am Sanieren und benötige entsprechende Intressante Artikel 😉
    Sensoren und Aktoren werden hauptsächlich in KNX umgesetzt, KNX Sensoren geben mir auch die Ist Temp. hier setze ich die Glastaser von MDT ein. Heizungsaktor – Stellmotor – auf die FBH, HM Heizkörperventile für die Flachheizkörper.

    Für die Taupunktbestimmung würde ich gerne OneWire Sensoren integrieren und für die Fenster Reedkontakte, die auf die Binäreingänge KNX laufen.

    Bin mir noch unsicher wo ich überall zusätzlich OneWire einsetze, Estrich für die FBH, Außen?

    Kenne mich momentan zwar gut aus in Thema KNX, bin aber neu im FHEM, war hier und in anderen Blogs, Forums etc. immer nur stiller Leser.

    Also wie gesagt bin gespannt auf die Artikel!!

    Umsetztung bei mir, KNX – FHEM – (Loxone, Openhab, IPsymcom) – IPcam mit NAS und Surveillance Station 6.3, Smappe oder Mbus.
    Anzuschließende Endgeräte:
    -Sonos, Panasonic TV, Afts, LG TV
    -Heizungserneuerung (Gibt es hier zu von euch gute Erfahrung aus sicht von OpenTherm zb.? oder direkt integration wie zb. Viessmann Vitogate auf KNX, FHEM?)

    –weiter so–!

    1. Hi,
      der Hausbau geht praktisch jetzt los, zumindest schon einmal virtuell per CAD und Co.
      Angedacht ist, dass das Fertighaus von Weiss in 14-15 Monaten schlüsselfertig steht. Bis dahin muss noch viel geplant werden, gerade auch deswegen, da ich jede Menge Smart-Home-Kram umsetzen möchte. Da ich eine Mischung aus verschiedenen Lösungen/Standards realisieren möchte, wird das sicher nicht ganz trivial. Habe schon tausende Ideen im Kopf, die ich in den nächsten Wochen und Monaten – gerne auch zur Diskussion – auf dem Blog veröffentlichen möchte. Input vom Elektroprofi könnte ich dabei natürlich besonders gebrauchen.
      Mit der Frage, welcher Sensoren man nutzen und am sinnvollsten platzieren kann bzw. wo man Kabel dafür vorsieht, beschäftige ich mich auch gerade intensiver.
      Bzgl. Heizungsstuerung mit OpenTherm habe ich hingegen spontan keine Erfahrung, sorry. In Sachen RPi, FHEM, Loxone und technischem Schnickschnack kann ich aber sicherlich weiterhelfen.
      Gerne können wir uns aber kurzschließen, um jeweils vom Wissen des anderen zu profitieren. Gerade in Sachen Elektroinstallation und CAD bräuchte ich auch etwas Unterstützung. 🙂

      Viele Grüße
      Jörg

  22. Hallo Jörg,
    ich lese nun seit drei Monaten auf deinen Blogs hin und her und bedanke mich für die schönen Erklärungen. Ich bin noch nicht lange unter der FHEM Gemeinde, aber lerne von Tag zu Tag …

    Nun aber zu meinem Problem:
    Kannst du mir folgende Zeile genau erklären? Ich besitze einen FS20 FHT 80TF. Der Status ist z.B. “state Closed”

    define KueLueften notify (Kue.Temp.*|Kue.Fenster.Window:(Open|Closed))

    Folgende verstehe ich:
    – definieren KueLueften der auf Änderungen reagiert bei Änderungen von Kue.Temp oder Kue.Fenster
    -was bedeutet hinter dem Doppelpunkt (Open|Closed) ?

    Bei mir steht leider immer “fenster_kue undefined”

    Kannst du es mir erklären?

  23. Problem ist gelöst, bei einem FHT 80TF muss der Code folgendermaßen heißen:

    “define KueLueften notify (Kue.Temp.*|Kue.Fenster.state:(Open|Closed))”

    usw.

  24. Hallo Jörg,

    habe das Script folgendermassen abgeändert und bei mir kommt im LogFile folgende Fehlermeldung.

    2015.11.25 09:49:44 3: BAD_EG_Lueften_notify return value:
    Unknown command my, try help.
    Unknown command my, try help.
    Unknown command my, try help.
    Unknown command my, try help.
    Unknown command my, try help.
    Unknown command {fhem, try help.
    Unknown command “)}, try help.
    Unknown command if, try help.

    angepasstes Script:

    (HM_TemperaturFeuchteBadEG.*|Wetter.*)

    my $temperature_bz = ReadingsVal(“HM_TemperaturFeuchteBadEG”, “temperature”, “-1”);
    my $dewpoint_bz = ReadingsVal(“HM_TemperaturFeuchteBadEG”, “dewpoint”, “-1”);
    my $temperature_te = ReadingsVal(“Wetter”, “temperature”, “-1”);
    my $dewpoint_te = ReadingsVal(“Wetter”, “dewpoint”, “-1”);
    my $dewpoint_buffer = $temperature_bz – $dewpoint_bz;

    {fhem
    (“setreading BAD_EG_Lueften temperature_bz $temperature_bz;
    setreading BAD_EG_Lueften dewpoint_bz $dewpoint_bz;
    setreading BAD_EG_Lueften temperature_te $temperature_te;
    setreading BAD_EG_Lueften dewpoint_te $dewpoint_te;
    setreading BAD_EG_Lueften dewpoint_buffer $dewpoint_buffer;
    “)};
    if ($dewpoint_buffer >= 3)
    { fhem (“set BAD_EG_Lueften on”) }
    elsif ($dewpoint_buffer < 3 && $dewpoint_te <= $dewpoint_bz)
    { fhem ("set BAD_EG_Lueften on") }
    elsif ($dewpoint_buffer $dewpoint_bz)
    { fhem (“set BAD_EG_Lueften off”) }
    else { fhem (“set BAD_EG_Lueften kA”)
    } }

    Wo liegt mein Fehler

  25. Hi, das mit dem Taupunkt finde ich ganz interessant, wäre für mich aber eher eine Spielerei…
    Umsetzen wollte ich das trotzdem mal, der Wand-Thermostat gibt die Temperatur aber über “measured-temp” raus, also habe ich den Code folgendermassen angepasst:

    define dewpointToAllDeviceReadings dewpoint dewpoint .* (measured-temp|temperature) humidity dewpoint
    Leider wird trotzdem nur mein normaler Temp/Feuchte Sensor mit dem Taupunkt ausgestattet, eine Idee an was es liegen könnte?

  26. Wow interessanter Beitrag. Ich bin noch relativ neu im umgang mit Fhem und finde deine Beiträge immer sehr lesenswert, vielen Dank dafür.

    Da ich noch keine Fensterkontakte habe, habe ich mich erstmal auf die Anzeige des Dewpoints beschränkt. In den Readings taucht dieser auch schön auf….aber mit

    define dewpointToAllDeviceStates dewpoint dewpoint .* T H D
    alle Devices, die als Status temperature und humidity in der Form “T: 25.1 H: 57” besitzen mit dem zusätzlichen Statuswert dewpoint erweitert.

    habe ich meine Probleme, denn der “D” wird einfach nicht bei Status hinzugefügt. Eine Idee woran es liegen könnte?

    1. Hey Jörg, ich hatte nach stundenlangen google’n die Lösung gefunden. Also damit bei den Technoline Temperatur/Feuchtigkeit Sensoren, der DewPoint im Status angezeigt wird muss folgendes gesetzt werden

      attr doDewpoint 1

  27. Sehr schöner Artikel und es funktioniert auch alles soweit. Allerdings ist es bei mir irgendwie nicht praktikabel wie ich finde. Ich habe das Ganze für das Schlafzimmer und das Bad eingerichtet. Für das Bad habe ich schon länger eine Pushover Warnung eingebaut, wenn das Bad unter 14°C fällt. Ich habe nun mal gewartet, wann dieser Code mir sagt, dass ich das Fenster schließen soll. Bei 11°C hatte ich heute Morgen keine Lust mehr. Im Schlafzimmer das Gleiche. Ich habe den Raum bis auf 14°C auskühlen lassen bei komplett offenem Fenster. Auch hier keine Meldung, dass ich es wieder schließen soll. ich finde die Räume kühlen so viel zu stark aus bei den Temperaturen draußen, was dann wieder Heizkosten verursacht. Soll das so sein oder kann man da was an den Werten ändern, so dass es früher eine Meldung zum Schließen des Fensters gibt? Alternativ würde ich das für mich sonst so abändern, wenn Temperatur X oder eben der passende Taupunkt erreicht ist, dass dann die Meldung zum Schließen kommt.

    1. Hi Sebastian,
      das Beispiel im Blogpost soll lediglich das generelle Vorgehen verdeutlichen und erhebt inhaltlich keinen Anspruch auf Vollständigkeit. Du kannst das natürlich so abändern, wie es für dich passt. Ich werde mich auch bald mehr mit sinnvollen Szenarien im Rahmen eines Kundenprojekts auseinandersetzen und vermutlich auch darüber berichten. Evtl. ist da ja auch was Passendes für dich dabei.

      Grüße
      Jörg

  28. Schade, jetzt habe ich den Code dahin gehend geändert, dass die Fensterkontakte nicht überprüft werden….aber fhem produziert nur Fehlermeldungen

  29. Das Problem hatte ich auch erst. In dem Code steht BZ.KlimaWeather, daher bin ich auch davon ausgegangen, das die werte im Weather Channel der Sensoren sind. Bei mir wird in den Thermometern aber im im Weather Channel auch kein dewpoint D angezeigt. Allerdings wird dieser im Thermometer selber angezeigt. Sprich bei mir im Code heisst es nicht Bad_Thermomether_Weather sondern nur Bad_Thermometer.

  30. Hi Jörg,

    kannst du bitten den Beitrag dahingehend korrigieren, dass Lüften bei “$dewpoint_buffer >= 3)” nicht korrekt ist …

    bin selbst auf copy+past Fehler hereingefallen 😉 Bin selbst drüber gestolpert und hab’s grade in den Kommentaren gelesen …

    Meldung meiner Heizung: (Ist natürlich quatsch)
    ‘Badezimmer 18.6 °C’ ‘Bitte Fenster öffnen Taupunkt 13.0 °C muss gesenkt werden’.

    Ansonsten vielen Dank für deinen Beitrag – echt Topp!

    1. Hi Jonas,
      stimmt, in Verbindung mit dem Pushover ist das wirklich Quatsch.
      Habe den Befehlsteil von

      if ($fenster_bz eq “closed” && $dewpoint_buffer >= 3) {\
      fhem (“set BZ.Lueften open”)\

      geändert in

      if ($fenster_bz eq “closed” && $dewpoint_buffer >= 3) {\
      fhem (“set BZ.Lueften closed”)\

      Grüße
      Jörg

  31. Hallo Jörg, bin gerade dabei. über die Kellertrocknung nachzudenken und habe eine generelle Frage: Mich interessiert beim Luftaustausch die absolute Luftfeuchigkeit der hinzukommenden Luft, die niedriger sein soll als die im Raum befindliche. Ist der Taupunkt tatsächlich ein ausreichendes Kriterium?

    1. Hi Bernd,
      eigentlich sollte der Taupunkt mindestens genauso gut geeignet sein wie die absolute Luftfeuchtigkeit. Kommt Luft mit einer niedrigeren Taupunkttemperatur als die im Raum befindliche hinzu, sinkt das Niederschlagsrisiko (und umgekehrt).

      Genauso verhält es sich mit der absoluten Luftfeuchtigkeit in g/m3. Wobei die Taupunkttemperatur aus meiner Sicht ein etwas anschaulicheres Maß ist, gerade wenn man mit einem errechneten Taupunktpuffer (Temperatur – Taupunkttemperatur) und einer Taupunktdifferenz (Taupunkttemp. Innen – Taupunkttemp. Außen) o.Ä. arbeitet.

      Grüße
      Jörg

  32. Hallo Jörg,
    ich stelle es mir mittlerweile so vor:
    wenn (Taupunkt innen überschritten)
    wenn(absFeuchteAussen<absFeuchteInnen)
    öffne Fenster;
    sonst
    oder(erhöhe Zimmertemperatur, öffne Zimmertür nach innen);

    Glücklicher Weise berechnet das dewpoint-Modul auch die absolute Luftfeuchtigkeit.
    Zumindest ist man dann auf der sicheren Seite, keine Luft in die Wohnung zu lassen, die feuchter ist als die Innenluft. Zur Sicherheit kann man noch einen Puffer einbauen, das ist eine gute Idee.

    Ciao,
    Bernd

  33. Hallo Jörg,
    ich melde mich mich einmal, das Gehirn denkt einfach weiter 🙂
    Zum prinzipiellen Trocknen stimmt, was ich oben schrieb, für die Betrachtung der Betauung/Schimmelvermeidung reicht es nicht:
    Ausschlag gebend für die Taupunktbetrachtung ist nämlich nicht die Lufttemperatur sondern die Temperatur der Wand. DH zunächst müsste mit einem Fühler die kälteste Stelle der Wand gefunden werden und wenn an dieser der Taupunkt (dh die Temperatur, bei der der Sättigungsgrad der Luft für Wasserdampf) erreicht ist, gibt es an allen Stellen, die diese Temperatur haben, Kondensation.

    Folglich wird gebraucht:
    (1) ein Raumsensor, um die Luftfeuchtigkeit zu messen –> der Taupunkt der Raumluft
    (2) ein Wandsensor zur Feststellung, ob an der kältesten Wand die Taupunkt-Temperatur unterschritten ist.

    Demzufolge wäre dann nicht ein unbedingt das Öffnen des Fensters sinnvoll (meist ist die kälteste Stelle in der Nähe des Fensters, was die Betauung erhöhen würde) sondern z.B. ein Heizlüfter, der die Wand wärmt.

    On Fenster auf oder nicht (wenn überhaupt) hängt von zwei Faktoren ab:
    (A) Wie ändert sich dadurch die Wandtemperatur? Das liegt an örtlichen -Begebenheiten
    (B) Wie ändert sich dadurch der Wasserdampfgehalt der Zimmerluft? Wenn draussen absolut trockener, dann könnte es ok sein falls (A) nicht einen stärkeren Effekt hat.

    Ich will betonen, dass ich gerade anfange, mich damit zu beschäftigen … würde mich aber schon interessieren was hieran falsch ist.

    Nun noch eine Frage – kannst Du einen derartigen Wandsensor empfehlen?

    Ciao,
    BerndD

    1. Hi Bernd,
      du hast vollkommen Recht. Das Thema ist super spannend, gerade weil es nicht ganz so trivial ist.
      Bzgl. Temperaturunterschied Innentemp-Wandtemp könnte man auch erstmal vereinfacht mit einem Puffer von bspw. 3°C rechnen. Das müsste man dann ggf. mit einem passenden Thermodetektor (Affiliate-Link) nachprüfen und den Wert dann entsprechend nachjustieren.
      Oder man besorgt sich direkt einen “Wandsensor”, klar. Hier habe ich aber spontan keinen passenden Produktvorschlag parat, sorry.
      Du hast auch damit Recht, dass Lüften nicht immer Sinn macht, entsprechend hilft nur noch eine Heizung. Je nach Raum(-nutzung) gibt es viele Faktoren, die in diesem Kontext berücksichtigt werden müssen. Auch die Zeit spielt sicherlich eine wichtige Rolle (aktuell auch noch nicht berücksichtigt). Denn nur weil die Taupunkttemperatur für eine gewisse Zeit erreicht wird, heisst das ja vermutlich noch lange nicht, dass sich auch tatsächlich Schimmel bildet. Da muss man wohl immer individuell die am besten passenden Settings ermitteln. Ich werde mich damit dann spätestens intensiv auseinandersetzen, wenn es um die intelligente Regelung meiner künftigen kontrollierten Be- und Entlüftung geht.

      Grüße
      Jörg

  34. Hallo Jörg,
    habe letztes WE so ein Teil auseinander gebaut, um den Sensor so dicht wie möglich an die Wand zu bringen:
    http://forum.fhem.de/index.php/topic,49067.msg407236.html#msg407236 … wahrscheinlich ist es wohl einfacher einen anderen Sensor zu finden (oder selber zu bauen) , als diesen zu modifizieren.

    Aus dem o.a. Wiki kann man tatsächlich fast alles übernehmen, die k-Wert Methode macht allerdings nur bei Wänden Sinn, bei denen man innen und aussen die Wandtemperatur messen kann – also bei Kellerwänden eher nicht.

    Cu,
    Bernd

  35. Delvar
    Q

    Hi Jörg,

    Dein Artikel hier hat mir gut geholfen, meine eigene Lüftungsberechnung zu implementieren. Heute ist mir aber aufgefallen, dass der dewpoint seit August nicht mehr errechnet wird. Ich habe Deine zwei Zeilen

    define dewpointToAllDeviceReadings dewpoint dewpoint .* temperature humidity dewpoint
    define dewpointToAllDeviceStates dewpoint dewpoint .* T H D

    eingefügt. Das lief bisher sauber. Hast Du eine Idee?

    Danke schonmal dafür, dass Du Dein Wissen so offen teilst!

    Liebe Grüße
    Hank

    1. Puh,
      hast du währenddessen ein Update gemacht oder Ähnliches? Ich nutze das aktuell nicht, deshalb kann ich leider nichts dazu sagen. Am besten liest du direkt mal im Wiki nach…

      Grüße und viel Erfolg
      Jörg

    2. Ja, natürlich. Am Modul wurde wohl etwas geändert, was speziell uns Netatmo-User ärgert. Denn wenn die Messwerte zeitlich zu weit auseinander liegen, rechnet FHEM nicht mehr. Das ändert man per zusätzlicher Zeile:
      attr dew_all max_timediff 700

  36. Mmmh habe dein Skript jetzt mehrere Monate in meinem Wohnzimmer im Einsatz. Und ich verstehe deine Auswert-Logik nicht.

    Folgende Zeile ist unklar, weil diese nie eintrifft:

    elsif ($fenster_WZ eq “closed” && $dewpoint_buffer < 3 && $dewpoint_Aussen <=3 ist ist und liegt im Schnitt zwischen 7 und 8.

    Der Taupunkt aussen ist bisher immer <= Taupunkt.innen

    Das Ergebnis:

    wenn das Fenster "open" ist, dann steht "opened" da.
    wenn das Fenster "close" ist, dann steht "closed" da.

    Irgendwas scheint nicht zu stimmen. Vielleicht kann es ja nicht mit einem Wohnzimmer funktioniert?!? Was könnte falsch sein?

    1. Hi Michael,
      schon ein paar Tage her, seitdem ich mir dazu Gedanken gemacht hatte. Deine Zeile macht so vermutlich keinen Sinn, richtig. Im Beispiel des Blogposts kann ich das in dieser Form aber nicht wiederfinden…

      Grüße
      Jörg

    2. Okay.

      Die Zeile die ich meine und aus deinem script habe, lautet ohne meine Namensänderungen:

      elsif ($fenster_bz eq “closed” && $dewpoint_buffer < 3 && $dewpoint_te <= $dewpoint_bz) {\
      fhem ("set BZ.Lueften open")\
      }\

      Für mich ergibt das keinen Sinn, liegt wahrscheinlich daran, dass ich nicht verstehe wofür der Buffer angedacht ist und wofür ich diesen brauche. Ein Zustand der, in meinem Fall ( Wohnzimmer) nicht erreicht werden kann, da der Buffer sich immer im Bereich von 7 bewegt.

    3. Hi Michael,

      hier die Formel aus dem Blogpost:
      my $dewpoint_buffer = $temperature_bz – $dewpoint_bz
      -> Puffer = Temperatur – Taupunkttemperatur

      Wenn also die Temperatur weniger als 3 Grad über der Taupunkttemperatur liegt, wird ein erhöhtes Niederschalgsrisiko angenommen. Dann sollte gelüftet werden. Aber natürlich auch nur dann, wenn die Taupunkttemperatur außen geringer ist als innen. Sonst wäre das ja kontraproduktiv.
      Der Differenzwert 3 ist einfach mal so angenommen und wird vermutlich nur in Kellerräumen erreicht bzw. unterschritten.

      Grüße
      Jörg

  37. Hi, wenn die Wände abgedichtet sind muss der Raum und alles darin gut getrockned werden.
    Die elektrischen Lufttrockner schaffen das am besten. Hier ein Testbericht auf www.vergleich365.com/Luftentfeuchter der Geräte. Wenn der Raum dann trocken ist, kann man damit super Wäsche trocknen.
    Gruß Stef

  38. Hallo Jörg,

    Danke für Deine Seite – ist immer wieder eine hilfreiche! 🙂

    Eine Anmerkung zum Notify-Code oben. Die doppelten Semikola in der fhem (“setreading…. – Anweisung führen dazu, dass die readings nebeneinander erscheinen. Eleganter, und so hast Du es ja auch im Screenshot gezeigt, ist untereinander, was ein vereinzeltes Semikolon erreicht.

    VG Matthias

    1. Servus Jörg, ich hatte das gleiche Problem, alle Readings wurden in einer Zeile dargestellt. Die übersichtlichere Variante ist

      {fhem (“\
      setreading BZ.Lueften temperature_bz $temperature_bz;\
      setreading BZ.Lueften dewpoint_bz $dewpoint_bz;\
      setreading BZ.Lueften temperature_te $temperature_te;\
      setreading BZ.Lueften dewpoint_te $dewpoint_te;\
      setreading BZ.Lueften dewpoint_buffer $dewpoint_buffer;\
      setreading BZ.Lueften fenster_bz $fenster_bz\
      “)};\

  39. Hi Jörg,
    vielen Dank für diesen Artikel (und deinen gesamten Blog). Ich steige gerade in dem Thema FHEM ein und dein Blog hat mir schon oft geholfen. DANKE =)

    Nun bin ich aber seit Tagen am verzweifeln, da das “Lüften” Script nicht funktioniert.
    Ich weiß einfach nicht woran es liegen kann.

    Kurz zu meinem Setup:
    – FHEM @ RPI3
    – COC von Busware für HM Geräte
    – Eigenbau Arduino Serial Gateway für LaCrosse Sensoren (9 Stück habe ich bereits)
    – dewpoint modul läuft
    – Dewpoint wird auch erkannt im State (Siehe Screenshots)

    Leider wird der Dummy BZ.Lueften nicht geändert bzw aktualisiert. Woran kann das liegen?

    Screenshots: http://imgur.com/a/YAcuj
    verwendeter Code: http://pastebin.com/7m5b2SBd

    Beste Grüße,
    Phil

  40. define dewpointToAllDeviceStates dewpoint dewpoint .* T H D

    Bei mir zeigt es in fhem bei den Lacross 29er das DewPint entweder nur bei SZ oder WZ oder mal so mal so an. Aber nie überall

  41. Hallo 🙂 könnte mir jemand sagen wie der Cose aussehen müsste, wenn ich kein Fensterkontakt habe und auch kein elektrisches Heizungsventil? Ich würde trotzdem gerne in dem Genuss sein informiert zu werden wann es optimal ist zu lüften.
    Danke!!

  42. Weiter oben wurde von Jörg in Kommentaren wurde geschrieben das der Dewpoint bei den Sensoren TX29DTH-IT nicht in die Readings geschrieben wird. Leider wurde keine Lösung gefunden, da wohl sonst niemand ein ähnliches Problem hatte. Bei mir tauch der Dewpoint zwar in den Readings auf. aber das D im Device Overview fehlt, was bei den Dummys zur Ausgabe “???” führt. Der Befehl “define dewpointToAllDeviceStates dewpoint dewpoint .* T H D” führt also zu keinem Ergebnis…Falls jemand eine Lösung für das Problem hat wäre ich sehr dankkbar.

  43. Moin,
    ich schlage vor du setzt das attribut doDewpoint am Sensor define dewpointToAllDeviceStates hat bei mir auch nur sporadisch den Taupunkt angezeigt. Wenn do eventonchangereading .* gesetzt hast klappt es fast nie.

  44. Hallo, danke schonmal für die vielen Inputs und Ideen. Ich habe einige von dieser Seite aufgenommen und noch etwas verfeinert/perfektioniert, siehe hier, vielleicht interessiert es ja den Autor oder den ein oder anderen Leser: http://saller.net/smart-home/

Schreibe einen Kommentar zu Harald Schmidt Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Das könnte dir auch gefallen