Heating Control III


Projektbericht Heizungssteuerung

Published on December 22, 2019 by Jörn Karthaus

rpi projekt heizung automatisierung

6 min READ

Versionshistorie

Heating Control 1

Das Projekt Heating Control begann vor 4 Jahren. Aus der Not heraus geboren, mußte die Steuerung einer Heizung die vorher komplett manuell bedient wurde, automatisiert werden.
Die Aufgabe erscheint erst einmal einfach bei genauerem Hinsehen aber keinegswegs trivial. So galt es mehrere Systeme in Einklang zu bringen.

  • Ein Sonnenkollektor Kreislauf, mit 2 Pufferspeichern.
  • Eine Gastherme als primäre Energiequelle.
  • Eine Feststoff Brennkessel für Holz mit einem angeschlossenen 1000 Liter Speicher.

Heating Control 2

Heating Control 1 lief schon 2 Jahre mehr oder weniger stabil.
Aus den Nachteilen die hauptsächlich aus der monolitischen Architektur von Heating Control enstanden sind.
Habe ich Versuche unternommen Heating Control mit einer Microservice Architektur neu aufzusetzen.
Als Framework hierzu habe ich auf Apache Karaf gesetzt.
Es folgen viele Stunden Entwicklung mit Karaf die immer zwischen Begeisterung für die OSGI Plattfrom und entsetzen lagen. Irgendwann war es Zeit einen Schlussstrich zu ziehen, und die OSGI Plattform aufzugeben.
Also gab es die Entscheidung für Heating Control 3, ohne die Version 2 komplett produktiv einzusetzen. Geblieben von Version 2 sind Fragmente, die parralell zu Version 1 aktiv sind. Diese Situation trägt nicht zu einem gut Wartbaren Produkt bei, also alle Energie in die Entwicklung für Version 3

Heating Control 3

Heating Control 3 wird seit Anfang 2019 von mir als Ersatz für die noch immer produktiv laufende Version 1 entwickelt. Die Version2 wird ebenfalls ersetzt, diese Version ist ohnehin nur in Fragmenten aktiv.

Damit Heating Control 3 unabhängig von Version 1 entwickelt und getestet werden kann, habe ich mich dazu entschlossen, die gesamte Heizungssteuerung zu splitten.

  1. Steuerung der Gas und Solarfunktionen mit der etablierten Version 1
  2. Entwicklung und Steuerung des Feststoffbrennkessels mit Version 3

Hier der useCase für die Entwicklung von HC3. Ein Feststoffkessel heizt über einen Wärmetauscher einen Wasserspeicher auf. Weitere Wärmetauscher geben 1. Wärme in den Hauskreislauf (HC1) und 2. in das Gebäude in dem sich die Heizung selbst befindet (Garage).

  1. Pumpe für den Kesselkreislauf
  2. Pumpe für den Heizkreislauf der Garage
  3. Temperaturfühler im Wasserspeicher
  4. Temperaturfühler im Feststoffbrenner
  5. Temperaturfühler Innenraum Garage
  6. Temperaturfühler Außen

Sobald die Festhofbrennkessel Version stabil ihren Dienst tut wird Heating Control 1 ersetzt.

Fotodokumentation HC3

Was ist neu an HC3

Heating Control 3 setzt nicht mehr auf ein monolithisches Programm, sonden auf eine Microservice Architektur.
Aufgrund der Erfahrungen mit OSGI habe ich bewusst auf eine globale Plattform verzichtet, sondern HC3 aus verschiedenen Technologieen zusammengesetzt.

Bausteine von HC3

  • Als Separierungstechnologie zwischen den Teilen von HC3 kommt (natürlich) Docker zum Einsatz.
  • Der Message Bus der zur kommunikation zwischen den Microservices benutzt wird ist RabbitMQ
  • Die Systemnahen Microservices wie beispielsweise das auslesen der Temperatursensoren wird Python verwendet.
  • Die eigentliche Kern-Geschäftslogik ist wieder in Java implementiert. Aufgrund der geringen RAM Anforderungen habe ich mich hierfür für das Micronaut Frameworketschieden.
    hc3-core auf Github
  • Die Microservices zum speichern und auswerten der Sensordaten sind.
    1. Influx-DB zum Speichern der Informationen
    2. Chronograf für die Darstellung und Auswertung
  • Der Proxy - Caddy
  • Als Ablaufplattform kommt natürlich der Raspberry Pi zum Einsatz.

Blockschaltbild von HC3

In grün dargestellt sind die Docker Container.
Die Container kommunizieren untereinander über das amqp Protokoll im Docker Netzwerk blau der Broker ist der hc-amqp Container (RabbitMq). Nach außen sind mehrere Ports gelb freigegeben, über die per REST zugegriffen werden kann.

