Open-Access-Kommunikation Vom Sensor bis zur Wallbox: Offene Standards für die Hausautomatisierung

Im ersten Teil dieser Serie standen die Grundlagen der Open-Access-Kommunikation im Fokus. Nun folgt die Implementierung: Anhand eines realen Forschungsprojekts wird demonstriert, wie sich maximale Flexibilität und Datensicherheit durch den konsequenten Verzicht auf Hersteller-Clouds erreichen lassen.

Vom Konzept zur Praxis: Im ersten Teil dieser Serie (Ausgabe 9/2024) standen die Grundlagen der Open-Access-Kommunikation für Sensoren und Aktoren im Fokus. Nun geht es an die Umsetzung: Anhand konkreter Implementierungsbeispiele zeigt dieser Beitrag, wie Entwickler Geräte und Automatisierungsregeln nahtlos in eine offene Smart-Home-Plattform integrieren.

Im vorangegangenen Artikel wurde die grundlegende Systemarchitektur eines durchgängig mit Open-Access-Technologien automatisierten Hauses vorgestellt. Diese Arbeiten entstammen einem freien Forschungsprojekt an der Universität der Bundeswehr München. Neben der reinen experimentellen Erprobung stand dabei unter anderem die Lernfähigkeit des Systems durch den Einsatz KI-basierter Verfahren im Fokus. Die elementaren Automatisierungsfunktionen wurden durch dezentrale Controller sowie einen zentralen Automatisierungsserver auf Basis der Open-Source-Plattform Home Assistant realisiert. Wie die hausspezifische Systemintegration in Home Assistant im Detail funktioniert, veranschaulichen die folgenden Implementierungsbeispiele.

Bedienoberflächen grafisch oder per Programmierung generiert

Bild 1 zeigt eine Auswahl der Geräte und Komponenten, die in die Hausautomatisierung des Projekts integriert wurden. Die meisten verfügen über LAN- oder WLAN-Schnittstellen. Über diese sind sie sowohl an den Home-Assistant-Server als auch an den KI-Controller angebunden (auf letzteren wird in diesem Beitrag nicht näher eingegangen). Komponenten ohne eigenen Netzwerkanschluss, beispielsweise analoge Raumsensoren oder klassische Aktoren wie Leuchten, Raffstore-Motoren und Infrarot-Heizelemente, werden über die Ein- und Ausgänge von acht dezentralen LabJack-Controllern angesteuert.

Zu Beginn des Projekts lief Home Assistant noch auf einem Raspberry Pi. Mit steigenden Anforderungen an die Leistungsfähigkeit und Robustheit des Systems wurde jedoch der Wechsel auf einen kompakten Embedded-PC erforderlich. Dort läuft Home Assistant nun stabil mit seinem eigenen, quelloffenen Betriebssystem (Home Assistant OS). Die Bedienung im Alltag erfolgt üblicherweise mit Gast-Rechten über eine integrierte Weboberfläche. Der Zugriff ist dabei hochflexibel: Er gelingt über jeden Standard-Browser oder die optimierte Home-Assistant-App von beliebigen Rechnern, Tablets und Smartphones aus und natürlich über die fest im Haus an den Wänden montierten Bedientablets.

Für tiefgreifende Eingriffe steht ein Programmierzugang mit erweiterten Admin-Rechten zur Verfügung. Darüber erfolgen die optische Gestaltung der Layouts sowie die komplette Konfiguration und Programmierung des Systems. Bild 2 gibt einen Einblick in einige der erstellten Bedienoberflächen.

Hardware-Architektur und Bedienkonzepte

Doch wie gelangen die Sensordaten, beispielsweise für Temperatur und Feuchte im Raum Büro/Süd (Bild 1), über offene Kommunikationstechnologien in die Home-Assistant-Plattform? In den Raumsensoren vom Typ Shelly H&T Gen3 wird dazu eine WebSocket-Verbindung zu einem passenden Server der Home-Assistant-Installation konfiguriert (Bild 3, oben). Der Raumsensor arbeitet hierbei als Client. Aufseiten von Home Assistant sorgt die installierte Shelly-Integration dafür, dass dieser WebSocket-Server aktiv ist und die ermittelten Sensordaten unter spezifischen Entitätsnamen (Entity) im System verfügbar macht. Im Beispiel etwa unter

(Bild 3, unten).

Eine WebSocket-Verbindung basiert auf einer unterlagerten TCP/IP-Kommunikation und ist im Bereich offener Sensordatenkommunikation sehr verbreitet. Die Nutzdaten selbst überträgt der Sensor einmal pro Minute als Textzeichenfolge in JSON-Codierung (JavaScript Object Notation). JSON ist ein gerade bei Webanwendungen extrem populäres, einfach lesbares Format zur Beschreibung strukturierter Daten. Im vorliegenden Beispiel ist die Übertragung zusätzlich per TLS-Verschlüsselung abgesichert.

