Projekt 23 Smarthome / Zugriff Heizung

Aus c3RE.de
Wechseln zu: Navigation, Suche

Diese Seite gehört zum Kontext Projekt 23 Smarthome und beschreibt die Umsetzung beim Zugriff auf die Daten der Heizungsanlage Stiebel Eltron WPF 10.

Es handelt sich um eine Sole/Wasser-Wärmepumpe mit angeschlossenem Warmwasser-Speicher 'SBB 300 basic' des selben Herstellers, welche an einer Tiefenbohrung angeschlossen ist (Geothermie). Diese Komponente als größter Energieverbraucher und Wärmelieferant bietet ein interessantes Ziel für eine Smarthome-Anbindung. In der Standard-Installation bietet dieses System keine Schnittstelle für eine Netzwerk-Anbindung. Leistungswerte können nur am Display abgelesen werden, was aus statistischen Zwecken bis zu einer smarteren Lösung auch jeden Morgen gemacht wird.

Primäres Ziel ist hier die kontinuierliche Erfassung bestimmter Daten, um daraus qualifizierte Rückschlüsse ziehen zu können. Ein aktiver Eingriff in die Steuerung ist derzeit nur ein nachrangiges Ziel.

Grundsätzlich scheint die Möglichkeit für einen Zugriff auf die Anlage gegeben zu sein, denn der Hersteller bietet scheinbar fertige Lösungen an:

  • Internet Service Gateway (ISG)
  • ISG web
  • KNX IP-Schnittstelle

Kriterien wie Zwang zum Wartungsvertrag, Kosten, Sorge um Security und Privatsphäre, Cloudzwang und mangelnder Spaß lassen diese Optionen auf den ersten Blick unattraktiv erscheinen. Zumal zumindest bei einem Teil der Lösungen noch unklar ist, wie der Zugriff auf die eigentlichen Daten (Export) umgesetzt werden könnte.

Firmware

Am Display werden die folgenden Versionsbezeichungen der Firmware angezeigt:

# Busteilnehmer Software
01 WPM3I 391-03
02 FES 400-00
03 MFG 11

Bus-System: CAN

Die Heizung verwendet den CAN-Bus, um Daten zu transportieren. Wahrscheinlich wird auch das eingebaute Display auf diesem Wege angebunden.

Im Handbuch werden im Abschnitt '18.3 Elektroschaltplan' diese potentiell relevanten Komponenten erwähnt:

  • X2: Anschlussklemmen extern Kleinspannung
  • X30/X31: CAN-Bus Anschluss Netzteil

