Node-RED Umsetzung als YouTube Tutorial

Lieber Leser!

2017 habe ich, weil unser Haus von 1890 einen alten Keller ohne „richtigen“ Boden und vernünftige Dämmung bot, ein Projekt zur automatisierten Lüften mit einer Raspberry PI umgesetzt. Der Lüftungserfolg an sich hielt sich zwar in Grenzen, aber es brachte etwas frische Luft, weniger Muff und eine ganze Menge Erkenntnisse.

2020 stieß ich auf Node-RED. Und meine Neugier zwang mich, die gesamte Umsetzung zu verwerfen und mit Node-RED neu aufzusetzen. Schlanker, grafischer, schicker.

Wer sich nun auf diese Seite verirrt, das gleiche vor hat und überlegt, wie er es angehen muss, dem möchte ich den Node-RED Ansatz ans Herz legen.

Node-RED bietet nicht nur eine grafische Oberfläche zur Programmierung, die dennoch mit Java-Script alle Freiheiten für den klassischen Ansatz lässt, sondern viele integrierte oder verfügbare Nodes, ja sogar ein Dashboard. Für die Kellerlüftung ist keine Datenbank nötig, dennoch können Charts erstellt werden. Die Nodes bringen alles zur direkten Integration der Sensoren mit und es ist sogar möglich, über ein UI manuell alles zu steuern, was man sich vorstellen kann.

Es gibt Grenzen, aber für dieses Projekt spielen sie keine Rolle, es überwiegen die Vorteile.

Da Node-RED als grafische Oberfläche prädestiniert für einen Screencast statt einem Blog ist, habe ich ein YouTube-Tutorial erstellt.

Wer sich also hierher verirrt hat, dem empfehle ich diesem Link zu folgen:

Kellerlüftung nun mit Node-RED umgesetzt: Diese Seite bleibt für Legacy-Zwecke

2017 starteten wir ein Projekt, um mit zwei DHT22 Sensoren und einer Raspberry, einem Fensteröffner und einem Lüfter die Luftfeuchtigkeit im Keller zu reduzieren durch automatisiertes Lüften.

Damals haben wir alles in Shell programmiert und als Batch umgesetzt, Daten in mySQL gesammelt und mit CACTI visualisiert. Das ist hier beschrieben.

Falls heute jemand auf dieser Seite landet und das Nachbauen will: Es gibt inzwischen elegantere Methoden. Die Frage ist, wie aufwändig soll es werden? Mein Plan mit Python, InfluxDB und Grafana zu arbeiten hat sich durch die „Entdeckung von Node-RED“ zerschlagen. Denn Node-RED bietet die Möglichkeit, grafisch zu arbeiten und ohne extra Datenbank und mit integriertem Visualisierungstool ein recht ansprechendes Dashbaord zu erzeugen. Selbst wenn einem das nicht reicht, kann man die Daten elegant in eine InfluxDB einspeisen (die sich mit Grafana auslesen lässt). Das wäre aber eine Erweiterung, die inhaltlich nicht notwendig ist.

Ich habe mich entschieden, ein YouTube-Tutorial aus dem Umbau zu machen, weil sich Note-RED dafür anbietet und eine Extra-Seite für die Implementierung zu erstellen, damit diese Seite als Legacy-Seite bestehen bleibt. Aber sobald die neue Seite steht, wird

HIER

der Link stehen, da der „neue“ Wege leichter zu implementieren ist. Auch gefällt mir der Bosch BME280 besser als der DHT, was vor allem am I2C Protokoll liegt.

Mit Node-RED war ich in der Lage, CACTI, die mySQL DB, die Batch-Programmierung, den Aufruf im Cronetab und die Einbindung der LOLDHT Libs in einer einzigen Umgebung zu ersetzen. Es sind zwar extra Nodes erforderlich für Node-RED, nämlich für den BME280 (Sensor), für das Dashboard, aber die lassen sich einfach installieren.

Ganz ohne Code kommt man leider trotzdem nicht aus und manchmal führt der grafische Weg zu erhöhtem Aufwand, weil es nicht so schlank funktioniert wie in einer Programmiersprache. Insofern wäre der Weg über Python mit InfluxDB und Grafana noch immer interessant, aber die Lösung über Node-RED ist für den Anwender, der nicht zu tief in Linux und Python steckt, sicherlich einfacher.

Wer bereits starten möchte, Node-RED lässt sich inzwischen mit nur einem Aufruf aus der Raspberry-Shell installieren, was hier beschrieben ist:

https://nodered.org/docs/getting-started/raspberrypi

Es kann direkt im Installer angegeben werden, dass die Raspberry Lib mitgeladen wird, was eine sehr komfortable Ansteuerung des GPIO Pins erlaubt.
Die BME280 Lib kann manuell, aber auch direkt aus Node-RED nachgeladen werden. Den Rest erkläre ich dann im Tutorial.

Als Teaser hier ein Screenshot des Dashboards:

 

Node-RED, BME280, InfluxDB und Grafana

Am Wochenende konnte ich die neuen BME280 Sensoren in Betrieb nehmen. Um sie an einem I2C zu betreiben, muss man eine Lötstelle verbinden und eine Leiterbahn trennen, dann hat man 0x77 statt der 0x76, zumindest bei diesem Sensor:

Danach konnte ich mit einer Library für den BME280 beide Sensoren auslesen, nach etwas Manipulation der Bibliothek, weil sie fest auf der 0x76 war, anstatt Übergabeparameter zu akzeptieren.

Leider war das alles Python2, ich wollte gerne in Python3 arbeiten, dafür habe ich aber keine Bibliothek gefunden.
InfluxDB ist installiert, DB erstellt, Grafana läuft.

Ich habe jetzt aber spaßeshalber Note-RED installiert und ich glaube, das ist PERFEKT für diese Aufgabe und so viel einfacher als es über Python zu realisieren. Es gibt auch eine Node für den BME280 und nach 2min habe ich schon Werte für beide Sensoren.

Daher neuer Plan: Ich werde mit Note-RED arbeiten, die Daten von dort in eine InfluxDB schieben, dann in Grafana auswerten. Auch GPIOs lassen sich aus Note-RED bequem schalten – ich denke das wird die Sache erheblich vereinfachen!

Kleines Update: Bosch BME280, Grafana, InfluxDB, Python

Ich hab die Seite hier lange so online gelassen, für Leute, die das Projekt nachbauen wollen. Inzwischen sind ein paar Jahre ins Land gegangen, meine Lüftung arbeitet noch, aber es gibt inzwischen elegantere Möglichkeiten und „Corona“ hat meinen Urlaub in unser zu Hause verlegt, so komme ich dazu, mir das alles nochmal anzugucken.

