Projekt 23 Smarthome

Aus c3RE.de
Wechseln zu: Navigation, Suche

Projekt 23 SmartHome

Projektbeschreibung:

An dieser Stelle soll beispielhaft eine SmartHome-Umgebung beschrieben werden. Diese Projektseiten dienen hauptsächlich den folgenden Zwecken:

  • Erarbeitung des notwendigen technischen Wissens zur Umsetzung der Dienste
  • Dokumentation der zum Verständnis notwendigen Punkte zur Verwendung in anderen Projekten

Abgrenzung: Es handelt sich nicht um eine allgemeine Abhandlung zu dem Thema. Vielmehr soll hier am Beispiel eines konkreten Projektes mit einer bestimmten Zielsetzung und technischen Infrastruktur Lösungsansätze gezeigt werden.

Konkrete Zielsetzung des Projektes

  • Netzwerkbasierter Zugriff auf die Daten der installierten Geräte (Devices) eines Hauses. Beispielhaft seien hier der KNX-Bus, eine Wärmepumpe und ein Wechselrichter (Photovoltaik) genannt.
  • Zentrale Speicherung der Daten
  • Nutzung der Daten für die situationsabhängie Steuerung von Geräten (Beispiel: Betrieb eines Wäschetrockners in Abhängigkeit von der Menge des aktuell erzeugten PV-Stroms). Hier ist der Fantasie des Nutzers kaum Grenzen gesetzt. Wenn die Verbindung der Geräte einmal implementiert und eine gewisse Logik-Engine aufgesetzt ist, dann können beliebige Szenarien automatisiert werden. Have a lot of fun...
  • Schaffung von Transparenz über die Qualität der einzelnen Services im Betrieb. Für viele Systeme im Haus sind Informationen über Betriebszustände wichtig. Beispielsweise eine Visualisierung der Leistungsdaten von PV-Anlage und Heizung oder ein Monitoring von Grenzwerten mit Notfall-Benachrichtigung.
  • Statistik als Basis für die (monatliche) Umsatzsteuererklärung zur PV-Anlage
  • Senkung des Stromverbrauches sowie Steigerung der Eigenverbrauchsrate durch Schaffung von Transparenz einerseits und Einführung von intelligenten Prozessen andererseits. Motivation: Klimaschutz und Geldbeutel.

Randbedingungen

  • Datenschutz: Die Privatsphäre ist den Nutzern sehr wichtig. Alle anfallenden Daten sollen in eigenen Systemen gehostet und verarbeitet werden. Der Zugriff auf diese Daten erfolgt ausschließlich aus der eigenen Netzwerk-Infrastruktur bzw. über abgesicherte Kanäle wie ein VPN. Auslagern von Infrastruktur-Diensten beispielsweise zum Hersteller von Produkten oder irgendwelche Cloud-Dienste sollen nach Möglichkeit vermieden werden oder in Ausnahmefällen bei zwingender Notwendigkeit transparent gemacht und isoliert werden.
  • Sicherheit: Sicherheit ist das Vehikel, um die Datenschutz-Ziele umzusetzen. Dementsprechend hoch sind die Maßstäbe hier anzulegen.
  • Schützenswert sind die im Haus anfallenden Daten, weil sie einen tiefen Einblick in die Privatsphäre der Bewohner erlauben.
  • Das gilt aber nicht nur für den Schutz der Daten, die im Projekt anfallen. Es soll explizit auch darauf geachtet werden, dass die hier verwendeten Services und Devices keine Einfallstore bilden, um andere Systeme im internen Netzwerk anzugreifen (und umgekehrt).
  • Auch der finanzielle Wert einer solchen Anlage legt nahe, auf ein möglichst hohes Maß an Sicherheit zu achten. So kann im Extremfall eine Beschädigung von Hardware wie beispielsweise das 'Veröden' einer Tiefenbohrung (Geothermie) einen sehr hohen finanziellen Schaden ausmachen. Dieser Gefahr muss sich der Betreiber einer solchen Anlage bewusst sein, wenn er die Anlage vernetzt und (auf welchem Wege auch immer) an das Internet anschließt.
  • Die Verwendung von freier Software und Protokollen wird bevorzugt - wohl wissend, dass gerade in einem solchen Bereich Hersteller-spezifische Lösungen und Protokolle existieren und diese nicht immer umgangen werden können (Aufwand, Garantieansprüche...).

