Homeserver Teil 2

Nachdem im vorherigen Beitrag zum Homeserver die Hardware kurz vorgestellt wurde geht es jetzt um die Installation der eigentlichen Steuerung. Voraussetzung ist ein lauffähiges Raspbian auf dem Pi.

KNX-Dämon

Standards, mehr oder weniger offen, für die Ansteuerung von Haustechnik gibt es viele. Bei uns kommt primär KNX zum Einsatz, welches den Vorteil hat ein offener Industriestandard zu sein und mit (hoffentlich) entsprechend langfristiger Unterstützung und herstellerunabhängiger Nutzbarkeit der Komponenten einhergeht. Kein Vendor-Lock-in mehr. Bislang scheint das für unser System auch hervorragend zu funktionieren.

Zur Ansteuerung der Komponenten benötigt es aber ein Gateway. Entweder eines der kommerziellen IP-Gateways oder wie hier über ein Hardwaremodul auf dem Raspberry Pi. Dieses benötigt allerdings noch einen Dämon zur Ansteuerung, der sowohl die Programmierung der Komponenten für ihre nativen Funktionen erlaubt als auch Zugriff für die Steuerzentrale für erweiterte Funktionen.

Dazu gibt es mit knxd eine freie Alternative, die sich auch problemlos auf dem Raspberry Pi einbinden lässt. Mit der zum aktuellen Zeitpunkt verfügbaren Version im Hauptentwicklungszweig, 0.14 (genau genommen der Commit 61a08e5fa5ce4cc6d47309bf80f9abc1fd792637, da sich Version 0.14 noch aktiv in der Entwicklung befand), gab es bislang keine Probleme, weder beim Programmieren der Geräte noch bei der Ansteuerung von Komponenten über den Homeserver.

Für den Raspberry Pi gibt es einen eigenen Abschnitt zur Konfiguration der Schnittstelle: https://github.com/knxd/knxd#adding-a-tpuart-serial-interface-to-the-raspberry-pi

Automatisierung mit OpenHAB

Visualisierung und Ansteuerung der Komponenten läuft dann über das freie OpenHAB-Projekt. Für KNX gibt es Alternativen, aber insbesondere durch die große Community, die Auswahl an Plugins und die Anbindung an unzählige weitere Standards (Jemand mit Tesla Modell S hier?) führt an Openhab kaum ein Weg vorbei.

Docker auf dem Raspberry Pi

Die Installation von OpenHAB ist mehr oder weniger aufwändig. Glücklicherweise existieren verschiedene Optionen auch für den Raspberry. Eine davon ist openHABian als eigene Distribution, die Raspbian als OS auf der SD-Karte ersetzt. Eine Alternative ist die Nutzung von Docker.

Docker ist eine sogenannte Containerisierungs-Lösung, die einzelne Software bis hin zu ganzen Betriebssystemen kapselt und (mehr oder weniger) unabhängig vom eigentlichen System ausführbar macht. Hauptvorteil ist damit der schnelle Wechsel zwischen verschiedenen Versionen und im Fehlerfall die Rückkehr auf die letzte funktionierende Version ohne sich mit Abhängigkeiten von anderen Paketen beschäftigen zu müssen.

Die Installation von Docker auf dem Raspberry funktioniert reibungslos über die Angabe von curl -sSL https://get.docker.com | sh auf der Kommandozeile, siehe den Artikel Docker comes to Raspberry Pi.

