Raspberry Pi als Modbus-Server – ein Universalübersetzer für die UVR16x2

Seit Irgendwessen heroischem Umbau des Heizraums sind sie glücklich auf diesem hochprofessionellen Schaltbrett vereint – die diversen Geräte am CAN-Bus und der Raspberry Pi:

Dieser Anblick hat die Datenkrake inspiriert! Im Gegensatz zur fleißigen UVR16x2 langweilte sich der Raspberry Pi – alle paar Minuten die Daten der Wärmepumpe von deren CAN-Bus loggen war nicht Herausforderung genug.

Es war Zeit, einige langjährige Vision umzusetzen:

Wärmepumpen-Daten auch in der UVR. Hin und wieder wurden die Siedler gefragt, warum sie die Daten der Stiebel-Eltron WPF7 basic nicht einfach direkt in die UVR loggen -‚Ist ja alles CAN-Bus!‘. Nicht ganz: Wie andere Netzwerkprotokolle gibt es auch hier verschiedene Schichten und auf der obersten (Applikations-)Ebene spricht die UVR canopen  und die Wärmepumpe eine proprietäre Variante.

Außerdem sind selbst die Siedler als furchtlose Tüftler etwas vorsichtig damit, den internen CAN-Bus der Wärmepumpe zu verbinden mit dem anderen CAN-Bus auf dem mittlerweile ja Einiges los ist. Man macht ja so seine Erfahrungen mit Geräten, die sich durch theoretisch harmlose Netzwerkpakete anderer gestört fühlen.

Aber was wäre, denn der Raspberry Pi die über den CAN-Bus geloggten Daten selbst wieder ‚auflegen‘ könnte – über ein Protokoll, dass die UVR versteht?

Der Klassiker – Photovoltaik und Eigenverbrauch: Die Datenkrake ermittelt schon lange Kenndaten wie z.B. den PV-Direktverbrauch oder den Haushaltsstrom ohne Wärmepumpe – das war aber bis jetzt nur auf Tagesbasis möglich, da die diversen Logger unterschiedliche Logging-Zeitpunkte und -Intervalle verwenden. Die bisher gezeigten Tagesgänge waren einfach übereinander gelegte Kurven mit unterschiedlichen Zeitwerten.

Es wäre also schön aus aktuellen Daten von Wechselrichter, Zähler und UVR16x2 eigene Werte berechnen zu könne – im Minuteninterval.

Der Fronius-Symo-Wechselrichter unterstützt Modbus – die Siedler loggen die aktuelle PV-Leistung über diesen Weg ‚in das CMI‘ bzw. die UVR. Der Zähler der Siedler hat aber ’nur‘ eine Weboberfläche und bietet die Daten in strukturierter Form über JSON an. Das CMI unterstützt zwar JSON, aber nur ‚in die andere Richtung‘: Man kann Daten der neueren Geräte von Technische Alternative über JSON vom CMI abfragen.

Was wäre, wenn der Raspberry Pi die JSON-Daten so aufbereiten könnte, dass das CMI sie lesen kann?

Kommunikation auch in die andere Richtung. Für manche Berechnungen braucht der Raspberry Pi auch Input von der UVR – d.h. die UVR16x2 muss z.B. die aktuelle Kompressorenergie an den Pi ’senden‘. JSON am CMI ist dafür nur bedingt geeignet, da Daten nur maximal 1x pro Minute abgerufen werden dürften.

Leider ist die hier mühsam aufgebaute Spannung schon verpufft – im Titel steht schon die Lösung:

Der Rasperry Pi arbeitet als Modbus Server (bzw. ‚Slave‘)! Daten werden von anderen Loggern über deren Protokolle geholt, z.B,. über JSON vom Smart Meter oder über Modbus vom Wechselrichter. Diese Daten werden vom Pi auf eigenen Modbus-Registern zur Verfügung gestellt. Zusätzlich werden Werte berechnet – wie der PV-Direktverbrauch – und ebenfalls ’serviert‘.

