Jörn - Karthaus.de
willkommen auf meiner Website

Heating Control III


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.

Hier weitere Informationen zur Umsetzung von Heating Control 1

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 Entwickllung mit Karaf die immer zwischen Begeisterung für die OSGI Plattfrom und
entsetzen lagen.
Irgendwann war es Zeit einen Schlußstrich 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 monolitisches 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 freigegebn.
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 orangene 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 Sesnoren werden ebenfalls eingeschaltet.
  2. remoteShutdown
    Um das System per ssh herunzufahren werden in diesem Script einstellungen gesetzt, damit der Benutzer Pi
    das hostsystem 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 Packete.
    Das docker-compose Tool ist bestandteil, da es zum starten von HC3 genutzt wird.
  5. heatingControl
    Dieser Task ist der Haupttask, der die eigendliche 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 neueen oder aktualisierteb 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. heatingControlDatalake
    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 eigendlich 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 Temperatursonsoren
    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...