Fertige Images gibt es öffentlich verfügbar über den Dockerhub unter (https://hub.docker.com/r/openhab/openhab/). Eine mögliche Variante für den Raspberry wäre demnach

docker run \
        --name openhab \
        --net=host \
        --tty \
        -v /etc/localtime:/etc/localtime:ro \
        -v /etc/timezone:/etc/timezone:ro \
        -v openhab_addons:/openhab/addons \
        -v openhab_conf:/openhab/conf \
        -v openhab_userdata:/openhab/userdata \
        -d \
        --restart=always \
        openhab/openhab:2.3.0-armhf-debian

Die Option --restart=always sorgt dabei dafür, dass Openhab auch nach dem Reboot oder bei Abstürzen automatisch wieder gestartet wird. Die -v openhab...-Optionen machen Ordner außerhalb des Images, d.h. vom Raspberry, innerhalb des laufenden Openhab-Containers verfügbar. Dies ist insbesondere dann hilfreich wenn die Daten nicht auf der SD-Karte des Raspberrys landen sollen, z.B. aus Backup-Gründen oder um die Lebenszeit der SD-Karte durch weniger Schreibzyklen zu erhöhen. Aus denselben Gründen kann das gesamte Docker-Root, in dem Images und Container liegen, beispielsweise auf ein NAS verlagert werden. Dem Thema widmet sich der nächste Abschnitt.

Um auch den Docker-Daemon bei jedem Boot wieder zu starten (denn auch nur dann starten die Container wieder automatisch) muss der Service aktiviert werden: sudo systemctl enable docker

Einbinden eines NAS

Die SD-Karte im Raspberry Pi ist (meist) klein und mit der Begrenzung an Schreibzyklen auch anfällig für Datenverlust (wer hebt bei regelmäßigen Vollbackups des mühselig angelegten Systems die Hand?). Eine Möglichkeit ist Verzeichnisse mit großen Datenmengen oder Dateien mit regelmäßigen Schreibzyklen auf ein Network Attached Storage zu verlegen.

Im Wesentlichen bedeutet das hier eine Verlegung des Docker-Datenverzeichnisses und der OpenHAB-Konfiguratinsverzeichnisse. Dazu ist jeweils ein Eintrag in der /etc/fstab-Datei notwendig:

//<nas-ip>/docker /docker cifs user=<nasuser>,password=<naspasswort>,uid=root,gid=root,sec=ntlmv2,file_mode=0644,dir_mode=0755,nounix,sfu 0 0
//<nas-ip>/openhab /openhab cifs user=<nasuser>,password=<naspasswort>,uid=root,gid=root,sec=ntlmv2,file_mode=0700,dir_mode=0700,noperm,nounix 0 0

Zwingend notwendig sind natürlich die Angabe der korrekten IP-Adresse zum NAS, die Pfade zu den Ordnern im NAS und die Zugangsdaten eines dazu angelegten Users. Wer sein Passwort nicht in der fstab im Klartext ablegen möchte, kann dies auch in eine Credentials-Datei auslagern¹.

Die übrigen Optionen waren für den Betrieb mit unserem NAS ebenfalls notwendig, z.B. um die Zugriffsrechte für Docker und den OpenHAB-Container passend zu setzen, bei der Einrichtung starten würde ich aber zunächst ohne und erst testen, ob der Zugriff auf das eigene NAS auch mit den Standardwerten direkt möglich ist.

Damit die Ordner nach einem Neustart des Raspberry Pi sicher verfügbar sind sollte in der Konfiguration dort per sudo raspi-config die Option Wait for network at boot aktiviert werden.

Um dem Docker-Daemon das neue Root für seine Daten bekannt zu geben ist diese in der Datei /etc/docker/daemon.json zu konfigurieren:

{
  "storage-driver": "devicemapper",
  "data-root": "/docker"
}

Der Storage-Driver legt fest, wie die Images und Container dort abgelegt werden. Devicemapper wird dabei explizit nicht für eine Produktiveinsatz empfohlen, da dieses unter anderem Probleme der Freigabe gelöschten Speicherplatzes hat. Leider war dies die einzig funktionierende Alternative (ymmv²) und da nicht ständig neue Container angelegt und gelöscht werden spielt der Speicherbedarf bislang (und hoffentlich auch zukünftig) keine Rolle.

Bedienoberfläche HABPanel

Der letzte (und aufwändigste, bzw. nie endende) Schritt ist dann die Konfiguration von OpenHAB und der Nutzeroberfläche. Dazu existieren verschiedene Varianten, besonders passend für den Touchscreen des Raspberry Pi ist HABPanel.

Zum Zugriff auf die Aktoren und Sensoren des KNX-Bus zu bekommen müssen diese zunächst in der jeweiligen Konfiguration definiert werden, siehe KNX-Binding.

Den sogenannten Items können dann direkt im Browser den passenden Schaltflächen zugeordnet werden.

Übersichtsseite in OpenHAB mit HABPanel als Oberfläche

Der Screenshot zeigt den Übersichtsbildschirm des Wandpanels. Neben den wichtigsten zentralen Messdaten wie Temperatur Außen/Wohnen, Feuchte und CO2-Gehalt wird per Wetterplugin auch die Wettervorhersage für die nächsten zwei Tagen angezeigt. Dazu kommt die Nachrüstung von seltener genutzter Funktionalität. So können per herkömmlichem Taster die Rollläden in Wohnzimmer und Küche nur gesamt verfahren werden, was für 90% der Fälle auch ausreicht. Mit dem Panel dagegen ist auch die Einzelsteuerung möglich.

Display auf dem Wandpanel

Die HABPanel-Oberfläche lässt sich auf jedem Gerät im lokalen Netzwerk anzeigen und nutzen. Gedacht ist sie allerdings für das Wandpanel aus dem Beitrag Homeserver - Die Hardware.

Die Anzeige übernehmen kann der Chromium-Browser per DISPLAY=:0 chromium-browser http://localhost:8080/habpanel/index.html --kiosk --incognito. Die Display-Anweisung ermöglicht den Start auch per ssh aus der Ferne. Im Kiosk-Modus wird direkt im Vollbild gestartet ohne Statusleiste und Kontrollbuttons. Der Incognito-Mode letztendlich verhindert bei Abstürzen Fehlermeldungen beim Neustart und soll auch die Anzahl der Zugriffe auf die Festplatte (bzw. hier auch gerne einmal der Flashspeicher, der nicht unendlich viele Schreibzugriffe aushält) deutlich reduzieren³.

Üblicherweise stört der Mauszeiger noch während der Bedienung, aber mit dem Tool unclutter kann dieser ausgeblendet werden. Sowohl Browser als auch unclutter können im Autostart bei jedem Neustart des Raspberry aktiviert werden: nano ~/.config/lxsession/LXDE-pi/autostart

@unclutter -idle 0
@chromium-browser http://localhost:8080/habpanel/index.html --kiosk --incognito

In der Standardeinstellung geht das Panel nach einigen Minuten in den Standby, wacht aber bei jedem Fingerdruck wieder darauf aus. Zu beachten ist lediglich, dass die Touch-Events auch im Schlafmodus an die Oberfläche weiter geleitet werden und damit unter Umständen Aktionen auslösen können. Zumindest auf der normalen Startseite sollten daher die aktiven (klickbaren) Flächen nicht zu groß sein und die Benutzer wissen, wo sie zur Aktivierung des Displays drücken dürfen.

Werden Änderungen an der HABPanel-Oberfläche vorgenommen lässt sich dies bequemer von einem PC aus erledigen. Im Browser im Wandpanel ist dann ein Refresh erforderlich, was im Kiosk-Modus gar nicht so einfach ist. Über DISPLAY=:0 xdotool key ctrl+F5 kann auch per ssh ein Refresh ausgelöst werden und dann ist auch das Wandpanel auf der neuesten Version der Nutzeroberfläche. Der Vorteil ist, dass neue Funktionen erst einmal begrenzt ausprobiert werden können bevor gleich der gesamte Haushalt mit den Neuerung konfrontiert wird.

Andere Möglichkeiten das Setup noch zu erweitern wären der Start von Chromium über supervise, welches den Prozess permanent überwacht und bei Abstürzen neu startet oder ein Browser-Addon, welches nach einer gewissen Idle-Zeit wieder auf die Startseite zurückwechselt.

https://wiki.ubuntuusers.de/Samba_Client_cifs/#Optionen ↩︎
Your mileage may vary ↩︎
https://productforums.google.com/forum/#!topic/chrome/wgKvdI7Ggj4 ↩︎