Das CMI arbeitet als Client (bzw. ‚Master‘) und holt die Daten vom Rasperry Pi ab. Für das Datenlogging in das CMI-Logfile und die eventuelle Nutzung als Signal für Aktionen der UVR ist wieder das Fenster-raus-Türe-rein-Spielchen mit Roundtrip über den CAN-Bus erforderlich.

Damit arbeitet der Pi als ein universeller Protokollübersetzer zwischen den Loggern.

Auch bei der Kommunikation ‚in die andere Richtung‘ ist das CMI der Client. Die Kompressorleistung wird nicht auf einem Register des CMI serviert, sondern das CMI schreibt diese Daten in ein Register des Modbus-Server am Pi. Spätestens an der Stelle sollte man vielleicht auch ein wenig paranoid werden und sicherstellen, dass sich das alles nur in einem selbst kontrollierten Netzwerk abspielt. Bei Modbus gibt es nämlich Null Security.

Umgesetzt hat die Datenkrake das mit der Python-Programmbibliothek pymodbus: Der eigentliche Modbus-Server läuft in einem eigenen Thread; die Daten werden in einer unendlichen Schleife von den anderen Loggern geholt und bearbeitet – und dann werden die Register mit den Ergebnissen befüllt.

Am CMI werden Modbus-Eingänge erstellt für alle zu loggenden Werte – Zähler EM210, Wärmepumpe, berechnete Werte …

…und Ausgänge für die Werte, die in die andere Richtung ‚gesendet‘ werden:

Sind dann die entsprechenden CAN-Ausgänge am CMI und Netzwerkvariablen an der UVR eingerichtet …

… steht dem Mitfiebern über Winsol nichts mehr im Wege!

Aber man sollte auch kurz einmal innehalten und sich andächtig den Fluss der Messdaten der Wärmepumpe selbst vorstellen. Die geloggten Heißgastemperaturen z.B. …

… fließen über folgende Stationen:

  • Interner CAN-Bus der Wärmepumpe
  • CAN-Sniffer-Board des Raspberry Pi
  • Register des Modbus-Server des Raspberry Pi
  • Modbus-Eingang am CMI
  • CAN-Ausgang am CMI
  • CAN-Eingang an der UVR16x2
  • Loggingplatz am CMI für diesen CAN-Eingang

Für die lebenswichtigen, kritischen Steuerungssignale würden die Siedler diese Vorgangsweise nicht unbedingt empfehlen 🙂

Wärmepumpen-Forensik – Teil 2: Mitloggen der Heizenergiewerte

Nachdem sich der neue CAN-Bus-Sniffer warmgeschnüffelt hatte mit nicht sehr spannenden Testwerten, wurde es Zeit für den Einsatz im Feld.

Der Raspberry Pi erhielt zunächst einmal einen würdigen Platz, um sich Überblick über den Heizraum zu verschaffen …

Raspberry Pi hat Alles im Blick

Eine typische provisorische Teststellung. Die einzige Stelle, an der am Beginn der Tests das WLAN-Signal halbwegs OK war. Ein ausgekreuztes Ethernet-Kabel gibt’s außerdem auch noch!

Das CAN-Bus-Kabel wurde entsprechend der Bedienungsanleitung an die Wärmepumpe angeklemmt:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, Abschnitt Kleinspannung

Manual (nicht mehr online) – Abschnitt 12.2.3 – Kleinspannung, Bus-Leitung. Die optionale zusätzliche Stromversorgung („+“) wurde nicht verwendet.

Wie beim Testen mit UVR1611 wurde der ebenfalls kurze CAN-Bus nicht speziell terminiert:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, CAN-Bus angeschlossen

Stiebel-Eltron WPF 7 basic mit offenem Gehäuse – High (rot), Low (blau) und Ground (gelb) sind angeschlossen.

Damit konnten die elkementaren Tests beginnen …

Der beste Arbeitsplatz

(Für eine mögliche Einreichung bei Wettbewerben wie ‚Great place to work…‘)