Technische Infrastruktur

Internes Netzwerk

Es besteht ein strukturiertes Netzwerk (IPv4), an welchem alle Devices angeschlossen werden. Dabei wird das Netz aufgeteilt in dedizierte Subnetze für verschiedene Anwendungsbereiche. Diese Strukturierung erfolgt auf Basis von:

  • VLAN-fähiger Hardware (managed switches)
  • Netzwerk-Komponente, welche die Subnetze konfiguriert/implementiert
  • Firewall zur Steuerung der Kommunikation zwischen den Subnetzen. Übergänge zwischen den Subnetzen und nach außen laufen immer ausschließlich durch diese Firewall.
  • DHCP-Server für die interne Ressourcen-Zuordnung

Relevante Subnetze für dieses Projekt sind:

  • 172.16.20.0/24 KNX
  • 172.16.21.0/24 Service (Backup...)
  • 172.16.22.0/24 Power (Wechselrichter, Zähler, Logger...)

Hardware

SmartHome-Server: 'APU 1D4 (PC-Engines)'

Dieses Board wurde ausgewählt aufgrund des günstigen Stromverbrauchs bei angemessener Leistung, einem angemessenen Anschaffungspreis, dem Verzicht auf UEFI aus Sicherheitsgründen, der Verfügbarkeit von 3x 1-GBit-Interfaces für saubere Separation und Performance, der robusten Ausführung für entsprechende Langlebigkeit, guter Erfahrung mit den Produkten dieses Herstellers in der Vergangenheit sowie der Verbreitung dieser Hardware in anderen Bereichen offener Software im Security-Kontext.

Nachteilig: Die Installation von aktuellen Linux-Distributionen ist aufgrund des seriellen Interfaces nicht ganz trivial.

Das Betriebssystem ist derzeit CentOS7.

'MDT KNX-IP-Interface SCN-IP000.01'

Integration von KNX-Bus an das IP-basierte Netzwerk.

KNX-Hardware

Im Zuge einer Kernsanierung wurde ein Teil eines Einfamilienhauses mit KNX ausgestattet. Hauptsächlich wurden Geräte des Herstellers MDT verbaut, wobei KNX durchaus hersteller-unabhängig und kombinationsoffen konzipiert ist.

Ethernet-Verkabelung

Es wurde darauf geachtet, an möglichst vielen Stellen Kabel verfügbar zu haben, um die Nachtteile von Funknetzen (Sicherheit, Shared-Network, Gesundheit, Stromverbrauch) zu umgehen oder zumindest deren Notwendigkeit zu reduzieren.

Wechselrichter 'SMA Sunny Tripower 10000TL-20' (Photovoltaik-Anlage)

Neben den Solar-Panelen auf dem Dach und der Verkabelung bildet der Wechselrichter das Herzstück der PV-Anlage zur Stromerzeugung. Hier ist die eigentliche Intelligenz der Anlage angesiedelt und hier fallen auch die relevanten Daten an. Verbaut wurde ein Wechselrichter vom Typ 'SMA Sunny Tripower 10000TL-20'. Er verfügt über zwei netzwerkfähige Schnittstellen:

  • Bluetooth
  • Ethernet

Stromzähler 'EMH Zweirichtungszähler EDL300L'

Dieser digitale Stromzähler bildet die Schnittstelle zwischen dem internen und dem externen Stromnetz. Hauptfunktionalität:

  • Zählen der aus dem öffentlichen Netz bezogenen Strommenge
  • Zählen der in das öffentliche Netz eingespeisten Strommenge

Hierzu werden zwei unterschiedliche Tarife verwendet. Zur Ablesung der Informationen steht neben einem Display auch eine optische Schnittstelle bereit.

Heizung Wärmepumpe 'Stiebel Eltron WPF 10'

Ein Sole/Wasser-Wärmepumpe mit angeschlossenem Warmwasser-Speicher 'SBB 300 basic' des selben Herstellers, welche an einer Tiefenbohrung angeschlossen ist (Geothermie). Diese Komponente als größter Energieverbraucher und Wärmelieferant bietet ein interessantes Ziel für eine Smarthome-Anbindung. In der Standard-Installation bietet dieses System keine Schnittstelle für eine Netzwerk-Anbindung. Leistungswerte können nur am Display abgelesen werden, was aus statistischen Zwecken bis zu einer smarteren Lösung auch jeden morgen gemacht wird.

