Architektur der Heizungssteuerung

Heute möchten wir die Architektur unserer Heizungssteuerung genauer vorstellen.

Kommunikation

Die primäre Kommunikation zwischen Sensor, Aktoren und „Compute-Node“ erfolgt grundsätzlich mit MQTT. Die Sensoren übermitteln die aktuelle Temperatur und Luftfeuchtigkeit, der Aktor öffnet oder schließt auf Befehl das Thermostat. Die aktuelle Stellung meldet er ebenfalls an die Compute Node zurück. Die Sensoren bzw. die Raspberrys sind mit unserem Projekt in der Balena Cloud verknüpft. Der Raspberry wird mit einem Docker Container bespielt. Die gemessenen Sensordaten werden an den MQTT geleitet.

Daten und Datenhaltung

Entgegen der ursprünglichen Planung wird für das Speichern der Daten über die Rauminformationen (Name, Rapla-Link, Soll-Temperatur) aus dem Frontend keine MongoDB verwendet. Das liegt daran, dass die Beziehung zwischen den Daten primär von relationaler Art ist, sodass sich eine relationale Datenbank für diesen Verwendungszweck besser implementieren lässt, als eine nicht rationale Datenbank. Daher wird hier eine MariaDB implementiert werden. Das ist für den kommenden Sprint geplant. Die MariaDB wird in einem Docker Container deployed.
Ferner werden die Werte, die ein Sensor ausließt, in einer InfluxDB gespeichert. Diese InfluxDB ist aufgrund ihrer Funktion als Zeitreihendatenbank dafür hervorragend geeignet ist, da sie die Zeitreihen logisch sinnvoll, ressourcensparend und effizient speichert. Zudem kann Influx die gesammelten Daten sogar visuell darstellen, ohne für das Aggregieren der Daten übermäßig Ressourcen zu benötigen. Die Sensoren senden die gemessenen Daten an den MQTT, von wo aus sie die InfluxDB erhält.

Compute-Node

Die „Compute-Node“ ist das Herzstück der Anwendung, da diese die komplette Programmlogik und das Frontend enthält. Als Framework wird hier das Tool Node-RED genutzt.

Kommunikation innerhalb und mit der Compute-Node

Die Daten bekommt die Node einerseits durch den MQTT und andererseits durch Nutzereingaben. Ein Heizbefehl kann entweder durch eine Abweichung zwischen Soll- und Ist-Temperatur erfolgen, durch ein Kalenderereignis (Raumbuchung in Rapla) oder durch eine manuelle Aufforderung durch das Frontend.

User-Access Control

Da das Implementieren der Node nicht auf Balena geklappt hat, wurde sie unabhängig davon auf einen Raspberry implementiert. Dieser nutzt das Betriebssystem Raspbian. Da nur eine Compute-Node vorliegt und diese bei einem Projektteilnehmer im Netzwerk ist, gibt es ein Vorgehen, um von außerhalb dieses Netzwerks auf die Compute-Node zuzugreifen. Dafür wird eine SSH Verbindung genutzt. Weiterhin kann die Webview über Zertifikate erreicht werden.

Als Maßnahme für IT-Sicherheit wurde die Compute-Node durch eine Netzwerk- und Clientfirewall abgesichert. Auf user-level wurde für die SSH-Verbindung auf ein Public-Key-Verfahren gesetzt und für den HTTPS-Zugriff ein SSL-Client-Zerfitikat für die Nutzenden ausgestellt. Ohne dieses Zertifikat oder SSH-Key kann nicht auf die Compute-Node zugegriffen werden.

Node-RED

Node-Red ist ein von IBM entwickeltes grafisches Entwicklungstool. Damit ist es möglich, Abläufe nach dem Baukastenprinzip zu erstellen. Dieses Tool ist der Dreh und Angelpunkt der Applikation. Aufgabe von Node-RED ist das Abrufen bzw. Senden von MQTT-Nachrichten und Speicherung der Sensorwerte in der Influx-DB. Zusätzlich besitzt Node-RED eine Schnittstelle zu der Konfigurationsdatenbank (MariaDB), die die Rauminformationen erhält. Eine ICAL-Implementation ermöglicht das Abrufen der Kalenderereignisse von Rapla und ein Frontendmodul ermöglicht das Einstellen der Raumtemperaturen an einem zentralen Punkt. Hauptaufgabe von Node-RED ist jedoch die Implementierung und Realisierung des Heiz-Regelkreises, welcher die Temperaturen der Räume entsprechend der definierten Regeln anpasst.