… und die CAN-Schnittstelle wurde aktiviert, entsprechend der Anleitung von messpunkt.org mit einer Bitrate von 20kbit/s:

sudo ip link set can0 type can bitrate 20000
sudo ifconfig can0 up

Ohne aktive Kommunikation sind auf dem Bus mit Wireshark dann nur alle paar Minuten zwei Pakete zu sehen – die Wärmepumpe will also gefragt werden.

Besten Dank wieder an juerg5524.ch für die Bereitstellung von CAN-Tools und der Elster-Tabellen, die die diversen interessanten Parameter / ‚Indizes‘ enthalten!

Wir verschaffen uns zuerst einen Überblick darüber, welche CAN-IDs die Wärmepumpe überhaupt verwendet. Eine CAN-ID repräsentiert ein Set von Eigenschaften wie z.B. Ausgänge und kann auch Informationen über die Knoten-ID am CAN-Bus enthalten (Zu CAN-Grundlagen siehe z.B. dieses Dokument.)

Wird der CAN-Bus angefragt mit einer Sender-ID von 680 (siehe ) …

./can_scan can0 680

… erhält man folgende IDs …

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

scan on CAN-id: 680
list of valid can id's:

  000 (8000 = 325-07)
  180 (8000 = 325-07)
  301 (8000 = 325-07)
  480 (8000 = 325-07)
  601 (8000 = 325-07)

Fragt man gezielt nach jeder dieser IDs …

./can_scan can0 680 180

… sieht man die Liste der Elster-Indizes mit selbst erklärenden Namen der einzelnen Parameter. Die Siedler finden die interessanten (Logging-würdigen) Parameter alle ‚unter‘ der CAN-ID 180 – hier ein Auszug aus dem Output:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

0001:  0000  (FEHLERMELDUNG  0)
0003:  019a  (SPEICHERSOLLTEMP  41.0)
0005:  00f0  (RAUMSOLLTEMP_I  24.0)
0006:  00c8  (RAUMSOLLTEMP_II  20.0)
0007:  00c8  (RAUMSOLLTEMP_III  20.0)
0008:  00a0  (RAUMSOLLTEMP_NACHT  16.0)
0009:  3a0e  (UHRZEIT  14:58)
000a:  1208  (DATUM  18.08.)
000c:  00e9  (AUSSENTEMP  23.3) 
000d:  ffe6  (SAMMLERISTTEMP  -2.6)
000e:  fe70  (SPEICHERISTTEMP  -40.0)
0010:  0050  (GERAETEKONFIGURATION  80)
0013:  01e0  (EINSTELL_SPEICHERSOLLTEMP  48.0)
0016:  0140  (RUECKLAUFISTTEMP  32.0) 
...
01d4:  00e2  (QUELLE_IST  22.6) 
...
092a:  030d  (WAERMEERTRAG_WW_TAG_WH  781)
092b:  0000  (WAERMEERTRAG_WW_TAG_KWH  0)
092c:  0155  (WAERMEERTRAG_WW_SUM_KWH  341)
092d:  001a  (WAERMEERTRAG_WW_SUM_MWH  26)
...
092e:  02db  (WAERMEERTRAG_HEIZ_TAG_WH  731)
092f:  0006  (WAERMEERTRAG_HEIZ_TAG_KWH  6)
0930:  0073  (WAERMEERTRAG_HEIZ_SUM_KWH  115)
0931:  0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39)

Um z.B. den Stand der Raumheizungsenergie in MWh abzufragen, sendet man …

./can_scan can0 680 180.0931

… und der Output enthält gleich die Summe der MWh- und kWh- Angaben (Indices 0930, 0931):

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

value: 0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39.115)

Beim Mitschnüffeln mit Wireshark sieht man die beiden Abfagen (Sender-ID 680) und Rückgabe der beiden Werte. Die Bedeutung der einzelnen Bits wird im Englischen elkementaren Artikel zu diesem Thema beschrieben.

Mitsniffen am CAN-Bus: Wärmepumpe, Abfrage Heizenergie