Browser-UI

Das Heating-Control-UI wird über den Proxy (hc-proxy) nach außen freigegeben.
Es handelt sich hierbei um eine SPA die mit Angular entwickelt wurde.

Datenbrowser Chronograf

Über den link Hc3-Dashboard wird man vom hc3-proxy zum Datenanalyse Tool Chronograf geleitet.
Hier können alle gesammelten Sensordaten die in dem Microservice hc3-influxdb gespeichert werden, zeitlich visualisiert werden.

Hier zusammengefasst, die Heizsaison von Oktober 2023 bis März 2023.
Jede Spitze zeigt den Temperaturverlauf eines Heizzyklus.
Die blaue Linie zeigt den Temperaturverlauf des Pufferspeichers.
Die orange Linie den Temperaturverlauf im Holzkessel.

Deployment Prozess

hc3-deployment auf Github

Das deployment wurde komplett über Ansible umgesetzt.
Das Ansible Deployment Script setzt alle einstellungen, um auf einem komplett leeren Rasbian eine funtkionsfähige HC3 Instanz zu installieren.
Das HC3 deployment durchläuft dabei 3 Ansible Rollen (Plays).

  1. kernelConfig
    Diese Rolle setzt alle Einstellungen im Rasbian Hostsystem um I2C, und OneWire devices zu benutzen.
    Die Notwendigen Kernel Module für die Nutzung der ds18b20 Sensoren werden ebenfalls eingeschaltet.
  2. remoteShutdown Um das System per ssh herunterzufahren werden in diesem Script einstellungen gesetzt, damit der Benutzer Pi das host-system per Kommando poweroff herunterfahren darf.
  3. greeting Der greeting task setzt für den Benutzer Pi eine Willkommensnachricht.
    Diese Grafik wird sichtbar, nachdem der Benutzer sich per ssh einloggt.
  4. docker Der docker Task installiert alle benötigten Docker Packet.
    Das docker-compose Tool ist bestandteil, da es zum Starten von HC3 genutzt wird.
  5. heatingControl
    Dieser Task ist der Haupttask, der die eigentliche Applikation installiert oder aktualisiert. Die einzelnen Microservices liegen auf Dockerhub das Ansible Script kopiert nur eine DockerCompose Datei und ein RabbitMQ konfigurationsscript nach /opt/heatingControl und führt danach dockerCompose aus.
  6. heatingControlWebGui Hier wird die Angular-SPA in einen static bereich des hc3-core kopiert.
    Der Webserver in hc3-core liefert die SPA an den Klienten aus.

Ab jetzt übernimmt Docker alle Aufgaben, und lädt als Erstes alle neuen oder aktualisierten Images aus der Docker Registry herunter. Dann wird RabbitMQ gestartet, und per Ansible RabbitMQ automatisch konfiguriert. Als letzter Schritt werden die anderen Docker Container erstellt und gestartet.

Datenanalyse deployment

  1. heatingControl Datalake
    In dieser Rolle sind alle Tasks zur Datenanalyse zusammengefasst.
    Weil die Datenanalyse kein zwingender Bestandteil von hc3 ist, wurde hierzu ein eigenes Ansible deployment gebaut.
    Die Ausführung erfolgt über das Script install_hc3Datalake.sh

Hardware

Folgende Hardware wurde verbaut

  1. Raspberry Pi
    Die Variante ist eigentlich egal. Ich hatte noch einen RASPI3 in der Schublage liegen, daher wurde dieser verbaut.
  2. Relais Board RPI Relais HAT Hier lauerte ein Stolperstein, da ein Relais GPIO4 beleg, der auch vom 1Wire Anschluss der Temperatursensoren genutzt wird. Da ich nur 2 Relais benötige, konnte GPIO4 durch Entfernen einer Brücke auf dem Relais Board einfach freigegeben werden.
  3. LCD Display 20x4
    Display bei Amazon Das Display ist an den i2c Ports des Raspberry angeschlossen. Daher werden weniger GPIO Pins verbraucht.
    Das Display ist Relativ groß, und kann daher locker über 3 Meter entfernung abgelesen werden. Um das Display betreiben zu können ist noch ein Pegelwandler erforderlich. Pegelwandler
    Ich habe mich an folgende Anleitung gehalten LCD Display per I2C ansteuern
  4. Temperatursensoren DS18B20
    Folgende Sensoren sind für sehr wenig Geld zu haben, und verrichten ihren Dienst zuverlässig: DS18B20 Set wasserdicht Der Anschluss der Sensoren wurde nach folgendem Tutorial durchgeführt:
    DS18b20 an RPI anschliessen

Entwicklungsprozess

Ein Bild sagt mehr als tausend Worte …

Fotodokumentation…