Theoretisch ließe sich nun direkt in Home Assistant mithilfe sogenannter Automationen eine Raumtemperaturregelung implementieren. Aus Gründen der Ausfallsicherheit und Echtzeitfähigkeit übernehmen die raum- beziehungsweise bereichsspezifischen Regelungen in diesem Projekt jedoch die dezentral installierten LabJack-Controller. Wie deren Programmierung in der offenen Sprache LUA im Detail erfolgt, wurde bereits im ersten Teil der Artikelserie erläutert.

Automation bei Änderung der Raumtemperatur

In der vorliegenden Home-Assistant-Implementierung wurde stattdessen eine Automation erstellt, die bei jeder Änderung der Raumtemperatur oder beim manuellen Betätigen eines Refresh-Buttons für Wartungszwecke, ein Skript aufruft. Dieses Skript beschreibt über Modbus ein dediziertes Istwert-Register im jeweiligen LabJack-Controller. Bild 4 zeigt diese Automation sowohl im grafischen Editor als auch im hinterlegten Programmcode, der nach dem YAML-Standard verfasst ist. YAML (Yet Another Markup Language) ist eine im Serverbereich weitverbreitete, an XML angelehnte Beschreibungssprache, die universell für Konfigurationszwecke eingesetzt wird.

Ganz rechts in Bild 4 ist zudem eine speziell für das Senden über Modbus erstellte Funktion zu sehen, die unter anderem von diesem Skript aufgerufen wird. Modbus ist ein in der Industrie etabliertes, offenes Protokoll. Ursprünglich für die einfache Prozessdatenübertragung via RS-232- und RS-485-Schnittstellen entwickelt, dominiert heute längst die Übertragung per LAN, bei der Modbus in das Nutzdatenfeld von TCP eingebettet wird (Modbus/TCP). Jeder Kommunikationsvorgang besteht aus einer Client-Anfrage und einer Server-Antwort. In unserem Architekturbeispiel fungiert die Home-Assistant-Installation als Client, während der LabJack-Controller als Server arbeitet.

Eine Lade-Infrastruktur per REST-API integrieren

Die im Haus verbaute Wallbox ist ein Modell vom Typ „go-e Charger Gemini flex“ und stellt eine sogenannte REST-API (Representational State Transfer, Application Programming Interface) bereit. Diese Schnittstelle bietet Server-Funktionen, die per HTTP (oder HTTPS) angesprochen werden. HTTP selbst wird dabei über das unterlagerte TCP/IP übertragen.

Sämtliche Anfragen an die Wallbox erfolgen über die standardisierte HTTP-GET-Methode. Gibt man beispielsweise testweise in einem Browser innerhalb des Heimnetzwerks die URL http://<ip_adr>/api/status ein (wobei <ip_adr> der IP-Adresse der Wallbox entspricht), so antwortet die Wallbox mit einer detaillierten JSON-Textsequenz, die den aktuellen Status beschreibt:

Die Übergabe von Befehlen oder Werten an die Wallbox erfolgt beispielsweise beim Start eines Ladevorgangs durch das Anhängen spezifischer Parameter an die URL der GET-Anfrage (eingeleitet durch ein Fragezeichen „?“). Zwar ließe sich diese Kommunikation mit geringem Aufwand selbst programmieren, doch auch hier nimmt eine vorgefertigte Home-Assistant-Integration dem Anwender die Arbeit ab (Bild 5).

Wie beim Raumsensor werden auch hier die Daten der Wallbox in Home Assistant über Entitäten verfügbar gemacht. Insgesamt lassen sich in der installierten Version 140 Entitäten der Wallbox abrufen. In der Praxis wird aktuell jedoch nur ein Bruchteil davon genutzt. Das ist beispielsweise der Fall, um das Laden dynamisch in Abhängigkeit des aktuellen Gebäudeenergiezustands zu regeln. Dabei fließen Faktoren wie PV-Erzeugung, Batteriespeicher-Ladestand, der aktuelle und prognostizierte Verbrauch sowie aktuelle Wetterdaten in die Automatisierung ein.

Energiemanagement per Modbus und OpenEMS

Im Haus ist zudem eine Photovoltaik-Anlage mit knapp 25 kW_p Leistung inklusive Wechselrichter und Batteriespeicher von Fenecon installiert. Gesteuert wird das gesamte System von einem sogenannten FEMS (Fenecon Energiemanagementsystem). FEMS arbeitet auf Basis von OpenEMS, einem etablierten Open-Source-Projekt für herstellerunabhängiges Energiemanagement. Um einen offenen Datenzugriff zu ermöglichen, ist im FEMS ein Modbus-Server mit umfassend dokumentierten Modbus-Registern integriert.