Netzwerk-Pakete am CAN-Bus: Abfrage der Elster-Indices 0930 (kWh Heizenergie) und 0931 (MWh Heizenergie) mit can_scan.

Um das Monitoring dieser Werte zu automatisieren, wird can_scan alle paar Minuten für die interessanten Parameter ausgeführt und der Zahlenwert aus dem Output in eine CSV-Datei geschrieben. Eine andere Option wäre, nur die Abfrage mit can_scan zu starten und den Output dann mit can_logger einzusammeln.

Die CSV-Datei wird dann per FTP an den Server geschickt, der als Datenkrake sämtliche Logfiles aus unterschiedlichen Quellen (UVR1611 / 16×2, PV-Wechselrichter, Smart Meter) zusammenfasst.

Das komplette Skript – wie auch noch etwas mehr Details zur CAN-Forschung – findet man wie immer auf dem elkementaren Blog.

Natürlich muss der neue Logger auch das Professionalitäts-Level des UVR16x2 einhalten, was die Montage betrifft: Deshalb sind im Routinebetrieb nun beide friedlich auf ihrem Holzbrettchen vereint zu finden (und nach einer Restrukturierung der Netzwerk-Architektur gibt es im Heizraum auch verlässliches LAN und WLAN):

Raspberry Pi mit PiCAN-Board von SK Pang, neben UVR16x2

Raspberry Pi mit PiCAN-Board von SK Pang neben UVR16x2 auf ökologischem Brettchen.

Wie der aufmerksame Leser sieht, wurde auch das CAN-Board getauscht – eine serielle Schnittstelle eröffnet Perspektiven für zukünftige Forschungsprojekte. Danke an SK Pang für ein eigentlich gar nicht mehr verfügbares Board!!

Wärmepumpen-Forensik – Teil 1: Mithorchen am Test-CAN-Bus

In grauer Vorzeit war die Aufnahme von Messdaten eine Herausforderung, die an physische und psychische Grenzen ging:

White-Out

White-Out im Winter 2012/13. Bodentemperaturen mussten trotzdem Irgendwer messen!

Wurzelsepp misst

Warten auf das Temperaturgleichgewicht…

Mittlerweile werden fast alle Messdaten automatisch aufgenommen:

Online-Schema CMI/UVR1611/UVR16x2

Online-Schema CMI/UVR1611/UVR16x2 mit den für die Steuerung nötigen Temperatur- und Durchflusssensoren und einigen weiteren Sensoren für ‚Forschungszwecke‘ (Bodentemperatur, Strahlung)

Aber ein wesentlich Sensor hatte sich der Automatisierungswut der Siedler bis jetzt widersetzt: Die offizielle Arbeitszahl in der Messdaten-Dokumentation wird berechnet aus der Wärmeenergie, die Irgendwer tagaus, tagein am Display der Wärmepumpe abliest.

Die Siedler-Wärmepumpe ist zwar ‚absichtlich dumm gewählt‚ – aber vielleicht gibt es ja doch smarte Ansätze? Im Handbuch der Stiebel-Eltron WPF 7 basic (Edit: 2019: Nicht mehr online – Englisches Manual hier) werden sie fündig: Im Abschnitt Kleinspannung, BUS-Leitung werden die Anschlüsse CAN-Bus für Fernbedienung angeführt – vielleicht könnte man ja hier die Ergebnisse der bisherigen CAN-Bus-Forschung nutzen? Und vielleicht sogar den derzeit nicht produktiven Raspberry Pi verwenden?

Wie praktisch immer, wenn man glaubt ein Pionier zu sein, findet man im Internet bereits Anleitungen und Tools. Besten Dank an die Stiebel-Eltron-Raspberry-Pi-CAN-Bus-Hacker von messpunkt.org und juerg5524.ch!

CAN-Erweiterungsboard für Raspberry Pi

