Daten über einen TCP-Socket verarbeiten

Als Beispiel-Projekt haben wir uns daran gemacht, die heimische Heizungsanlage eines Kollegen mit dem connect-Gateway zu vernetzen. Der Kollege wollte genau wissen, was die Anlage wann tut. Die Lösung, die der Hersteller hier für die Konnektivität anbietet, ist leider sehr dürftig und überhaupt nicht an eigene Zwecke anpassbar.
Disclaimer
Der hier beschriebene Aufbau ist ein Proof-of-Concept im privaten Umfeld und keine von der verlinked GmbH angebotene kommerziell verfügbare Lösung. Das verlinked connect-Gateway ist als kommerzielle Lösung in der Lage die Daten aufzunehmen, aber Heizungsanlagen wie in diesem Beispiel werden nicht Out-of-the-Box unterstützt, sondern erfordern zusätzliche Software-Komponenten. Wenn Sie jedoch Interesse an einer professionellen Umsetzung haben, sprechen Sie uns gerne an!
Inhaltsverzeichnis
Aufbau mit eBUS
Die Heizungsanlage kommuniziert über das so genannte eBUS-Protokoll, das bei Heizungsbauern relativ verbreitet ist. Es ist ein serielles Protokoll, das an RS232 angelehnt ist, aber mit anderen Spannungen arbeitet. Daher kann man den eBUS nicht direkt etwa an einer RS232 Schnittstelle betreiben, sondern benötigt einen Spannungswandler.
Das Protokoll wurde von Tatkräftigen Open-Source Entwicklern aufgeschlüsselt und auch die spezielle Kommunikation vieler Geräte entschlüsselt. Das Projekt ebusd stellt einen Software-Service bereit, der die Kommunikation über eBUS behandelt. Außerdem gibt es bereits Funktionen, um die Geräte am eBUS zu erkennen und deren Daten zu entschlüsseln. Damit ist ein Großteil der Aufgabe eigentlich schon gelöst.
Das connect-Gateway nutzen wir, um die Rohdaten per Kommando vom ebusd abzurufen. Der ebusd bietet hierfür ein einfaches TCP-Protokoll, das wir vom connect-Gateway nutzen können.
Installation
Das connect-Gateway ist auf einem kleinen Industrie-PC installiert. Das System bietet diverse Schnittstellen, auch wenn wir für dieses Projekt nur einen USB-Port benötigen.
Um von eBUS auf USB zu kommen, setzen wir den eBUS-Koppler von esera ein. Es gibt auch die Möglichkeit sich einen eBUS-Koppler selbst herzustellen, aber wir setzen hier auf eine professionelle Lösung für die Hutschiene.
Konfiguration
Die Daten werden vom connect-Gateway über eine TCP-Socket-Verbindung abgefragt. Für unterschiedliche Informationen müssen wir hierzu jeweils andere Kommandos über den TCP-Socket schicken und erhalten die passende Antwort, die wir in einen Datapoint
speichern.
Datapoints
Als Datapoint
erheben wir zum Beispiel die aktuelle Außentemperatur, die die Heizung dazu verwendet, um die Heizkurven entsprechend dynamisch steuern zu können.
<datapoints> <datapoint> <path>/vaillant/aussentemperatur</path> <type>decimal</type> </datapoint> <datapoints>
Endpoint
Die aktuellen Werte erhalten wir über eine TCP-Socket Verbindung indirekt vom ebus. Wir legen einen entsprechenden Endpoint fest.
<endpoint> <name>Heizung_EBUS</name>
Protocol
Nun konfigurieren wir für den Endpoint das TCP_TEXT
Plugin. Über die Parameters
legen wir die IP-Adresse für die Verbindung fest und wie die Inhalte über den Socket übertragen werden.
<protocol plugin="TCP_TEXT"> <name>EBUS</name> <parameters> <param key="ip">192.168.178.53</param> <param key="port">8888</param> <param key="charset">ISO_8859_1</param> <param key="response_delimiter">\n\n</param> </parameters>
Trigger
Wir wollen die Daten vier mal pro Minute erheben. Also legen wir den Trigger
auf 15 Sekunden fest.
<trigger> <cyclicTrigger> <period>15</period> <unit>seconds</unit> </cyclicTrigger> </trigger>
Producer
Den aktuellen Wert für den Datapoint
“aussentemperatur” erhalten wir über folgendes, etwas kryptisches Kommando, das wir auf dem TCP-Socket absetzen.
read -c hmu -n Status01 temp2
Um diesen Befehl abzusetzen, legen wir einen entsprechenden Producer
an, der die Daten für uns erzeugen soll. Der eigentliche Befehl ist dann einfach der Parameter request
. Den Rest erledigt das TCP_TEXT
Plugin.
<producer> <name>aussentemperatur</name> <parameters> <param key="request">read -c hmu -n Status01 temp2\n</param> </parameters>
Decoder und Mapping
Nun legen wir einen Decoder
fest, der aus dem zurückkommenden String eine Decimal
Zahl erzeugt. Im Decoder geben wir über ein Mapping
auch den Datapoint
an, in den der Rückgabewert des Befehls gespeichert werden soll.
<decoder plugin="STRING_DECODER"> <parameters /> <mapping> <datapoint>/vaillant/aussentemperatur</datapoint> <parameters> <param key="charset">ISO_8859_1</param> <param key="parse_number">decimal</param> </parameters> </mapping> </decoder>
Analog verfahren wir mit allen anderen Daten, die wir aus der Heizung so herausbekommen und für uns von Interesse sind. Dazu gehören zum Beispiel der Betriebszustand oder die Temperaturen im Pufferspeicher.
Foto-Strecke
Ergebnis
Durch den Einsatz der ebusd Software waren wir in der Lage an die entsprechenden Informationen zu gelangen, die eine solche Heizungsanlage ansonsten für sich behält. Es zeigt sich auch hier, dass diese Anlagen selbst und deren Software historisch und elektrotechnisch gewachsen sind. Eine saubere Modellierung der Daten sowie ein logisch konsistenter Zugriffsmechanismus fehlen leider.
Hier zeigt sich die extreme Stärke des verlinked connect-Gateways. Wir sind in der Lage mit einer leicht zu beherrschenden Konfigurationsdatei die relevanten Informationen abzufragen und auf eine sauber modellierte Datenstruktur abzubilden. Die Fleißarbeit besteht darin zu ermitteln, wie man an welche Information gelangen kann.
Sind die Daten einmal auf Datenpunkten im connect-Gateway vorhanden, können wir diese in jedes beliebige Format umwandeln und verschicken. Nebenbei könnten wir auch noch Umformungen und Normalisierungen auf den Daten ausführen, aber dazu mehr in einem anderen Post.