Smart Gemeindehaus I – Installation

Mit möglichst günstigen Mitteln werde ich ein SmartHome-System für ein Gemeindehaus bauen um Heizkosten zu sparen. Dafür werden mittels Raspberry Pi, MQTT, Zigbee, NodeRed und Nextcloud die Heizkörper über eingetragene CalDav-Termine gesteuert.

Die Vorgeschichte und die Vision

Seit Anfang Oktober bin ich nicht mehr im Landeskircheamt als Social Media Pfarrer unterwegs, sondern widme mich neben Kirche.plus nun mit meiner anderen halben Stelle der Kirchengemeinde Pivitsheide. Die dortige Kirche mit angeschlossenen Gemeinderäumen ist nach dem zweiten Weltkrieg gebaut und wird durch viele interne und externe Gruppen belegt. Durch die Sparbemühungen angesichts vorausgesagter Energieknappheit im Winter 2022/23 kamen Überlegungen in den Gang, wie besser geheizt werden könnte – ohne dass eine Stunde vor Gruppenbeginn jemand zur Kirche gehen/fahren muss.

Als erstes wird der Raspberry Pi * mit PiOS installiert und ins lokale Netzwerk gebracht. Dafür gibt es so viele Tutorials, dass ich das hier überspringe. Wer daran scheitert, sollte sich dringend Mitstreiter:innen suchen, die etwas Ahnung von Linux haben, damit bei Problemen nicht der Supergau droht. Meine Empfehlung unter Windows ist der Pi Imager und die Lite-Variante (zumindest wenn man die grafische Benutzeroberfläche nicht anderweitig braucht). Im Imager kann man übrigens ganz bequem festlegen, welches Tastaturlayout, welchen Benutzernamen und welches Wlan man nutzen möchte. Darüber hinaus – für mich das Wichtigste: Man kann ssh aktivieren!

Der Kommunikator: MQTT bzw. Mosquitto

MQTT ist ein Protokoll, was sich wunderbar für unser Vorhaben eignet. Ein zentraler Server (Mosquitto) nimmt Nachrichten in benannten Kanälen (Topics) von Sendern an und leitet sie an Empfänger weiter, die genau diese Topics abonniert haben. So kann ein Thermometer seine Temperatur mit nur einer Nachricht an X beliebige Empfänger senden, in dem es nur den Mosquitto-Server kennt und der wiederum die Geräte, die die Temperatur wissen wollen.

// das System nach der Installation auf den neuesten Stand zu bringen
sudo apt update
sudo apt upgrade

// vorsichtshalber einmal rebooten und dann die eigentliche Installation
sudo reboot
sudo apt install mosquitto mosquitto-clients

// und dann noch bei jedem Start starten lassen
sudo systemctl enable mosquitto

Jetzt gilt es noch, den Mosqitto zu konfigurieren. Entweder mit anonymem Zugriff oder mit User und Passwort. Dazu öffnet ihr die Konfigurationsdatei: sudo vi /etc/mosquitto/conf.d/local.conf (ihr könnt natürlich statt dem Texteditor vi auch nano oder emacs nehmen) und schreibt/kopiert dort

listener 1883
allow_anonymous true

// oder für den Nutzerzugriff:

listener 1883
allow_anonymous false
password_file /etc/mosquitto/credentials

rein. Dazu müsst ihr natürlich auch entsprechende Datei mit euren Credentials anlegen. Das geht glücklicherweise einfach mit dem Befehl: sudo mosquitto_passwd -c /etc/mosquitto/credentials mqttuser

Bis jetzt hat das bei mir immer ausnahmslos gut geklappt und ich spare mir die Tests, ob das alles so funktioniert. Wer Testen und ein bisschen mehr wissen möchte: Ausführlicher gibt es das in diesen Artikel.

Der Hintergrundserver: Node.js

Um im nächsten Schritt NodeRed zu laufen zu bekommen, brauchen wir einen Node.js Server. Da die Paketquellen gewöhnlich recht alte Versionen anbieten, machen wir das mithilfe eines Scripts, das uns direkt zum nächsten Schritt führt:

Das Hirn: Node-Red

Node-Red und Node.js installieren wir mittels Script:

bash <(curl -sL https://raw.githubusercontent.com/node-red/linux-installers/master/deb/update-nodejs-and-nodered)

Bei einer der letzten Installationen kam eine Fehlermeldung, es sei kein npm istalliert. (Vermutlich ist das in einer der letzten Versionen von Raspbian Lite rausgeflogen.) Also kommt in dem Fall vor dem Script noch ein sudo apt install npm

(dann starten wir die Konfigiration „node-red admin init“) <– In der jetzigen Version des Installationsscriptes ist das nicht mehr nötig, weil die Abfragen schon im Installationsprozess kommen.

Direkt im Installationsprozess oder eben mit dem Konfigurationsscript werden einige Dinge, wie die Zugriffsrechte, Dateinamen u.a. abgefragt. Der gesunde Menschenverstand und genau Lesen sollte dazu in den meisten Fällen ausreichen. Neben der Passwortsicherheit sollte man sich auch anderweitig mit Sicherheit beschäftigen. Hierzu gibt es diese Seite direkt bei den Entwicklern. Als nächstes testen wir, ob NodeRed läuft.

node-red-pi --max-old-space-size=256

Nun gebt ihr in einen Browser im selben Netzwerk folgendes ein: http://IP_des_NodeRedPIs:1880 Es sollte nun etwas anderes als eine Fehlermeldung kommen. 😉 Nach einem beherzten strg-c killen wir NodeRed wieder, nur um es als Prozess mit einem Autostart beim Hochfahren des Raspberry Pis zu versehen.

Hierzu öffnet man die eine entsprechende Datei sudo vi /lib/systemd/system/nodered.service und befüllt sie. Das sieht in der Regel dann so aus:

[Service]
Type=simple
User=dein_benutzername
Group=dein_benutzername
WorkingDirectory=/home/dein_benutzername

Jetzt lassen wir das System diese Konfiguration nochmal neu einlesen und starten dann den Autostart:

sudo systemctl daemon-reload

sudo systemctl enable nodered

Sollte irgendetwas nach dem Neustart nicht so laufen wie geplant, könnt ihr mit sudo systemctl status nodered nachschauen, wo es hakt. Der Befehl eignet sich entsprechend modifiziert natürlich genau so für Mosquitto und später für zigbee2mqtt.

Auch hier gibt es einen guten und ausführlicheren Artikel vom Elektronik Kompendium, das allerdings nodered auf eine andere Art installiert (bitte bringt nicht die beiden Installationsarten durcheinander, wenn ihr nicht wisst, was ihr tut).

Die Brücke zur physischen Welt: Zigbee-Stick und zigbee2mqtt

Als Zigbee-Stick habe ich den SONOFF Zigbee 3.0 USB Dongle Plus ZBDongle-P genommen. Ganz wichtig: Am Ende muss das P stehen, auf keinen Fall ein E oder gar nichts, es braucht momentan (noch) den CC2652/CC1352 Chip!

Die Installation von zigbee2mqtt ist auf der Projektwebsite gut dokumentiert. Wichtig ist allerdings, dass ihr node.js nicht noch mal installiert. Dort findet ihr neben der Anleitung zum Autostart auch eine Anleitung zum späteren Update.

Für alle, die es schnell mögen: Stellt sicher, dass ihr die interne Bezeichnung eures Sticks kennt (in vielen Fällen /dev/ttyACM0 bei mir war es allerdings /dev/ttyUSB0.

//Ein Verzeichnis anlegen und entsprechende Rechte vergeben
sudo mkdir /opt/zigbee2mqtt
sudo chown -R ${USER}: /opt/zigbee2mqtt

// Clone den Code aus dem Zigbee2MQTT repository
git clone --depth 1 https://github.com/Koenkk/zigbee2mqtt.git /opt/zigbee2mqtt

//In das Verzeichnis wechseln und Abhängigkeiten nachinstallieren
cd /opt/zigbee2mqtt
npm ci

//Sollte da die Fehlermeldung ERR_SOCKET_TIMEOUTkommen, versucht stattdessen: npm ci  --maxsockets 1

// Und zum Schluss das Programm bauen:
npm run build

// Die Beispielkonfiguration kopieren und bearbeiten:
cp /opt/zigbee2mqtt/data/configuration.example.yaml /opt/zigbee2mqtt/data/configuration.yaml
vi /opt/zigbee2mqtt/data/configuration.yaml

Wenn ihr euren Mosquitto-Server mit Benutzern ausgestattet habt und anonymen Zugriff verboten habt, müsste ihr vor dem Start von Zigbee2mqtt die /opt/zigbee2mqtt/data/configuration.yaml im Punkt mqtt um eure Zugangsdaten ergänzen:

mqtt:
  base_topic: zigbee2mqtt
  server: mqtt://localhost
  user: euer_Mosquitto_Benutzername
  password: euer_Mosquitto_passwort

Vergesst nicht, etwas weiter unten auch euren Adapter ggfs. anzupassen.

Für den Autostart legt ihr die entsprechende Datei mit sudo nano /etc/systemd/system/zigbee2mqtt.service an:

[Unit]
Description=zigbee2mqtt
After=network.target

[Service]
Environment=NODE_ENV=production
Type=exec
ExecStart=/usr/bin/npm start
WorkingDirectory=/opt/zigbee2mqtt
StandardOutput=inherit
# Or use StandardOutput=null if you don't want Zigbee2MQTT messages filling syslog, for more options see systemd.exec(5)
StandardError=inherit
Restart=always
RestartSec=10s
User=pi

[Install]
WantedBy=multi-user.target

Falls ihr einen anderen Benutzernamen als pi bei der Installation eures Betriebssystems gewählt habt, müsst ihr den hier entsprechend ändern!

Nach der Installation und des Starts (ob nun per Kommandozeile oder per Autostart nach einem Neustart) kann es nun im Browser auf http://IP_des_NodeRedPIs:8080/ weitergehen. Eigentlich kann es nun an das Einbinden der Sensoren, Aktoren, wasauchimmer gehen.

Weiter geht es in den nächsten Tagen mit dem Einrichten, Verknüpfen und ersten Flows.

Sensoren, Steckdosen, Schalter und Geräte zum Basteln, um auch Wasser- und Stromzähler im Auge zu behalten (letztere allerdings per Wlan)

Der Vollständigkeit halber: Es gibt natürlich auch andere Systeme, die ebenfalls OpenSource Software sind und teilweise auch einfacher aufzusetzen und zu bedienen sind. Aber gerade im Gemeindehaus- und Kirchenkontext sind meiner Meinung nach die Anforderungen so komplex, dass ich lieber den flexibleren Weg gewählt habe. Wer es einfacher versuchen will sollte sich laut einem anderen LUKi-Mitglied mal HomeAssistent anschauen. Da arbeitet auch Zigbee2mqtt gut mit zusammen.

SmartGemeindehaus Artikel:
I-Installation | II-Verbindungen schaffen (und Hardware) | III-Erste Automatisierung |
IV – Speichern + Visualisieren

*Hardware: Nehmt einen RasPi 4 mit 4GB Ram, der kann 64 Bit und hat Reserven (für eine Erweiterung um InfluxDB und Grafana). Wenn euch der Stromverbrauch egal ist und ihr noch mehr Reserven braucht, dann ist auch ein Pi 5 empfehlenswert.
Da der neue und gehypte Standard „Matter“ noch in den Kinderschuhen steckt und bis jetzt sehr teuer ist bzw. vermaktet wird, obwohl die Geräte nur ein Update auf Matter bekommen können, geht es Richtung Zigbee. Wenig Energiebedarf, leichter cloudloser Einsatz und die Mesh-Funktionalität sind die Hauptentscheidungsgründe.
TLDR: Angefangen habe ich mit einem Raspberry Pi 3. Der Raspberry Pi 1 und der Raspberry Pi Zero (W) eignen sich nicht so gut, weil der verwendete ARM6-Prozessor nicht so gut mit Softwarepaketen versorgt wird. Im weiteren Verlauf arbeitete ich mit einem Raspberry Pi Compute Module 4 ohne verlöteten Speicher und mit 2GB Ram auf einem DFRobot Pi Tray Mini ohne Funkchips. Für mich die bessere Wahl, erstens, weil sie zu dem Zeitpunkt lieferbar war und zweitens weil sie nicht unnötig Strom vergeudet, weil der Pi eh über ein Netzwerkkabel angeschlossen werden soll.
Das Compute-Module erwies sich im späteren Verlauf auch schwierig, weil es mit den GPIOs nicht klar kam (zumindest nicht mit den Neopixeln, die ich irgendwann angeschlossen habe). Solange man nicht mit den GPIOs arbeiten möchte und auf Wlan verzichten möchte, ist das Compute-Module vermutlich weiterhin die beste Wahl. Ich setze momentan auf einen RasPi 4 mit 4GB Ram, den es ja mittlerweile wieder recht zuverlässig zu kaufen gibt.

erLoest