Erste Herausforderung: Unser Pi ist das ältere ‚Modell B‘. Im Gegensatz zum Nachfolgermodell B+ hatte dieser Pi nur 26 GPIO-Pins für Steuerungszwecke anstatt 40. Die PIN-Belegung hat sich zwar nicht geändert, aber neuere CAN-Boards für 40 Pins passen nicht auf den alten Pi. Der versierte Bastler wird aber auf ebay fündig und freut sich über dieses kleine Board passend für 26 Pins.

Damit ist die CAN-Schnüffel-Hardware einsatzbereit:

Raspberry Pi mit CAN-Board

Raspberry Pi mit aufgestecktem CAN-Board und verdrahtetem CAN-Kabel (grau). Blaues Kabel: Ethernet, schwarzes Kabel: Stromversorgung.

Um nicht gleich die Energieversorgung der Siedlerhütte lahm zu legen und Software zu testen, schnüffeln wir zuerst in einer…

Testumgebung: UVR1611 mit Logger BL-NET

Der Pi-Schnüffler wird daher an einen Test-Bus angeschlossen der aus den folgenden altbekannten Geräten besteht:

  • UVR1611-Steuerung mit einem angeschlossenen Temperatursensor
  • Datenlogger BL-NET, per ausgekreuztem Ethernet-Kabel mit einem Test-PC verbunden, auf dem Winsol läuft. Daten werden jede Minute geloggt. (Überblick zu Logging mit UVR1611 und BL-NET).

Eigentlich müsste jeder CAN-Bus an beiden Enden terminiert werden. Da dieser Test-CAN-Bus wie auch der Wärmepumpen-CAN-Bus nur sehr kurze Kabel verwenden und sie keine negativen Erfahrungen gemacht hatten mit kurzen falsch terminierten Bussen, verzichten die Siedler auf eine korrekte Terminierung.

Test Can-Bus: UVR1611 und BL-NET

Test Can-Bus: UVR1611 (Mitte) mit einem Pt1000-Temperatursensor (Metallhülse, schwarzes Kabel) und Datenlogger BL-NET (oben, weiß). Das CAN-Kabel (grau) verbindet 1) UVR1611, 2) BL-NET (blauer Stecker) und Raspberry Pi (nicht im Bild). Am LAN-Kabel (gelb) ist ein PC mit Winsol angeschlossen.

Software und Konfiguration

Zuerst wird der Kernel des Raspberry Pi auf eine Version upgedated, die die CAN-Schnittstelle unterstützt. Für Details siehe z.B. diesen Blog-Artikel (Abschnitt Software Installation).

In der Raspberry-Pi-Konfiguration muss der für CAN benötigte SPI-Bus aktiviert werden. Dies wird im Detail beschrieben im Blog des CAN-Board-Herstellers SK Pang.

Bitrate einstellen

Der UVR-CAN-Bus verwendet eine Bitrate von 50kbit/s – im Gegensatz zum Wärmepumpen-Bus, der 20kbit/s benötigt. Mit folgendem Befehl wird die Bitrate eingestellt und die CAN-Schnittstelle ‚aktiviert‘:

sudo ip link set can0 type can bitrate 50000
sudo ifconfig can0 up

Bei falscher Bitrate sieht man beim Mitschnüffeln keine Pakete weil das CAN-Interface ’stummgeschaltet‘ wurde (Fehler BUS OFF [*]).

Wenn man alles richtig macht, sind jetzt alle zwischen BL-NET und UVR1611 ausgetauschten Pakete auch für den Raspberry Pi lesbar. Installiert man Wireshark, kann die CAN-Schnittstelle ausgewählt werden … und die Pakete werden korrekt dem CAN-Protokoll zugeordnet:

CAN-Bus-Netzwerkverkehr mitsniffen mit Wireshark

Nachdem Steuerung und Logger diesen Test überstanden haben, wagen sich die Siedler an die Kommunikation mit der Wärmepumpe heran. Fortsetzung folgt … hier in Teil 2.

[*] Etwas mehr Details im elkementaren Artikel zu diesem Thema.

_______________________________________________

Weitere Details zur CAN-Kommunikation der UVR1611