Skip to content
Gilles HPK-RA: Eine Pelletheizung in Home Assistant

English

Gilles HPK-RA: Eine Pelletheizung in Home Assistant

Veröffentlicht am 10. Oktober 2026 · Home Assistant · Modbus TCP

Eine Heizung liefert ziemlich interessante Daten. Temperaturen, Sauerstoffwerte, Brennphasen, Lüfterzustände. Auf dem Display der Steuerung ist vieles davon bereits sichtbar. Ich wollte diese Werte auch in Home Assistant haben und nachvollziehen können, was der Kessel über längere Zeit macht. Daraus ist gilles-hpk-ra-modbus entstanden: eine offene Dokumentation der Modbus-Schnittstelle samt Werkzeugen und Home-Assistant-Konfiguration.

Gilles ist ein Heizungshersteller aus Gmunden in Oberösterreich. HPK-RA bezeichnet eine Baureihe automatisch beschickter Biomassekessel. In den Herstellerunterlagen gibt es dafür sowohl Pellet- als auch Hackschnitzelausführungen in unterschiedlichen Leistungsgrößen. Die Anlage, an der dieses Projekt entwickelt wurde, ist eine Pelletheizung. (Pelletkessel-Broschüre, Hackschnitzelkessel-Broschüre)

Bei einer solchen Heizung gelangt der Brennstoff automatisch aus dem Vorrat zum Brenner. Die Pellets werden dosiert zugeführt und entzündet; über den Wärmetauscher geht die entstehende Wärme an das Heizungswasser. Ein Saugzuggebläse hält den nötigen Unterdruck im Kessel. Eine Lambdasonde erfasst den Restsauerstoff im Abgas und liefert damit einen wichtigen Wert für die Verbrennungsregelung. Auch die Reinigung des Wärmetauschers und der Ascheaustrag sind bei dieser Baureihe automatisiert. (Herstellerbroschüre, PDF)

Dahinter steckt ein Ablauf mit mehreren Betriebsphasen. Vor dem eigentlichen Heizbetrieb stehen beispielsweise das Durchlüften des Kessels, die Brennstoffzufuhr und die Zündung. Später regelt die Steuerung die Verbrennung und reduziert bei entsprechendem Wärmebedarf die Leistung. Nach dem Heizbetrieb folgen weitere Zustände wie der Gebläsenachlauf. Wer nur auf die aktuelle Kesseltemperatur schaut, sieht also einen kleinen Ausschnitt dessen, was gerade passiert. Die Gilles-Touch-Anleitung beschreibt diese Abläufe recht ausführlich. (Gilles Touch: Bedienungsanleitung, PDF)

Bedient wird die Anlage über Gilles Touch. Die im Projekt untersuchte Steuerung basiert auf der Sigmatek-HZS-Plattform und verwendet LASAL II. Das ist industrielle Steuerungstechnik. Auf dem Touchscreen erscheinen die Messwerte und Einstellungen, mit denen diese Steuerung arbeitet. Für das Projekt war die Frage, welche davon sich auch über das Netzwerk auslesen lassen.

Dafür gibt es Modbus TCP. Vereinfacht gesagt fragt ein Programm über das Netzwerk nummerierte Speicherstellen der Steuerung ab, die sogenannten Register. Als Antwort kommen Zahlen zurück. Was eine Zahl bedeutet, welche Einheit sie hat und ob sie noch umgerechnet werden muss, steht normalerweise in einer Registerbeschreibung.

Genau diese Beschreibung fehlte für die untersuchte Gilles-Steuerung. Die Schnittstelle antwortete, aber eine passende öffentliche Registermap hatte ich nicht. Dass der Hersteller Modbus in seinen Unterlagen erwähnt, hilft beim Finden des richtigen Protokolls. Für die Bedeutung der einzelnen Werte braucht es deutlich mehr. (Herstellerbroschüre, PDF)

Auch der Umweg über Hargassner führte hier nicht zur fertigen Lösung. Hargassner gab im September 2020 die Übernahme von Gilles bekannt. Die im Projekt verglichene Hargassner-Registermap passte allerdings nicht zur vorhandenen Gilles-Steuerung. Die Unternehmensgeschichte erklärt damit noch nicht die technische Schnittstelle einer älteren Anlage. (Hargassner: Übernahme von Gilles)