Ich werde daher ein paar grundlegende Veränderungen vornehmen und habe davon einen Teil schon umgesetzt. Ich werde das dieses Mal nicht so ausführlich dokumentieren können, aber es wird eine Zusammenfassung mit den Skripten geben.

Hier als Teaser die Eckdaten:

 

• CACTI war als „Dashboard“ zum Anzeigen der Daten eine etwas zweckentfremdete Lösung. Es gibt inzwischen einfach „schickere“ Dashboards, die genau für unseren Zweck optimiert sind.
  Vor allem „Grafana“ wird gern für Dashboards verwendet und ist schon deutlich edler und schicker als CACTI. D.h. wir werden CACTI mit GRAFANA ersetzen.
• Grafana benötigt eine Datenbank, genau wie CACTI. Für Zeitwerte („time series“) gibt es inzwischen optimierte Datenbanken, stark auch durch Cloud-Computing (Azure, AMS) gepusht.
  Wir werden daher statt mySQL (was wir für CACTI genutzt hatten) eine InfluxDB einsetzen, um unsere Daten abzulegen und mit Grafana darzustellen.
  Also: Wechsel von mySQL auf InfluxDB.
• Das Projekt habe ich damals als Batch-Programm durchgezogen und musste immer wieder Umwege daher in Kauf nehmen. Alleine um die Temperaturwerte aus dem String zu extrahieren, aber wir benötigten auch einen externen Taschenrechner usw. Schon damals wollte ich „umkehren“, aber als dann alles lief, war es zu aufwändig.
  Durch die grundlegenden Änderungen nutzen wir die Chance und wechseln auf Python.
  Also: Batch wird durch Python ersetzt.
• Nun bleibt noch etwas Hardware: Der DHT22. Mit dem Sensor habe ich nur bedingt gute Erfahrungen gemacht. Die Genauigkeit reicht mir aus, aber die Kommunikation brachte je nach verwendeter Library unterschiedliche Ergebnisse: Mit der Adafruit gab es beim weiter entfernen Außensensor oft fehlerhafte Messwerte, die klar ein Timingproblem zeigen, da die LOLDHT Variante korrekte Werte lieferte.
  Mit geschirmten Kabeln und einem Kondensator am Sensor kann man die Störempfindlichkeit reduzieren, aber das Problem ist das Timing schon in der Lib.
  Aber auch die LOLDHT ist nicht perfekt. Ich hatte zwar keine Probleme, ein Bekannter aber schon.
  Da wir eine Python Library nun aber benötigen, die Adafruit bietet, muss eine erhöhte Störfestigkeit her.
  Das Problem ist meiner Ansicht nach der Bus: Das One-Wire-Interface der DHT Sensoren besitzt keine Clock-Leitung. D.h. die Synchronisation muss über die Flanken der Datenleitung erfolgen. Das kann offenbar Probleme machen.

  Wir nutzen also auch diese Chance und wechseln den Sensor. Bosch bietet mit dem BMP280 einen Luftdruck- und Temperatursensor, in der BME280 Variante ist auch nocht die Luftfeuchtigkeit enthalten, die wir benötigen. Es gibt 3,3V und 5V Varianten. Bei der Raspberry sind 3,3V angesagt.
  Also werden wir von dem DHT22 auf den BME280 wechseln, noch ein Wechsel also.
  Der BME280 bietet I2C und SPI, auch hier bietet Adafruit eine Library.
  Wir müssen von 3 auf 4 Adern wechseln, denn der I2C Bus benötigt eine Clock-Leitung. Für SPI müssten wir sogar auf 6 Adern gehen, aber I2C sollte reichen.

• Zuletzt: Ich habe inzwischen auf meiner PI einen Unifi Controller laufen, PI-hole als DNS und nun noch Grafana?!
  Die Gunst der Stunde werden wir also auch hier nutzen und wechseln von einer Raspberry 3B auf eine Raspberry 4 mit 2GB RAM. Da hab ich zwar etwas Sorgen bzgl. Temperatur, aber das sehen wir dann. Wir werden die Raspberry 3B als Entwicklungsumgebung nutzen, die 4 wird dann die Produktivumgebung. Das ist zwar auch etwas kritisch, unterschiedliche Hardware, aber wird schon passen 😉

Also – das wird doch ein grundlegender Umbau, der aber das Konzept doch auf moderner und etwas ausgereiftere Füße stellen wird.

Ich werde die Ergebnisse hier posten, allerdings nicht ganz so genau dokumentieren wie den ursprünglichen Aufbau. Dafür bette ich dann die Links ein, wo die Informationen zu finden sind.
Stay tuned und bleibt gesund!

HABridge – Lüften über Amazon Alexa / Echo

Ich habe lange nichts mehr an meiner Kellerlüftung gemacht. Sie funktioniert soweit gut, auch wenn man merkt, dass man über zwei offene Türen doch noch mehr Luft umwirbelt.

Aber ich las neulich über eine Software, die sich „HABridge“ nennt und die eine ganz nette Funktion bietet: Sie emuliert eine HUE Bridge und dadurch kann man mit Alexa ohne zusätzliche Skills bestimmte Aktionen über die Raspberry (wenn man darauf die HABridge installiert) steuern – z.B. unsere Skripte starten.

Das Kellerfenster per Sprachkommando öffnen oder die gesamte Lüftung starten fand ich natürlich ganz nett.

Aber – es gab natürlich ein Problem. Wir haben einen Apache2 Webserver installiert, der auf Port 80 läuft. Die HABridge kann auf jedem Port laufen, aber ich hatte Probleme mit einer Alexa 2nd Gen dann die HABridge zu finden. Es gibt viele Tipps, aber es ging bei mir nur auf Port 80, dort läuft aber schon der Apache2.

Ich habe dann ein Tutorial gefunden, wie man im Apache2 einen Proxy definieren kann und so auch Anfragen auf Port 80 durchgeroutet bekommt.

Also – wer Lust hat kann sich damit beschäftigen:

1. Installation der HABridge:
   https://itler.net/ha-bridge-auf-raspberry-pi-installieren-anleitung/
2. Konfiguration des Apache2, um die HABridge auch auf  Port 80 zu finden:
   https://github.com/openenergymonitor/emonpi-ha-bridge

Ich habe die HABridge auf  Port 8080 laufen. Das muss man natürlich dann in der Apach2 Konfig anpassen. In dem Beispiel ist es 8081.

Ich überlege noch, was man sonst damit anfangen kann. Vielleicht den Rechner per Sprache ausschalten – dafür kann man die NET Befehle nutzen, wenn Samba auf der Raspberry installiert ist. Vielleicht gibt es noch sinnvollere Ideen 🙂