Eine Recherche im Internet zeigt, dass scheinbar schon mehrere andere Hackversuche auf dem Weg über den CAN-Bus erfolgreich waren und auch gut dokumentiert worden sind (s. #Links).

CAN-Bus-Adapter

Für den Zugriff auf den CAN-Bus ist eine zusätzliche Hardware notwendig, welche die Schnittstelle zwischen dem verarbeitenden System (SmartHome-Server) und dem Datenlieferanten (Heizung) bietet. Da im Projektkontext der SmartHome-Server auf einer PC-Engines APU abgebildet ist, welche in unmittelbarer Nähe zu der Heizung steht, erscheint hier ein Controller mit USB-Anschluss sinnvoll. An anderen Stellen wird mit Controllern gearbeitet, die auf einen Raspberry Pi aufgesetzt werden, aber das scheint im vorliegenden Fall unnötig komplex.

Verwendete Hardware:

Beim Anschluss am System meldet journald:

Mär 03 19:07:35 j2 kernel: usb 7-1: new full-speed USB device number 2 using uhci_hcd
Mär 03 19:07:35 j2 kernel: usb 7-1: New USB device found, idVendor=04d8, idProduct=000a
Mär 03 19:07:35 j2 kernel: usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Mär 03 19:07:35 j2 kernel: usb 7-1: Product: USBtin
Mär 03 19:07:35 j2 kernel: usb 7-1: Manufacturer: Microchip Technology, Inc.
Mär 03 19:07:35 j2 kernel: usb 7-1: SerialNumber: <xxx>
Mär 03 19:07:35 j2 mtp-probe[9970]: checking bus 7, device 2: "/sys/devices/pci0000:00/0000:00:1d.1/usb7/7-1"
Mär 03 19:07:35 j2 local mtp-probe[9970]: bus: 7, device: 2 was not an MTP device
Mär 03 19:07:35 j2 kernel: cdc_acm 7-1:1.0: ttyACM0: USB ACM device
Mär 03 19:07:35 j2 kernel: usbcore: registered new interface driver cdc_acm
Mär 03 19:07:35 j2 kernel: cdc_acm: USB Abstract Control Model driver for USB modems and ISDN adapters

Ein Probelauf der vom Hersteller zur Verfügung gestellten Java-Application ohne Anschluss an den CAN-Bus der Heizung bringt zumindest schon mal ein einzelnes Event zur Anzeige:

Connected to USBtin (FW0107/HW0100, SN: 8CFE)

Parameter:

  • Port: /dev/ttyACM0
  • Baud-Rate: 115200

Aufruf:

[root@j3 ~]# java -jar USBtinViewer_v1.3.jar
No preset for given baudrate 115200. Set baudrate to 115384

Anschluss

Physischer Anschluss Adapter 'USBtin' an Block 'X2'

Für den physischen Anschluss des Adapters an die Heizung wurden relativ starre Drähte an den Kontaktstellen des Adapters angelötet. Diese Drähte haben eine Länge von ca. 20cm und wurden in die Klemme der Heizung (Block 'X2') eingesteckt.

Durch die Steifheit der Kabel wird der Adapter schwebend ohne Bodenkontakt im Innenraum der Heizung gehalten. Dort ist die Konstruktion vor mechanischer Beanspruchung geschützt.

Ein Abschlusswiderstand von 120 Ohm zur Terminierung des Busses wird derzeit nicht eingesetzt.

Der USB-Anschluss erfolgt über ein 5m langes Kabel, welches hinten aus der Heizung herausgeführt wird.

Funktionstest

Ein erster Testlauf mit USBtinViewer

Für einen ersten Funktionstest wurde das vom Hersteller zur Verfügung gestellte Programm USBtinViewer (v1.3) auf einem Notebook unter CentOS verwendet. Es handelt sich um ein Java-Programm, welches ein GUI bietet. Der Start erfolgt in diesem Fall zur Vereinfachung unter dem User root.

Als Verbindungsparameter wurde eingestellt:

  • Port: /dev/ttyACM0
  • Baud-Rate: 20000

Bei Auswahl von Connect treffen quasi unmittelbar Daten vom CAN-Bus ein. Die LED am Controller leuchtet kontinuierlich rot.

Nun gilt es herauszufinden, was diese Daten bedeuten und wie sie genutzt werden können.

Hinweis: Der beschriebene Funktionstest kann per X11Forwarding auch remote gestartet werden, wenn der Adapter per USB am SmartHome-Server angeschlossen ist. Damit entfällt die Notwendigkeit, für die Evaluierungszeit mit einem Notebook im Heizungskeller zu hocken.

Hierfür ist eine Installation notwendig:

# yum install xauth

Aufruf:

$ ssh -X j8-admin
Last login: Mon Mar 27 15:28:58 2017 from 172.16.17.10
/usr/bin/xauth:  file /home/<user>/.Xauthority does not exist

$ su -

# java -jar USBtinViewer_v1.3.jar

Zieldefinition

Die folgenden Daten scheinen im Projektkontext relevant zu sein und sollten erfasst werden:

  • Außentemperatur (stündlich)
  • Vorlauf Ist-Temperatur (alle 5 Minuten)
  • Rücklauf Ist-Temperatur (alle 5 Minuten)
  • Warmwasser Ist-Temperatur (alle 5 Minuten)
  • Warmwasser Soll-Temperatur (alle 5 Minuten)
  • Speicher Ist-Temperatur (alle 5 Minuten)
  • Quellen-Temperatur (stündlich)
  • Elektrische Leistung Verdichter Heizen Tag (alle 5 Minuten)
  • Elektrische Leistung Verdichter Heizen Summe (täglich)
  • Elektrische Leistung Verdichter Warmwasser Tag (alle 5 Minuten)
  • Elektrische Leistung Verdichter Warmwasser Summe (täglich)
  • Volumenstrom (alle 5 Minuten)
  • Gewählte Heizkurve (täglich)

Für die Wahl der Zyklen ist insbesondere auch das Fassungsvermögen und die Performance bei der Analyse zu berücksichtigen (s. #Datenbank).

Hinweis: In der ersten Phase des Projektes soll es primär um die Erfassung und statistische Auswertung von Betriebsdaten gehen. Es erscheint ebenfalls sinnvoll, andere Werte wie beispielsweise Fehlerwerte für eine Systemüberwachung abzufragen, dies dann aber für andere Zwecke wie beispielsweise einem Monitoring mit entsprechender Notifikation des Betreibers. Solche Aufgaben werden erst in späteren Phasen umgesetzt.

Auswertung der Daten

Die empfangenen Daten können wie folgt ausgewertet werden (Beispiel):

ID DLC Data Bedeutung Wert (dez.) Wert (hex.) Faktor Einheit Bemerkung
180h 7 22 00 08 01 c4 00 00 Warmwasser Ist-Temperatur 45,2 452 1c4 0,1 °C
180h 7 22 00 02 00 78 00 00 Außentemperatur 12,0 120 78 0,1 °C
100h 7 31 00 16 00 00 00 00 Rücklauf Ist-Temperatur 16: Elster-Index: RUECKLAUFISTTEMP - Request
180h 7 22 00 16 01 04 00 00 Rücklauf Ist-Temperatur 26,0 260 104 0,1 °C 16: Elster-Index: RUECKLAUFISTTEMP - Response
180h 7 22 00 fa 09 1a 00 ea Elektrische Leistung Verdichter Warmwasser Tag 0,234 234 ea 1 Wh fa: Erweiterungstelegramm
09 1a: Elster-Index EL_AUFNAHMELEISTUNG_WW_TAG_WH
180h 7 22 00 fa 09 1c 01 f0 Elektrische Leistung Verdichter Warmwasser Summe 1,496 MWh (zusammengesetzt) 496 1f0 1 kWh fa: Erweiterungstelegramm
09 1c: Elster-Index EL_AUFNAHMELEISTUNG_WW_SUM_KWH
180h 7 22 00 fa 09 1d 00 01 1 1 1 MWh fa: Erweiterungstelegramm
09 1d: Elster-Index EL_AUFNAHMELEISTUNG_WW_SUM_MWH
601h 7 66 01 fe 01 00 00 00  ?  ?  ?  ?  ? fe 01: Elster-Index: ENDE_CHAR_BEREICH ?

Bedeutung:

  • ID: Bislang wurden die folgenden IDs beobachtet (Zuordnung teilweise laut 'robots' / haustechnikdialog):
    • 100 (1163): ? Sendet ausschliesslich Requests (Typ '1')
    • 180 (1094): Kessel? Sendet ausschliesslich Responses (Typ '2') als Antwort auf Requests von 100h
    • 480 (6888): Manager? Sendet ausschliesslich Requests (Typ '1') oder Typ '0')
    • 601 (8): ?
    • 700 (5762): Fremdgerät? Sendet ausschliesslich Responses (Typ '2') als Antwort auf Requests von 480h
Die Zahlen in Klammern bedeuten die Anzahl der Telegramme (im Zeitraum 1 Stunde zur quantitativen Einordnung)
  • DLC (Data Length Code): Längeninformation zum nachfolgenden Datenfeld. Bislang wurde ausschließlich Felder mit einer Länge von 7 Bytes gesichtet.
  • Data: Daten des Telegramms
    • 2. Digit:
      • 0= ?
      • 1= Request (Anfrage)
      • 2= Response (Antwort)
      • 6= ?

<ToDo: noch ganz am Anfang...>

Architektur

Unterschiedliche Möglichkeiten für eine Anwendungs-Architektur:

  • Standalone-Programm: Einmalige Abfrage von Werten. Externe Zeitsteuerung und Aufruf via cron, systemd, collectd, telegraf... Leichtere Implementierung, höhere Wahrscheinlichkeit für Wiederverwendung in anderem Kontext (geringere Hürde). Weiterverarbeitung via JSON-Export flexibel möglich, beispielsweise für Monitoring oder Visualisierung.
  • Server: Als Daemon laufender Prozess mit eigenem Scheduling für die Abfrage der Daten oder lückenloser Verarbeitung ohne Zeitsteuerung und aktive Anfragen (in diesem Fall würde es beispielsweise einer TSDB obliegen, die Datenerfassung und Datenhaltung nicht ausufern zu lassen). Möglicherweise Einbettung in die Funktionalität von openHAB, dann kann auch dynamisches Regelwerk und EventHandling verwendet werden. Komplexer zu implementieren, potentiell höherer Nutzen für openHAB-Betreiber, aber weniger flexibel. Kompensation der erhöhten Workload besonders bei der Verwendung von Java.

Protokollierung in #Datenbank müssen alle Varianten implementieren.

Entscheidung: <ToDo>

Datenbank

Aufgrund der Menge der anfallenden Daten und der Schwierigkeit, diese vorweg sinnvoll einzugrenzen, bestehen Zweifel, ob für diese Aufgabe die Verwendung eines RDBMS (wie beispielsweise mySQL) die richtige Wahl ist. Alternativ bieten sich sogenannte time-series databases (wie z.B. InfluxDB) an.

Insbesondere das Thema 'Visualisierung' ist schon zu Anfang des Projektes gerade bei der Auswahl der Datenbank zu betrachten, auch wenn es erst später umgesetzt werden sollte. Hier ist zu berücksichtigen, welche Möglichkeiten die Datenbank hinsichtlich performanter Abfragetechniken bietet.

Ebenso ist die Frage der dynamischen Datenhaltung relevant. Hierbei ist beispielsweise das Konzept von InfluxDB Downsampling and Data Retention interessant, wonach Datenbestände mit zunehmenden Alter zu Gruppen konsolidiert (und dadurch weniger voluminös gespeichert) werden und abgestufte Regelungen für die Haltbarkeit von Daten möglich sind. Ziel soll es sein, aktuelle Daten für Analysezwecke möglichst hoch-aufgelöst und detailliert vorzuhalten, ältere dagegen mit groberem Raster oder gar nicht mehr zu speichern.

<ToDo>

Status

  • Einarbeitung in CAN-Bus und Datenformat
  • Evaluierung von Protokoll- und Auswertungsmöglichkeiten
  • Gedanken zur Architektur

<ToDo>

Links