Im zuvor erläuterten Beispiel wurden Schreibzugriffe auf Modbus-Register noch über den Aufruf eines separaten Skripts realisiert, da das Zahlenformat zwingend umcodiert werden musste. Für das reine Einlesen von Daten ist der Weg hingegen deutlich direkter: Es genügt, die Modbus-Geräte samt ihren Registern in der zentralen Home Assistant-Konfigurationsdatei configuration.yaml zu definieren.

Bild 6 zeigt den Beginn dieser Modbus-Register-Definition in der vorliegenden Home-Assistant-Installation ab Zeile 1191. Zunächst werden dort die Modbus-Register aller acht LabJack-Controller definiert (unter Namen wie T4_1, T4_2 und so weiter). Ab Zeile 1883 folgen dann die Register des FEMS. Über das Feld name wird jeweils der spezifische Entitätsname für den späteren Zugriff in Home Assistant festgelegt. Das Ergebnis in der Praxis: Einige der vom FEMS laufend eingelesenen Energiewerte sind in Bild 2 im rechten unteren Teilbild („Strom“) unter der Rubrik „Aktuelle Werte“ zu sehen.

Vor- und Nachteile offener Standards

Aktuell sind in dem hier beschriebenen Projekt viele weitere Geräte und Komponenten über vergleichbare offene Kommunikationsschnittstellen angebunden. Exemplarisch seien hier noch einige wenige kurz aufgeführt: Das Elektrofahrzeug verfügt trotz vorhandener WLAN-Schnittstelle über keine offene, lokal dokumentierte Anbindung. Stattdessen sendet es kontinuierlich Daten in eine herstellerspezifische Cloud. Für diese Cloud existiert jedoch wiederum eine dokumentierte REST-API, die ganz ähnlich funktioniert wie die Ausführungen zur Wallbox.

Die REST-API der Türstation vom Typ Doorbird wird über HTTP-GET-Abfragen angebunden. Neben einfachen Textzeichensequenzen können hier auch Bilder und Videostreams des in die Türstation integrierten Servers ausgelesen werden. Spezifische Ereignisse an der Türstation, die beispielsweise durch das Drücken der Klingel ausgelöst werden, melden sich hingegen aktiv bei Home Assistant, indem sie spontan per HTTP (oder HTTPS) eine Statusinformation senden (je nach Konfiguration über einen GET-Parameter oder per POST-Methode).

In vergleichbarer Weise wurden auch die Audio- und Videosysteme (hier kommt der Google-Cast-Standard zum Einsatz) sowie die intelligenten WLAN-Steckdosen nach der offenen Tasmota-Spezifikation integriert. Aufgrund der generellen Offenheit dieser Protokolle ließen sich all diese Kommunikationsvorgänge problemlos selbst programmieren. In der Praxis stehen für diese Systeme jedoch auch fertige Home-Assistant-Integrationen zur Verfügung, die den Entwicklern einen Großteil dieser Arbeit abnehmen.

Robust, flexibel und skalierbar

Durch die konsequente und fast ausschließliche Nutzung quelloffener Kommunikationsschnittstellen konnte in diesem Projekt eine nahezu vollständige Unabhängigkeit von herstellerspezifischen, geschlossenen (nicht dokumentierten) Lösungen erreicht werden. Ein entscheidender Vorteil: Mit Ausnahme des Zugriffs auf das Elektrofahrzeug war keinerlei Einbindung von proprietären Hersteller-Clouds notwendig. Die gesamte Hausautomatisierung agiert dadurch äußerst robust, datensicher, flexibel und hochgradig skalierbar. Dies wurde in der inzwischen gut einjährigen, intensiven Testphase im realen Betrieb eindrucksvoll bestätigt.

Prinzipbedingt ist der einmalige Engineering-Aufwand für die Konzeption und Integration eines derart offenen Systems höher als bei einem fertigen, geschlossenen Gesamtsystem von einem der großen Anbieter für Gebäudeautomatisierung. Dieser Mehraufwand wird jedoch in der Regel durch die deutlich günstigeren Komponentenkosten mehr als aufgewogen. Wer die Kriterien Unabhängigkeit, Datensicherheit und Flexibilität hoch gewichtet – insbesondere bei kleineren privaten und gewerblichen Gebäuden –, für den sind offene Systemarchitekturen die mit Abstand zukunftssicherste Lösung. (heh)

Referenzen des Autors

Prof. Dr.-Ing. Jörg Böttcher von der Universität der Bundeswehr in München hat passend zu den Schwerpunkten dieses Beitrags kürzlich mehrere praxisnahe Fachbücher veröffentlicht. Diese sind in der Reihe „Basiswissen für die intelligente Systemautomatisierung“ (Verlag Books on Demand) erschienen.Weitere Details.

* Prof. Dr.-Ing Jörg Böttcher hat eine Professur für Regelungstechnik und Elektrische Messtechnik an der Universität der Bundeswehr München inne.

(ID:50707348)