Letztes Kapitel: Finalisierung

Inzwischen ist auch der Fenstermotor eingebaut und wir können nicht nur Erfolge verkünden, sondern auch den Blog schließen. Denn die Aufgabe die Automatisierung einer Keller-Lüftung mittels Raspberry PI, Temperatur- und Feuchtesensoren, Relais und Ventilatoren (und nun sogar Fenstermotoren) umzusetzen, ist abgeschlossen und zwar mit einem wirklich guten Ergebnis.

Aber in diesem letzten Kapitel kommen doch noch einige Änderungen auf euch zu. Ich habe sowohl das Haupt-Skript überarbeitet, um etwas mehr Einstellmöglichkeiten zu erhalten, habe es auch noch verschoben und einige Bezeichner geändert, damit es leichter zu pflegen ist…. als auch den Ventilator und der Fenstermotor auf je einem Relais in Betrieb genommen, daher wurde die Relaisansteuerung um eine weitere Transistorschaltung erweitert und natürlich auch der Fenstermotor selbst in Betrieb genommen. Insofern hat sich doch noch einiges getan.

Wer am Anfang dieses Projekts steht, sollte daher auch am Anfang dieses inzwischen umfangreichen Blogs beginnen und sich bis hierher durcharbeiten. Das mag anstrengend werden, aber ihr bekommt eine fertige Lösung, die ihr nur noch auf eure Gegebenheiten anpassen müsst. Ihr könnt sie sogar skalieren – ob ihr nun unbedingt CACTI nutzen wollt, also eine graphische Oberfläche für die Visualisierung, oder ob euch das einfache automatische Schalten reicht, liegt ganz bei euch. Das Skript läuft ebenso gut wenn CACTI nicht installiert ist.

Nun aber weiter für die, die sich bis hierher durchgearbeitet haben oder gar den gesamten Weg live begleiteten:

Ich beginne mit einem wichtigen Tipp: Ich habe mein Skript aufgemotzt und dabei so viele Dinge verändert, dass ein intensives Debugging notwendig war. Da wir aber nicht mit einem Compiler arbeiten, können wir leider keine Schritt-für-Schritt Abarbeitung starten und uns dabei unsere Variablen angucken. Das macht die Sache deutlich komplizierter, wenn es um Fehlersuche geht aber auch dann, wenn wir einfach nur die Funktionstüchtigkeit aller Wege prüfen wollen.

Aber immerhin kann die Bash etwas unterstützen. Wenn ihr das Skript wie folgt startet:

bash -x SKRIPTNAME.SH

werden sowohl die Code-Zeilen als auch die Rückmeldungen mit angezeigt, was ungemein hilft. Bei langen Skripten wird es aber unübersichtlich, daher kann auch mitten im Skript ein Bereich markiert werden:

#GUTER CODE
set -x
#DEBUG-CODE
set +x
#GUTER CODE

Das Skript kann dann ohne -x Parameter gestartet werden und wird in dem markierten Bereich dennoch genauso behandelt. Sehr hilfreich!

Bevor wir uns dem finalen Skript zuwenden, hier noch die letzten Schritte:

Ich habe inzwischen beide Relais des Relais-Moduls an der Raspberry hängen. Daher muss ich im Skript auch immer 2 GPIOs nun schalten.
Mein Relais-Modul schaltet über GND und ich habe als Sicherheit eine Transistorvorstufe vorgeschaltet – hier nun die einfache Beschaltung:

Wie in dem vorherigen Kapiteln erwähnt, müssen es nicht genau 1KOhm sein. Ich nutze 2KOhm, das ist auch okay. Eine typische Größe für einen Basiswiderstand, wenn der Transistor voll durchschalten soll. Wir hängen unsere Relais-Eingänge an die Kollektoren der bipolaren NPN-Transistoren. Laut Spezifikation ist das Relais sowohl bei 5V als auch bei High-Z „non energized“  und bei GND dann „energized“. D.h. wenn wir unseren GPIO auf 3.3V setzen, ziehen wir das Relais auf MASSE und schalten es. Liegt der GPIO auf 0V, ist der Transistor geschlossen und das Relais hängt in der Luft und schaltet in seine Ruheposition.

An den Relais hängt sowohl mein Ventilator für die Abluft als inzwischen auch mein Fenstermotor für die Zuluft. Ich habe den Luftstrom gemessen und ohne Zuluftsteuerung war kein Erfolg zu verzeichnen.

Das ist ein Keller von 1890 – die sehen leider so schäbig aus 🙂
Über dem Fenster ist der Stellmotor, den ich nicht exakt so anbauen konnte, wie es gedacht ist, weil mir dort über der Laibung der Platz fehlt. Rechts sieht man den Lüfter, den ich in eine Wetterfeste Bauplatte gesetzt habe, die mein altes Fenster überdeckt. Beides ist inzwischen zusätzlich über Fenstergitter gesichert – aber ich habe noch Videos ohne, da kann man die Funktionsweise gut sehen:

Fenster-Steuerung
Ventilator-Ansteuerung

Das ist die Infrastruktur. Wir haben nun einen idealen Luftstrom. Mit Testmessungen bekomme ich bei sehr kurzer Lüftungsdauer, z.B. 5min, direkte Rückmeldungen auf dem Feuchtemesser, während ohne Zuluftsteuerung selbst nach 45min keine signifikante Veränderung eintrat.

Eigentlich wollte ich noch ein Video von der Strömungsmessung mit dem Dräger Flow-Check machen – vielleicht reiche ich das noch nach.

In den vorherigen Kapiteln hatte ich die notwendigen Informationen hierzu schon gegeben, z.B. die Initialisierung der GPIOs als Ausgänge und die Verwendung der Wiring PI, die wir vorher nur indirekt genutzt haben für das Auslesen der DHTs.
Ich habe übrigens aus verschiedenen Gründen zwei getrennte Relais verwendet. Einerseits bietet das die Möglichkeit, bei Bedarf Lüftung und Fenster getrennt zu steuern, was ich aber noch nicht tue.

Auf der anderen Seite entkoppelt es die beiden aber. Die Fenstersteuerung benötigt immer eine Phase – entweder auf Eingang 1 oder auf Eingang 2. Wenn nur ein Relais verwendet würde, wäre der Eingang in „Fenster zu Position“ ohne Phase dennoch zumindest mit dem Ventilator verbunden. Das kann zu unerwünschten Nebeneffekten führen – daher trennt man das besser galvanisch.

Wie erwähnt habe ich nun auch noch das Haupt-Skript überarbeitet. Ich habe die Variablen eindeutiger benannt, aber vor allem habe ich ein paar zusätzliche Optionen eingebaut. Es gibt nun mehrere Abbruchmöglichkeiten einer Lüftung:

1. Die Lüftungsempfehlung aufgrund der Messung der Temperatur und Luftfeuchtigkeit wird zurück genommen (Standard)
2. Die Lüftung dauert lange an, bis ein time out erreicht ist (on_time_session)
3. An einem Tag wurde sehr lange gelüftet, auch in mehreren Etappen und so ist ein anderer time out erreicht (on_time_day)
4. Eine Lüftung zeigt keine Wirkung (lueften_pass_fail)

Zu 4: Hier kann natürlich beliebig viel Intelligenz eingebaut werden. Man könnte die Differenzialrechnung bemühen und die erste Ableitung bilden. Man könnte Durchschnittwerte über mehrere Messungen bilden. Man kann versuchen eine Reihe zu bilden oder eine Funktion zu beschreiben, um eine Vorhersage der Entwicklung zu treffen usw. (wobei anzumerken ist, dass die Bash-Onboard-Tools für Rechnenoperationen sehr beschränkt sind).

Im ersten Schritt habe ich hier nur einen Vergleich des aktuellen Werts mit dem Wert davor vorgenommen und einen zusätzlichen Abgleich mit dem Startwert. Verbessert sich die Situation nicht, wird ein Zähler erhöht. Nach einer Zahl X wird das Lüften abgebrochen, da es offensichtlich nichts bringt.

Ein anderes Thema ist das Starten einer Lüftung. Auch hier habe ich eine Änderung vorgenommen: Um bei Fehlmessungen nicht gleich eine Lüftung zu starten, müssen zwei Lüftungsempfehlungen nacheinander gegeben werden.

Für die Realisierung dieser Funktionen musste ich etwas mehr Daten ablegen und wieder einlesen, da ich die Historie benötige.
Bewusst habe ich die CACTI-Seite aber so gelassen wie bisher, nur dass ich nicht die Schaltungsempfehlung übergebe, sondern wirklich nur den Zustand ON/OFF.

Dazu kommen weitere kleinere Verbesserungen. Daher nun zum Abschluß dieses Blogs der komplette Code des Hauptsskripts – alles andere findet ihr in den Kapiteln zuvor.

Für mich war das ein spannendes Projekt und ich habe selbst auch wieder einiges lernen können und nebenbei bin ich inzwischen überzeugt, dass es auch für den Keller eine sinnvolle Investition ist.
Falls ich Fehler finde, werde ich das Skript in diesem Blog hier ersetzen, ansonsten bin ich erstmal raus und wünsche euch viel Spaß mit diesem Projekt.

PS: Als Nerd-Ausblick kann ich noch ein Philips HUE Projekt mit der Raspberry ankündigen, was aber deutlich schlanker wird als dieser Blog hier. Es wird nur um eine Urlaubssteuerung gehen…

Nun noch der Code:

#!/bin/bash

#Kellerlüftung mittels Raspberry PI, DHT22/21 Sensoren, Relais für Ventilator und Fenstermotor
#Copyright Malte Berndt 2017
#Ab welcher Feuchtigkeit im Keller soll nicht mehr gelüftet werden / untere Grenze?
MIN_FEUCHTE=55

#Beide DHT22 auslesen und als Variablen ablegen
Sensor_Innen=$(/home/pi/lol_dht22/loldht 0)
Sensor_Aussen=$(/home/pi/lol_dht22/loldht 2)
#In Einzelwerte aufteilen
Sensor_Innen_HUM=$(echo $Sensor_Innen | awk '{printf $1}')
Sensor_Innen_TEM=$(echo $Sensor_Innen | awk '{printf $2}')
Sensor_Aussen_HUM=$(echo $Sensor_Aussen | awk '{printf $1}')
Sensor_Aussen_TEM=$(echo $Sensor_Aussen | awk '{printf $2}')

#Näherungsformel Außen-Luftfeuchtigkeit-3*(Innentemperatur-Außentemperatur)=R_InnenLuftfeuchtigkeit 
R_InnenFeuchte=$(echo "$Sensor_Aussen_HUM-3*($Sensor_Innen_TEM-($Sensor_Aussen_TEM))" | bc -l)

#Schaltempfehlung JA/NEIN 1/0
#Lüftungsmepfehlung wenn min. 10% Abstand vorliegen und die Minimalfeuchtigkeit noch nicht erreicht ist
#Vorher auf INT wechseln, damit wir nicht mit expr etc. arbeiten müssen. Also Mal 10...
R_InnenFeuchte_10=$(echo "$R_InnenFeuchte*10" | bc)
R_InnenFeuchte_10=${R_InnenFeuchte_10%.*}
Sensor_Innen_HUM_10=$(echo "$Sensor_Innen_HUM*10" | bc)
Sensor_Innen_HUM_10=${Sensor_Innen_HUM_10%.*}
SCHALT_HUM_10=$(echo "$Sensor_Innen_HUM_10-100" | bc -l)
MIN_FEUCHTE_10=$(echo "$MIN_FEUCHTE*10" | bc)
if [ $R_InnenFeuchte_10 -le $SCHALT_HUM_10 -a $Sensor_Innen_HUM_10 -gt $MIN_FEUCHTE_10 ]; then
SCHALTEN=1
else
SCHALTEN=0
fi

#Prüfen ob Historie vorhanden sonst Werte auf 0
if [ ! -f "/home/pi/lueften_historie.txt" ]; then 
on_off=0
on_time_session=0
on_time_day=0
on_off_count=0
start_wert_lueften=0
vorher_wert_lueften=0
lueften_pass_fail=0
break=0
counter=0
else
#Historie einlesen
lueften_historie=$(head /home/pi/lueften_historie.txt)
on_off=$(echo $lueften_historie | awk '{printf $1}')
on_time_session=$(echo $lueften_historie | awk '{printf $2}')
on_time_day=$(echo $lueften_historie | awk '{printf $3}')
on_off_count=$(echo $lueften_historie | awk '{printf $4}')
start_wert_lueften=$(echo $lueften_historie | awk '{printf $5}')
vorher_wert_lueften=$(echo $lueften_historie | awk '{printf $6}')
lueften_pass_fail=$(echo $lueften_historie | awk '{printf $7}')
break=$(echo $lueften_historie | awk '{printf $8}')
counter=$(echo $lueften_historie | awk '{printf $9}')
fi

#wir schalten erst bei 2x Empfehlung für Lüften in Folge, daher zählen
if [ $SCHALTEN -eq 1 ]; then
on_off_count=$(($on_off_count+1))
fi
#falls es eine Empfehlung gab, aber diese nun zurückgenommen wurde, setzen wir auch den Zähler zurück
if [ $SCHALTEN -eq 0 -a $on_off_count -ne 0 ]; then
on_off_count=0
fi