In der untersuchten Schnittstelle lassen sich 40 logische Werte auslesen. Technisch besteht jeder davon aus zwei 16-Bit-Registern, die zu einem 32-Bit-Wert zusammengesetzt werden. Diese Unterscheidung ist relevant, wenn man selbst mit Modbus experimentiert: 40 Werte belegen hier 80 Registerwörter.

Die Zuordnung entstand durch Vergleiche. Ein Parameterexport der Steuerung lieferte benannte Einstellungen. Der Touchscreen zeigte aktuelle Temperaturen und Betriebszustände. Daneben liefen die ausgelesenen Modbus-Werte. Stimmen Anzeige und Register wiederholt überein und verändern sie sich gemeinsam, wird aus einer Vermutung langsam eine belastbare Zuordnung.

Bei Temperaturen funktioniert das vergleichsweise gut. Schwieriger sind Zahlen, die einen Betriebszustand oder eine Stellgröße darstellen. Ein Wert kann beim Start des Brenners steigen, weil er die Brennstoffzufuhr beschreibt. Er kann aber auch steigen, weil gleichzeitig ein Lüfter hochläuft. Die zeitliche Nähe allein entscheidet das nicht.

Ein gutes Beispiel ist Register 62. Anfangs sah es nach einem Türsignal aus, weil sich der Wert beim Öffnen der Tür deutlich veränderte. Bei weiteren Beobachtungen passte diese Erklärung nicht mehr: Der Wert nahm auch Zwischenstufen an und folgte dem Saugzug. Beim Öffnen reagierte das Gebläse, und genau diese Reaktion war im Register zu sehen. Die Funktionszuordnung wurde entsprechend korrigiert. Die genaue Skalierung der Lüfterwerte bleibt trotzdem eine eigene, noch offene Frage.

Solche Schritte sind in der Methodik dokumentiert. Dazu gehören auch die Werkzeuge: ein Python-Logger, der Änderungen erfasst und als CSV ablegen kann, sowie ein Snapshot-Werkzeug für eine einzelne Momentaufnahme. Damit lassen sich Beobachtungen später vergleichen, ohne alles vom Display abschreiben zu müssen.

Der erste Git-Commit vom 20. Mai 2026 enthielt bereits die Registermap, die Werkzeuge und eine Home-Assistant-Anbindung. Die ersten Entwicklungsschritte sind zusätzlich im Changelog festgehalten. Kurz darauf kamen berechnete Sensoren und eine umfangreichere Statistikansicht dazu.

Dabei ging die Auswertung zunächst zu weit. Es gab Schätzungen für Pelletverbrauch, Wirkungsgrad und Modulation. Aus vorhandenen Zahlen lässt sich schnell eine weitere Zahl berechnen. Ob diese anschließend einen brauchbaren Messwert darstellt, hängt aber von den Voraussetzungen ab. Für den Pelletverbrauch fehlte beispielsweise eine belastbar kalibrierte Fördermenge.

Am 7. September wurden diese Schätzungen wieder entfernt. Die vorhandenen Signale reichten für die behauptete Aussage nicht aus. Dieser Schritt gehört genauso zur Entwicklung des Projekts wie das Hinzufügen neuer Sensoren. Eine Prozentanzeige für den Wirkungsgrad sieht im Dashboard gut aus, braucht aber eine nachvollziehbare Grundlage.

Im September ging es außerdem um die Zuverlässigkeit der Verbindung. An der Referenzsteuerung wurde eine sehr kurze TCP-Leerlaufgrenze beobachtet: Nach ungefähr drei Sekunden ohne Anfrage konnte die Verbindung beendet werden. Die Konfiguration liest deshalb einen ausgewählten Zustandswert alle zwei Sekunden. Das ist eine Anpassung an das beobachtete Verhalten dieser Steuerung; andere Firmwarestände müssen separat geprüft werden.