Primäres Ziel ist hier die kontinuierliche und vollständige Erfassung der Daten, um daraus qualifizierte Rückschlüsse ziehen zu können. Ein aktiver Eingriff in die Steuerung ist derzeit nur ein nachrangiges Ziel.

Projektstatus

  • Das IP-basierte Netzwerk ist wie beschrieben eingerichtet
  • Der Wechselrichter ist an das Netzwerk angeschossen und die Funktionalität ist mittels proprietärer Windowssoftware des Herstellers getestet. Jeglicher Zugang nach außen oder in andere Subnetze wird von der Firewall protokolliert und geblockt. Die Daten werden über das OpenSource-Tool SBFspot ausgelesen und in die Datenbank geschrieben.
  • Das KNX-IP-Interface ist angeschlossen und ist in Betrieb. Jeglicher Zugang nach außen oder in andere Subnetze wird von der Firewall protokolliert und geblockt.
  • Eine virtuelle Maschine (VM) als erster Versuch wurde im Subnetz 172.16.20.0/24 eingerichtet und ist an das zentrale Backupsystem angeschlossen.
Getestete Funktionalität auf Basis von eibd:
  • Kontinuierliches Logging der KNX-Events ('Telegramme') zu Debug-Zwecken im Journal (systemd) der VM
  • Schreibender Zugriff auf einzelne KNX-Devices (Licht an, Rollladen runter...)
  • Minimales cron-basiertes Szenario zum Einbruchsschutz bei Abwesenheit
  • Installation des 'echten' SmartHome-Servers auf einer APU 1D4. Betriebssystem inklusive Backup sind aufgesetzt, das System ist physisch angeschlossen und 3 Subnetze liegen auf den realen IP-Interfaces an.
  • Die Infrarot-Schnittstelle des Stromzählers wird kontinuierlich abgefragt und dessen Daten (Zählerstände) in der Datenbank protokolliert. Hierzu wurde ein kleines Tool auf Basis von 'openMUC' (Java) entwickelt und unter OpenSource-Lizenz freigegeben. Als IR-Hardware wird der im Projekt 'Volkszähler' entwickelte Lesekopf eingesetzt.

Da wahrscheinlich im späteren Projektverlauf auch security-relevante Daten auf diesem System liegen werden, wurde eine Vollverschlüsselung der Festplatte auf Basis von LUKS/LVM durchgeführt. Das hat den Nebeneffekt, dass das System nur nach manueller Eingabe einer Passphrase an der seriellen Konsole bootet. Hoffentlich ist das nicht so oft notwendig...

Offen: Nach dem Start ist das System nach ersten Beobachtungen nicht immer vollständig erreichbar. Mögliche Ursache: http://brainscraps.wikia.com/wiki/Setup_Gateway_Routing_On_Multiple_Network_Interfaces

Pläne

  • Phase 1: Netzwerk und Infrastruktur
  • Phase 2: Vollständige Installation des eigentlichen Smarthome-Servers (OS, Network, Backup)
  • Phase 3: Relevante Devices zugreifbar machen und Sammlung der Daten in RDBMS (mysql?). Betroffene Systeme:
    • KNX: Bus-Zugriff sowie Logging via eibd in das Journal von systemd
    • Wechselrichter (Middleware SBFspot)
    • Stromzähler: Optisches Interface für Erfassung und davon abhängiger Middleware evaluieren. Siehe evtl. Projekt 'Volkszähler'
    • Heizung: Netzwerk-Anbindung und alles weitere evaluieren <aktuell>
  • Phase 4: Implementierung der eigentlichen 'smarten' Logik auf Basis noch zu evaluierender Software (derzeitiger Favorit: 'openHAB')
  • Phase 5: Visualisierung der Systeme und Prozesse
  • Phase 6: Monitoring (Nagios)

Umsetzung

Datenanalyse

Die in den unterschiedlichen Teilprojekten auflaufenden Daten sollen übergreifend analysiert werden, um die skizzierten Ziele erreichen zu können: Projekt 23 Smarthome / Datenanalyse.

Ideen

Eine Sammlung von Ideen, was in einer solchen SmartHome-Umgebung mehr oder weniger sinnvoll umgesetzt werden könnte: Projekt 23 Smarthome / Ideen