# Wenn bereits gelüftet wird...
if [ $on_off -eq 1 ]; then
on_time_session=$(($on_time_session+5))
on_time_day=$(($on_time_day+5))
#Wir prüfen ob lüften erfolgreich ist durch Vergleich mit Start- und Vorher-Wert
if [ $Sensor_Innen_HUM -ge $vorher_wert_lueften -a $Sensor_Innen_HUM -ge $start_wert_lueften ]; then
lueften_pass_fail=$(($lueften_pass_fail+1))
fi
#wenn lueften nicht erfolgreich oder Zeiten übeschritten, Pause setzen und lüften stoppen
if [ $lueften_pass_fail -gt 3 -o $on_time_session -gt 30 ]; then
break=45
/usr/local/bin/gpio -g write 14 0
/usr/local/bin/gpio -g write 15 0
on_off=0
on_off_count=0
EMAILTEXT=$(printf "Erfolgloses Lüften: %s Mal\nOn_Time_Session: %smin\nLüften gestoppt!\n" "$lueften_pass_fail" "$on_time_session")
/home/pi/skripte/mail.sh "Lüften des Kellers gestoppt" "$EMAILTEXT"
fi
#wir nehmen den neuen Raum-Feuchte-Wert mit in die Historie
vorher_wert_lueften=$Sensor_Innen_HUM
fi

# Falls on_off_count >1 (also ab 2) und noch nicht gelüftet wird und break nicht gesetzt ist, LÜFTEN.
if [ $on_off_count -gt 1 -a $on_off -eq 0 -a $break -eq 0 ]; then
EMAILTEXT=$(printf "Luftfeuchtigkeit Keller: %s%%\nLuftfeuchtigkeit durch Lüftung: %s%%\nLüften gestartet!\n" "$Sensor_Innen_HUM" "$R_InnenFeuchte")
/home/pi/skripte/mail.sh "Lüften des Kellers gestartet" "$EMAILTEXT"
/usr/local/bin/gpio -g write 14 1
/usr/local/bin/gpio -g write 15 1
on_off=1
on_time_session=0
start_wert_lueften=$Sensor_Innen_HUM
vorher_wert_lueften=0
lueften_pass_fail=0
fi

#Bei Schaltempfehlung 0 bei aktiver Lüftung, LÜFTEN stoppen
if [ $SCHALTEN -eq 0 -a $on_off -eq 1 ]; then
EMAILTEXT=$(printf "Luftfeuchtigkeit Keller: %s%%\nLuftfeuchtigkeit durch Lüftung: %s%%\nLüften gestoppt!\n" "$Sensor_Innen_HUM" "$R_InnenFeuchte")
/home/pi/skripte/mail.sh "Lüften des Kellers gestoppt" "$EMAILTEXT"
/usr/local/bin/gpio -g write 14 0
/usr/local/bin/gpio -g write 15 0
on_off=0
on_off_count=0
fi

#falls break gesetzt, 5min reduzieren
if [ $break -gt 0 ]; then
break=$(($break-5))
fi
#falls Tageslüftung überschritten, break setzen bzw. wieder setzen
if [ $on_time_day -gt 180 ]; then
break=5
fi

#counter erhöhen oder rücksetzen wenn 24h (288*5min) um sind
if [ $counter -lt 288 ]; then
counter=$(($counter+1))
else
counter=0
on_time_day=0
fi

#Debug-Vergleich: GPIO ist gesetzt aber on_off ist aus... Fehlermeldung per Mail
PIN14=$(/usr/local/bin/gpio -g read 14)
PIN15=$(/usr/local/bin/gpio -g read 15)
if [ $PIN14 -eq 1 -a $on_off -eq 0 ]; then
/home/pi/skripte/mail.sh "Fehlerbericht" "PIN14 aktiv während on_off auf 0"
fi
if [ $PIN15 -eq 1 -a $on_off -eq 0 ]; then
/home/pi/skripte/mail.sh "Fehlerbericht" "PIN14 aktiv während on_off auf 0"
fi


#-------------EXPORT in DATEIEN---------------

#Debug-CSV erstellen
#CSV mit Header erstellen, falls nicht vorhanden
if [ ! -f "/home/pi/keller_lueftung_log.csv" ]; then
printf "Date;Time;Humidity_Sensor_Innen;Temperature_Sensor_Innen;Humidity_Sensor_Aussen;Calc_Humidity;Temperature_Sensor_Aussen;on_off;on_time_session;on_time_day;on_off_count;start_wert_lueften;vorher_wert_lueften;lueften_pass_fail;break;counter\n" > /home/pi/keller_lueftung_log.csv
fi
#Datum und Zeit ablegen und in CSV Datei anfügen
date=$(date -I)
time=$(date +%T)
printf "%s;%s;%s;%s;%s;%s;%s;%s;%s;%s;%s;%s;%s;%s;%s;%s\n" "$date" "$time" "$Sensor_Innen_HUM" "$Sensor_Innen_TEM" "$Sensor_Aussen_HUM" "$Sensor_Aussen_TEM" "$R_InnenFeuchte" "$on_off" "$on_time_session" "$on_time_day" "$on_off_count" "$start_wert_lueften" "$vorher_wert_lueften" "$lueften_pass_fail" "$break" "$counter">> /home/pi/keller_lueftung_log.csv

#Ausgabe für CACTI in Datei
#Für CACTI on_off auf 0 und 100 skalieren
cacti_on_off=$(($on_off*100))
echo $Sensor_Innen | awk '{printf "HUM1:" $1 " TEM1:" $2" "}' > /home/pi/cactiwerte.txt
echo $Sensor_Aussen | awk '{printf "HUM2:" $1 " TEM2:" $2" "}' >> /home/pi/cactiwerte.txt
printf "SCHALT:"$cacti_on_off" " >> /home/pi/cactiwerte.txt
printf "RHUM:"$R_InnenFeuchte"\n" >> /home/pi/cactiwerte.txt

#Schalthistorie in Datei schreiben
printf "%s %s %s %s %s %s %s %s %s" "$on_off" "$on_time_session" "$on_time_day" "$on_off_count" "$start_wert_lueften" "$vorher_wert_lueften" "$lueften_pass_fail" "$break" "$counter"> /home/pi/lueften_historie.txt

 

 

 

Finale Phase: Fenstersteuerung

Nun sind wir doch gemeinsam einen weiten Weg gegangen, liebe Leser, oder?
Der Blog ist gewachsen, Stück für Stück haben wir eine Lösung aufgebaut, die sich sehen lassen kann.

