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 🙂

7 Gedanken zu „Raspberry Pi als Modbus-Server – ein Universalübersetzer für die UVR16x2

  1. Hallo Elke,

    da ich auch gerade dabei bin die Stromseite im CMI-Schema darzustellen, würde mich interessieren, welche Funktion der CAN-EZ2 bei euch im obigen Bild hat.
    Mit diesem könnte man doch auch über den CAN-BUS am Zählpunkt alle Werte Leistung, Strom, Spannung, Frequenz etc. gesamt und je Phase einbinden und darstellen ?
    Warum habt ihr da noch zusätzlich den EM210LR ?

    Danke im Voraus für die Info.

    LG

    Karl

  2. Danke für ein weiteres Signal aus den Tiefen des Irgendwo. Literarisch nachlassen kommt also auch nicht in Frage. Eine Frage habe ich:
    „Für die lebenswichtigen, kritischen Steuerungssignale würden die Siedler diese Vorgangsweise nicht unbedingt empfehlen“
    Warum?
    Hochachtungsvoll (echt jetzt, nicht so wienerisch amtssprachvergittert)
    frank

    • Weil dann die „lebenswichtigen Funktionen“ z.B. davon abhängig sein würden, ob der Raspberry Pi noch lebt und das Skript dort noch läuft!

      Das ist keine Lösung, die jetzt unbedingt ‚robust‘ ist – ein Pi stirbt irgendwann an korrupter SD-Karte (haben wir alles ausprobiert ;-)), und/oder ein Dienst kann sich auch irgendwann einmal verabschieden. Bei solchen Funktionen setzen die Siedler lieber auf Hard- und Software, die genau für sowas gebaut ist und ‚ewig‘ hält. Zuviele Abhängigkeiten, zu überwachende Komponenten, zu hohe Komplexität…

      Vergleichbar hinsichtlich Abhängigkeiten, wenn auch noch extremer: Wenn wieder jemand twittert dass das Haus kalt ist weil das Internet gerade nicht geht und/oder der „Cloudserver“ des „Smart Home“ aus anderen Gründen nicht erreichbar ist.

      • Was die Verwendung von [zu viel] elektronik angeht bin ich auch vorsichtig. Vielleicht weil ich mich schon über 30 Jahre damit befasse. Ein „klassisches“ Haus hat einen „Updatezyklus“ von sagen wir mal 60 Jahren. Alle 30 Jahre eine große Inspektion (Dach, Wasserventile usw.) Ich habe es in den Anfängen mit wireless Taster fürs Licht beim Nachhausekommen probiert. 2 Jahr später der Schlüsseanhänger kaputt. Die neue Version war nicht mehr kompatibel und so habe ich alle 3 Komponenten ausgetauscht und bei der letzten Renovierung weggeworfen.
        Je nachdem von wem man sich die „Homeautomation“ kauft kann es sein, dass der „Updatezyklus“ vom funktionierenden Haus nur mehr 5-10 Jahre beträgt.
        Warum. Ganz einfach. Wenn wir 10 Elektrogeräte im Haus haben kann man davon ausgehen, dass eines pro Jahr kaputt geht.
        Wenn man 100 Geräte im Haus hat werden jedes Jahr 10 kaputt. Von der Leuchte , bis zur Heizungspumpe, vom Fernseher bis zum Modem, vom Handy bis zum Garagentor. Nichts hält ewig.
        …Im Keller habe ich einen alten Drehschalter. Der hält im Aussenbereich bereits seit über 60 Jahre!
        Allses was ich nicht eingbaut habe kann auch nicht kaputtgehen. Daher habe ich auch keine Homeautomation.
        And der Eisheizung wird gearbeitet 🙂

    • … und noch eine Antwort auf die andere Frage auf dem mysteriösen Posting 😉 Das was ein uralter, nie publizierter Entwurf aus dem Jahr 2013, der uns (mir ;-)) versehentlich ‚ausgekommen‘ war! Die Zahlen sind nicht mehr aktuell … die Siedler wollen da keine Verwirrung stiften!

Die Kommentarfunktion ist geschlossen.