Ebenso wichtig war der Umgang mit fehlenden Daten. Wenn Home Assistant die Verbindung verliert, ist der Zustand der Heizung zunächst unbekannt. Die Anzeige muss dann „nicht verfügbar“ melden. Ein ausgefallener Messwert darf keine scheinbar normale Kesseltemperatur erzeugen, und aus einer fehlenden Zustandsmeldung darf nicht versehentlich „Standby“ werden. Dafür wurden Verfügbarkeitsprüfungen ergänzt und die abhängigen Sensoren überarbeitet.

Die längere Beobachtung brachte weitere Korrekturen. Am 24. September wurde unter anderem die bisherige Interpretation von Register 78 als Aschemotorsignal zurückgenommen. Das Verhalten über einen längeren Zeitraum passte nicht zu dieser Zuordnung. Auch ein möglicher Verbrauchszähler erwies sich als nicht monoton: Sein Wert konnte wieder sinken. Damit war die ursprüngliche Erklärung als fortlaufender Gesamtzähler nicht haltbar.

Andere Werte sind weiterhin Kandidaten für bestimmte Funktionen. Für Register 56 gibt es beispielsweise Hinweise auf einen Sauerstoff-Sollwert. Eine plausible Übereinstimmung reicht hier noch nicht für eine endgültige Beschriftung. Besonders wenig beweist ein Vergleich, bei dem sowohl die Anzeige als auch das Register gerade null zeigen. Für eine brauchbare Prüfung braucht es aussagekräftige Werte im normalen Betrieb.

Der jüngste untersuchte Git-Stand vom 25. September 2026 berücksichtigt außerdem neu beobachtete Zustandsnummern. Deren Bedeutung ist teilweise noch ungeklärt. Sie bleiben deshalb entsprechend gekennzeichnet. Die aktuellen Registerbefunde halten fest, was beobachtet wurde und welche Erklärung bisher dazu passt.

In Home Assistant lassen sich heute unter anderem Kessel-, Abgas- und Rücklauftemperatur, Restsauerstoff sowie bekannte Betriebsphasen darstellen. Dazu kommen Auswertungen beobachteter Starts und Zykluszeiten. Im Verlauf wird dadurch sichtbar, wie Temperatur und Betriebszustand zusammenhängen und wie sich ein Heizzyklus entwickelt.

Auch diese Statistiken haben Grenzen. Ein Start kann nur gezählt werden, wenn der entsprechende Übergang tatsächlich beobachtet wurde. Während einer Datenlücke können Ereignisse verloren gehen. Eine erfasste Zyklusdauer kann Vor- und Nachlauf enthalten und ist deshalb kein direkter Nachweis dafür, wie lange eine Flamme vorhanden war. Die rollierende Startstatistik für die letzten 24 Stunden hat außerdem noch eine dokumentierte Einschränkung und sollte derzeit nicht als verlässlicher Zähler verwendet werden.

Die Integration arbeitet ausschließlich lesend. Sie verändert keine Kesselparameter. Die eigentliche Regelung bleibt bei der Gilles-Steuerung; Home Assistant übernimmt die Anzeige und Auswertung der zugänglichen Daten.

Das Projekt ist weiterhin offen. In der untersuchten Registermap sind beispielsweise noch keine belastbaren Zuordnungen für sämtliche Puffer- und Warmwassertemperaturen oder einen tatsächlichen Pelletverbrauch vorhanden. Auch unbekannte Zustände und die Skalierung einzelner Stellgrößen brauchen weitere Vergleiche. Die bisherigen Ergebnisse stammen von einer konkreten Referenzanlage und sind keine Zusage, dass jede Gilles-Steuerung dieselben Werte liefert.

Der Code und die Dokumentation stehen unter der MIT-Lizenz auf GitHub, mit deutschen und englischen Beschreibungen. Wer eine ähnliche Anlage hat, findet dort die Registermap und die Anleitung für Home Assistant. Besonders hilfreich sind nachvollziehbare Vergleiche zwischen Touch-Anzeige und Registerwerten. Damit kann die nächste Zuordnung genauer werden – oder eine bisherige Erklärung wieder von der Liste verschwinden.