Aber wie ich schrieb: Ich habe inzwischen den Luftstrom mit einem Dräger Flowcheck visualisiert und bin damit nicht zufrieden. Auch zeigt sich, dass der Lüfter recht lange anspringt ohne große Erfolge zu erzielen.

Aber: Öffnet man gleichzeitig ein bestimmtes Fenster, zieht er von dort die Luft und nach 5-10min schaltet sich der Lüfter aufgrund deutlich reduzierter Luftfeuchtigkeit wieder ab. Perfekt. Das ist die Lösung.
Nun habe ich überlegt dort (in das andere Fenster) einen Zulüfter einzubauen, aber es wird schwer Zuluft mit der Leistung zu erhalten – und wäre auch wieder ein „intensiver“ Eingriff. Daher habe ich nun eine andere Lösung gefunden:

So einen Fenstermotor gibt es schon für ca. 85€. Also ähnlich teuer wie die Lüfter. Mit einem Fenstergitter als Einbruchsschutz ist auch die Sicherheit gegeben.

Das wird also unser Finale: Die Zuluft steuern wir über diesen Fenstermotor, den wir mit an unser Relais klemmen. Dann sollte sich unser Aufwand bezahlt gemacht haben und wir haben endlich die gewünschte Lösung. Klar, der Lüftungsalgorithmus wird sicherlich iterativ noch etwas optimiert werden müssen, aber das muss man vermutlich ohnehin individuell tun.

Daher: Stay tuned, im vermutlich letzten größeren Kapitel werden wir die Fensteröffnung mit in unsere Lösung aufnehmen – als Zuluftsteuerung – dann endet auch mein Nerd-Dasein und ich kann mich wieder anderen Themen widmen 🙂

Wobei ich schon verraten kann, dass ich noch eine 2te Aufgabe für die Raspberry geplant und teilweise initiiert habe: Ich nutze das Philips HUE System bei mir zu Hause und ein paar Dinge kann die Bridge über die APP nicht anbieten – z.B. ein vernünftiges Urlaubsprogramm. Das wird nun über die Himbeere erfolgen. Vielleicht gibt es dazu noch einen kurzen Nerd-Blog, bevor es wieder um alltägliche Dinge im meinem Blog Kurioses Allerlei gehen darf…

PS: Ich hatte eine Zeichnung der Schaltung versprochen, mit der wir das Relais ansteuern. Die kommt noch, aber dann gleich komplett mit Ansteuerung des Fenstermotors.

PPS: Was auch noch zu erwähnen wäre: Mir wurde der DHT21 als Sensor  empfohlen anstatt des DHT22. Die Sensoren sind spezifiaktionsgleich, aber der DHT21 sind in einem robusteren Gehäuse, ist bereits verkabelt und besitzt schon den notwendigen Widerstand, der im Gehäuse sitzt. D.h. er ist schneller in Betrieb genommen und für unsere Anwendung (abgesetzte einzelne Sensoren) einfach besser geeignet. Daher habe ich mir davon zwei bestellt, die ich aber zusätzlich nutzen werde.

 

Kapitel Abluft kann geschlossen werden

Nun habe ich den Lüfter eingebaut und das sieht in unserem alten Keller – das Haus ist von 1890 – so aus:

Und er dreht sich sogar 🙂

Ich habe nun mit einem Dräger Flow-Check Rauch erzeugt und den Luftstrom gemessen.

Was soll ich sagen: Eine definierte Zuluft würden dem Ganzen gut tun. Sobald ich eines der Fenster in dem anderen Raum öffne dreht der Ventilator leiser (Widerstand geringer) und die Luft zischt an dieser Stelle in den Raum. Man muss wirklich keinen Ventilator setzen, aber eine definierte Öffnung, die optimaler Weise elektronisch geschlossen werden kann, ist besser als passive Öffnungen. Vielleicht reichen auch Lamellen an KG Rohren, die bei Unterdruck dann öffnen – müsste man ausprobieren.

Ich habe noch keine Langezeitergebnisse – aber mit der Fensteröffnung war nach wenigen Minuten ein klarer Abfall der Luftfeuchtigkeit im Keller zu erkennen (heute ist es ja schön kalt draußen).

Inzwischen habe ich den Programmcode erweitert, damit der Lüfter geschaltet wird und wir nicht nur eine Mail erhalten.

Bevor ich den Code hier poste – noch eine kurze Anmerkung: Ich habe im letzten Kapitel erwähnt, man solle in rc.local die Initialisierung als Ausgang ablegen. Noch ein weiterer Tipp – man sollte auch den Ausgang auf 0 setzen. Nach Neustart lüftet mein Ventilator und erst wenn der Ausgang definiert auf 0 gestellt wurde, was man ergo beim Autostart sollte, passt das soweit.

Hier nun der aktuelle Code unserer Steuerung:

#!/bin/bash
#Ab welcher Feuchtigkeit im Keller soll nicht mehr gelüftet werden / untere Grenze?
MIN_FEUCHTE_10=60
#Beide DHT22 auslesen und als Variablen ablegen
SENSOR1=$(/home/pi/lol_dht22/loldht 0)
SENSOR2=$(/home/pi/lol_dht22/loldht 2)
#In Einzelwerte aufteilen
SENSOR1_HUM=$(echo $SENSOR1 | awk '{printf $1}')
SENSOR1_TEM=$(echo $SENSOR1 | awk '{printf $2}')
SENSOR2_HUM=$(echo $SENSOR2 | awk '{printf $1}')
SENSOR2_TEM=$(echo $SENSOR2 | awk '{printf $2}')
#Näherungsformel Außen-Luftfeuchtigkeit-3*(Innentemperatur-Außentemperatur)=R_InnenLuftfeuchtigkeit
R_InnenFeuchte=$(echo "$SENSOR2_HUM-3*($SENSOR1_TEM-($SENSOR2_TEM))" | bc -l)
#Schalten JA/NEIN 1/0
#Lüften wenn 10% unter Luftfeuchtigkeit gemessen und diese größer als MIN_FEUCHTE ist
# vorher auf INT wechseln, damit wir nicht mit expr etc. arbeiten müssen. Also Mal 10...
R_InnenFeuchte_10=$(echo "$R_InnenFeuchte*10" | bc)
R_InnenFeuchte_10=${R_InnenFeuchte_10%.*}
SENSOR1_HUM_10=$(echo "$SENSOR1_HUM*10" | bc)
SENSOR1_HUM_10=${SENSOR1_HUM_10%.*}
SCHALT_HUM_10=$(echo "$SENSOR1_HUM_10-100" | bc -l)
MIN_FEUCHTE_10=$(echo "$MIN_FEUCHTE_10*10" | bc)
if [ $R_InnenFeuchte_10 -le $SCHALT_HUM_10 -a $SENSOR1_HUM_10 -gt $MIN_FEUCHTE_10 ]; then
SCHALTEN=1
else
SCHALTEN=0
fi
#Letzten Zustand auslesen
SCHALT_VORHER=$(head -n 1 /home/pi/schalten.txt)
# Falls Schalten von 0 auf 1, LÜFTEN. Wir können hier auch erst bei 2 oder 3 lüften als Filter/Hysterese...
if [ $SCHALTEN -eq 1 -a $SCHALT_VORHER -eq 0 ]; then
EMAILTEXT=$(printf "Luftfeuchtigkeit Keller: %s%%\nLuftfeuchtigkeit durch Lüftung: %s%%\nLüften gestartet!\n" "$SENSOR1_HUM" "$R_InnenFeuchte")
/scripts/mail.sh "Lüften des Kellers gestartet" "$EMAILTEXT"
/usr/local/bin/gpio -g write 14 1
fi
# Falls Schalten von X auf 0, LÜFTEN stoppen
if [ $SCHALTEN -eq 0 -a $SCHALT_VORHER -ne 0 ]; then
EMAILTEXT=$(printf "Luftfeuchtigkeit Keller: %s%%\nLuftfeuchtigkeit durch Lüftung: %s%%\nLüften gestoppt!\n" "$SENSOR1_HUM" "$R_InnenFeuchte")
/scripts/mail.sh "Lüften des Kellers gestoppt" "$EMAILTEXT"
/usr/local/bin/gpio -g write 14 0
fi
#Letzten Zustand ablegen. Bei 0 Datei rücksetzen. Sonst hochzählen.
if [ $SCHALTEN -eq 0 ]; then
echo $SCHALTEN > /home/pi/schalten.txt
else
SCHALT_VORHER=$(($SCHALT_VORHER+1))
echo $SCHALT_VORHER > /home/pi/schalten.txt
fi
#Debug-CSV erstellen
#CSV mit Header erstellen, falls nicht vorhanden
if [ ! -f "/home/pi/wetter_log.csv" ]; then
printf "Date;Time;Humidity_Sensor1;Temperature_Sensor1;Humidity_Sensor2;Calc_Humidity;Temperature_Sensor2;SCHALTEN;SCHALT_VORHER\n" > /home/pi/wetter_log.csv
fi
#Datum und Zeit ablegen und in CSV Datei anfügen
date=$(date -I)
time=$(date +%T)
printf "%s;%s;%s;%s;%s;%s;%s;%s;%s\n" "$date" "$time" "$SENSOR1_HUM" "$SENSOR1_TEM" "$SENSOR2_HUM" "$SENSOR2_TEM" "$R_InnenFeuchte" "$SCHALTEN" "$SCHALT_VORHER">> /home/pi/wetter_log.csv
#Ausgabe für CACTI in Datei
#Für CACTI SCHALTEN auf 0 und 100 skalieren
SCHALTEN=$(($SCHALTEN*100))
echo $SENSOR1 | awk '{printf "HUM1:" $1 " TEM1:" $2" "}' > /home/pi/cactiwerte.txt
echo $SENSOR2 | awk '{printf "HUM2:" $1 " TEM2:" $2" "}' >> /home/pi/cactiwerte.txt
printf "SCHALT:"$SCHALTEN" " >> /home/pi/cactiwerte.txt
printf "RHUM:"$R_InnenFeuchte"\n" >> /home/pi/cactiwerte.txt

Wie ihr seht habe ich die GPIO Befehle hinzugefügt und den Text der Email geändert. Es gibt noch ein paar weitere, kleinere Verbesserungen – aber mit dieser Basis haben wir alles was wir benötigen.

Das Problem ist nun wirklich noch die Zuluft. Denn mit der Zuluft definieren wir den Luftstrom. Da werde ich wohl noch mal ran müssen…

Verkabelung steht

So. Endlich habe ich das Relais und den Ventilator verkabelt und die Raspberry steuert ihn nun – schön 🙂

Morgen noch der Einbau des Ventilators in das „neue Fenster“, dann sind wir fertig.

Aber der Reihe nach – was ist heute passiert:

Ich hatte ein 2-Kanal-Relais-Modul bestellt, welches über GND geschaltet wird. Das bedeutet, am Eingang muss GND liegen, damit das Relais anzieht, während Vdd/Vcc (5V oder auch 3.3V) oder HighZ (hochohmig) das Relais auf Ursprung setzen. Das Relais benötigt 5V an dem Vcc PIN und natürlich auch selbst GND.

Ich habe mich dagegen entschieden, direkt mit den GPIOs auf den Eingang zu gehen. Man liest das zwar immer wieder im Netz, aber auch ein Relais zieht etwas Strom. Nun hat dieses hier einen Optokoppler, dennoch bin ich auf Nummer sicher gegangen. Ich habe eine einfache Emitterschaltung verwendet:

Als Basiswiederstand habe ich 2KΩ verwendet, weil ich den gerade da hatte. Ich hätte auch 1KΩ nehmen können – das spielt keine große Rolle, denn wir schalten ohnehin den Transistor ganz durch.

An den Kollektoreingang habe ich dann IN1 des Relais gehängt, an die Basis vor den Widerstand meinen GPIO der Raspberry. GND muss an den Emitter und dann kann man mit 3,3V des GPIOs das Relais, was 5V benötigt, schalten. Die 5V gibt es ja auch an der Raspberry abzugreifen.

Ich erstelle noch ein genaues Bild, damit man die Verkabelung versteht. Da das Relais Optokoppler nutzt habe ich keine weiteren Schutzmaßnahmen (Dioden etc.) eingesetzt.

So sieht es nun aus:

Das ist das Relais, die kleine Transistorschaltung und natürlich die 230V Leitung.

Um nun schalten zu können, nutzen wir die wiring PI, die wir bereits installiert haben. Auch „loldht“ nutzt diese nämlich.

Prüft bitte, ob sie gestartet werden kann. Dazu z.B. folgenden Befehl in der Shell nutzen:

gpio -v  #gibt die Versionsnummer an

oder auch

gpio readall  #zeigt alle GPIOs an

Sollte das nicht funktionieren, müsst ihr vermutlich die wiring PI noch builden… also im Verzeichnis von wiring PI den Befehl

./build

aufrufen.

So. Wenn das läuft könnt ihr einen einfachen Test machen – ihr habt ja noch die Tabelle mit den GPIOs. Ihr wisst ja, wiring PI nutzt eine andere PIN-Nummerierung – aber man kann beim Aufruf die gewünschte Zählweise definieren.
Wenn man nicht die wiring PI Zählweise nutzen will, sondern die GPIO Zählweise, kann man z.B. die Option -g nutzen. Das werden wir nun nutzen.

Als ersten müssen wir unseren PIN, in meinem Beispiel GPIO14, als OUTPUT definieren. Sonst können wir ihn nicht schalten. Das geht so:

gpio -g mode 14 out   #setzt GPIO14 als Output

Das müssen wir übrigens nach jeden Neustart wiederholen. Ich habe daher diesen Befehl in einem Skript abgelegt und starte es beim Start. Das kann man z.B. über die Datei rc.local definieren, die im /etc Verzeichnis liegt. rc.local startet beim Hochfahren Programme oder Skripte und zwar mit root Rechten.

Nun ist unser Pin also ein Ausgang. Nun können wir ihn Ein- und Ausschalten:

gpio -g write 14 1   #setzt GPIO14 auf 3,3V (high)
gpio -g write 14 0   #setzt GPIO14 auf 0V (low)

Diesen Code nutzen wir später in unserem eigentlichen Skript, um den Ventilator an und aus zu schalten. Jetzt testen wir damit, ob alles richtig verkabelt ist.
Das Relais zeigt über eine DIODE an, ob es angezogen ist. Mit dem gpio readall Befehl, kann man sehen, ob das Register auf 1 oder 0 steht und ob der Pin auch wirklich als OUT definiert wurde und ein Messgerät hilft im Zweifel auch.

Mein Ventilator dreht sich jedenfalls nun, wenn ich den Pin auf high setze:

Nun müssen wir den Ventilator noch einbauen und dann können wir statt via Email zum Lüften aufzufordern, den Ventilator einschalten und die Email nutzen wir dann nur als Info, dass nun gelüftet wird.

Ich bin gespannt, wie viel das bringt und wie oft er anspringen wird. Sicherlich werden wir da noch etwas Feinschliff benötigen…

Nun aber… der Lüfter kommt

Jetzt sind die Wochen wieder ins Land gezogen und ich bekomme fleissig mails, ich sollte lüften, schön morgens um 5 oder 6 Uhr.

Dafür wollten wir doch einen Lüfter einbauen, oder?

Ich konnte mich einfach nicht entscheiden: Wo und welchen. Ob Zuluft und Abluft oder nur Abluft usw.

Nun muss es aber mal losgehen und ich habe folgende Dinge bewertet und daher eine Entscheidung getroffen:

1. Das Volumen des Kellers beträgt ca. 150m^3. Ein Lüfter, der so 100m^3 pro Stunde schafft, erscheint mir nicht ausreichend. Das geht für ein kleines Bad, ab er für den Keller muss er so lange an sein, um einen Luftaustausch vorzunehmen. Zumal sicherlich nicht nach 1,5h die Luft ausgetauscht wäre, sondern das dauert vermutlich länger, weil sich die Luft vermischt. Und im Sommer haben wir ggf. nur ein kurzes Zeitfenster zum Lüften.
   Nebenbei haben wir ja schon festgestellt, dass Intervalllüften besser ist – dazu müssen wir aber erstmal Stoßlüften per Ventilator hinbekommen, was kaum möglich ist.
   Trotzdem: Wir brauchen Leistung. ToolTime like.
2. Mit 100er Rohren als Wanddurchbruch, die ich zufällig im Keller schon habe, werden wir das nicht erreichen. 100er Lüfter müssten sehr schnell drehen, nur um 150m^3/h zu schaffen. Wenn wir aber eher Richtung 300-700m^3/h gehen wollen, werden wir mit 100er niemals hinkommen.
   Außerdem sind diese Lüfter laut, da sie schnell drehen müssen. Je größter der Lüfter, desto langsamer kann er drehen. >2000U/min sind nicht mein Ziel. Besser wären eigentlich eher so 1200/min. Man kennt das ja von seinen PC-Lüftern…
3. Wir müssen den Luftstrom messen und sehen, woher er sich die Luft holt. Sinnvoll ist sicherlich eine definierte Zuluft. Also Zuluft- und Abluft per Lüfter. Ich werde aber mit Abluft starten und mit einem Dräger FlowCheck (erzeugt „Rauch“ über die Verdampfung von Ethanol) mir angucken, woher die Luft kommt. Ich habe verschiedene Öffnungen im Mauerwerk. Mein Ziel ist es alle zu schließen bis auf 1-2, dort die Luft anzuziehen. Gggf. kommen da Rohre und Lamellenverschlüsse rein, damit sie nur bei Unterdruck aufgehen. Aber da muss man sehen, ob der Unterdruck reicht…
4. Es gibt viele Lüfterhersteller und alle sind mir nicht bekannt oder wenn doch, wird es richtig teuer.
   Ich denke ich starte mit einer günstigen Lösung. Mein Favorit war der Vario 230/9. Der kostet aber auch gutes Geld und bietet Optionen, die ich nicht benötige. Der kleine Bruder Vario 150 scheint mir zu schwach auf der Brust, wäre aber vielleicht doch eine geeignete Wahl.
   Recht günstig und einfach sind die Cata Lüfter. Z.B. der CATA LHV 225 oder der kleinere LHV 190.
   Ich habe mich nun für einen LHV225 entschieden mit zusätzlicher Lamellenabdeckung. Als ersten Versuch sollte das reichen und das ist kein großer finanzieller Aufwand (65€ all inclusive) …

Plan:

Ich habe eine Bauplatte besorgt, die ein kleines Kellerfenster ersetzen wird, was unter der Terrasse liegt und somit ohnehin kein Licht bringt. Dort kommt der Lüfter rein, der als Fensterlüfter eingebaut werden kann (also auch in dünne Platten). Diese Bauplatten sind 6mm dick und zu 100% witterungsbeständig. Also der ideale Ersatz für das Fenster, aber gut zu bearbeiten.

Da mein Fenster Sprossen hat, musste ich so „radikal“ vorgehen. Ist aber ein uraltes Fenster im Keller, also unkritisch.

Ich überlege noch ob wir über ein Relais oder HUE steuern, tendiere aber zum Relais. Die nächste Aktion ist also Einbau des Lüfters und ansteuern über das Relais via Rasberry.

Anschließend werden wir mit dem FlowCheck den Luftstrom angucken und mit den Öffnungen im Mauerwerk spielen und gucken, ob wir da eine gute Sache hinbekommen.

Falls er aber die Luft doch woanders – z.B. von oben – holen sollte, müssen wir auch Zuluftventilatoren setzen. Dann haben wir ganz klar definierte Verhältnisse und vielleicht wäre das auch klug. Mit den CASA Ventilatoren scheint mir das finanziell auch machbar…

Melde mich, wenn alles da und eingebaut ist.