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 🙂

Logging-Forschung: Beim Fenster raus und bei der Türe wieder rein

Die Datenkrake wird täglich herausgefordert: So viele Möglichkeiten gibt es, neue Tentakel in bisher unerforschte Gebiete auszustrecken!

Das CMI ist seit einiger Zeit selbst eine Datenkrake: In den Einstellungen können Ein- und Ausgänge am CAN-Bus oder für Modbus-TCP konfiguriert werden.

Logisch und physisch getrennt von Wärmepumpe und Hydraulik arbeitet der PV-Wechselrichter der Siedler (Fronius Symo 4.5-3-M). Die PV-Daten werden lokal auf einen USB-Stick geloggt; das minimale Loggingintervall beträgt 5 Minuten. An manchen dunklen Abenden werden die gesammelten Daten dann an die Krake verfüttert. Der Fronius-Datenlogger hat eine WLAN-/Internet-Verbindung und einen lokalen Webserver, aber direkt ‚online runterkopieren‘ von diesem Stick kann man die Daten nicht.

Aber es gibt eine Modbus-TCP-Schnittstelle: Damit können die aktuellen Daten von einem Computer im  lokalen Netzwerk abgefragt werden oder von einem anderen Dings im Internet of Things. Die Siedler wollten nun wissen, ob der Modbus-Client des CMI das USB-Logging ersetzen könnte. Oder könnte gar die künstliche Intelligenz der Regelung auf die aktuelle PV-Leistung reagieren? Der Wechselrichter hat eine Energiemanagement-Funktion, aber 1) er könnte nur sehr schlicht über ein Relay ‚kommunizieren‘ und 2) das natürlich nicht über WLAN.

Nötige Schritte und einige Erkenntnisse:

Modbus wird aktiviert am Datenlogger des Wechselrichters. Wir entscheiden uns für echte Kommazahlen und erlauben keine Änderungen über Modbus:

Modbus-Einstellungen am lokalen Webserver des Fronius-Symo-Wechselrichters. 502 ist der Modbus-Standardport. Die Alternative zu float wären Ganzzahlen mit Skalierungsfaktor SF (Faktor steht dann in anderem Register).

Check der Modbus-TCP-Dokumentation von Fronius: Benötigt werden die Register (‚Speicherplätze‘) der interessanten Werte, z.B. die aktuelle Outputleistung. Das ausführliche PDF ist aktuell hier zu finden (Letzter Check/Update des Links: 2019-01). Eventuell Logging-würdige Werte sind in verschiedenen Tabellen (‚Models‘) zu finden – z.B. Daten die dem Wechselrichter ‚als Ganzes‘ zugeordnet werden oder nur einem String von PV-Modulen.

Dokumentation S.30, Common Inverter Model. Zum Loggen der Wechselstrom-Leistung werden folgende Angaben benötigt: Adresse 40092, Registertyp 3 (read and hold), Datentyp float32 (Platz entspricht zwei 16bit-Register, daher ist die Endadresse 40093) und die Einheit Watt.

Wichtig dazu ist dieser Hinweis auf S.15:

D.h. auf einem Modbus-Client muss bei der Abfrage der Leistung 40091 angegeben werden.

Mit diesen Infos und der IP-Adresse des Wechselrichters in lokalen Netz wird ein entsprechender analoger Modbus-Eingang am CMI festgelegt:

Modbus-Analogeingang 1 liest die aktuelle PV-Leistung vom Wechselrichter. Der ‚Eingangswert‘ ergibt sich, wenn die Daten als Integerzahl interpretiert werden. ‚Aktueller Wert‘: Der Integer-Teil der ‚wahren‘ Gleitkommazahl.

Ja, wir haben uns das in einem Netzwerk-Trace angeschaut 😉 nachdem uns das Dropdown-Menü zur Byte-Reihenfolge etwas verwirrt hatte: Modbus-TCP sollte immer Big Endian verwenden laut Protokollspezifikation.

Faktoren und Datentypen: Am CAN-Bus werden nur Integer-Werte verarbeitet – evtl. mit einem Skalierungsfaktor als Zusatzinformation. Bei der Leistung in Watt gibt es da glücklicherweise keinen Handlungsbedarf. Würde man aber z.B. die 15A Strom mit einer Kommazahl loggen wollen, müsste man den Faktor auf 10 setzen um eine Kommastelle aus der Floatzahl ‚mitzunehmen‘. Vorher am Symo Integer + Skalierungsfaktor einzustellen ist nicht sinnvoll, da dieser Faktor in einem anderen Register des Wechselrichters steht … das das CMI natürlich nicht kennt.

Wenn man statt relativ stabilen Werten irgendwelche Zahlen zwischen ca. -32000 und + 32000 sieht 😉 merkt man, dass hier etwas schiefgegangen ist.

Diese Einstellung bedeutet noch nicht, dass das CMI die Modbus-Daten schon ‚hat‘ und mitloggt. Alles, was man bis jetzt davon ‚hat‘, ist die Anzeige des aktuellen Wertes in der CMI-Modbus-Einstellung. Zur Weiterverarbeitung inklusive dem Logging am CMI selbst muss wieder ein passender Ausgang definiert werden. Das CMI kann nur über CAN- oder DL-Bus loggen. Also brauchen wir einen…

… analogen CAN-Bus-Ausgang am CMI:

Das CMI hat die Standard-Knotennummer 56. Jedes andere Gerät am CAN-Bus kann damit diesen Wert auslesen durch Angabe der Knotennummer und der Nummer des Analogausgangs – 1.

Diese Geräte nutzen aktuell den CAN-Bus:

Darstellung der Geräte durch das CMI. Beim Klick auf (unterstützte) Geräte kommt man in das entsprechende Konfigurationsmenü.

Wenn man sich die Logging-Einstellungen am CMI ansieht, könnte man in Versuchung kommen, einfach das CMI selbst – CAN 56 – auszuwählen:

Am CMI konfiguriertes lokales CAN-Logging (Nutzung mit Winsol) – von UVR1611 (1), UVR16x2 (2) und dem Energiezähler CAN-EZ (41).

Erkenntnis: Das CMI kann aber seinen eigenen CAN-Ausgang nicht loggen. Man kann zwar CAN 56 als Logging-Quelle im Dropdown-Menü anklicken, aber das endet dann so:

CAN-Fehler am CMI – ausgelöst durch den Versuch, das CMI als Logging-Quelle einzutragen (so dass es gleichzeitig Logger und Quelle spielt).

Hier ist das ‚Durchschleifen‘ des Wertes durch die ‚loggingfähige‘ UVR nötig – womit endlich der Titel des Postings erklärt wäre!

An der UVR16x2 wird der CAN-Ausgang des CMI jetzt als CAN-Eingang (‚Netzwerkvariable‘) verbunden:

Definition des Netzwerkeingangs auf der UVR16x2. Quelle ist der CAN-Ausgang am CMI (Knoten 56, Ausgang 1).

Die Leistung in Watt wird als Integer übergeben. Hätte man am Modbuseingang einen Faktor 10 verwendet, müsste hier die Einheit auf ‚dimensionslos,1‘ gesetzt werden.

Aktueller Wert am CAN-Netzwerkeingang.

Die UVR16x2 kennt damit die PV-Leistung. Dieser Wert steht für Regelungszwecke zur Verfügung und Irgendwer kann beginnen, das Warmwasser-Zeitprogramm durch eine Digitalisierte Smarte 4.0 Big Data AI Bot Version abzulösen. Skynet entwickelt ein Bewusstsein!

Andererseits kann der Wert durch das CMI von der UVR geloggt werden – der neue CAN-Eingang wird in den Datenlogging-Einstellungen in TAPPS hinzugefügt und steht dann in Winsol zur Verfügung:

Anzeige der geloggten Daten mit Winsol (Zugriff auf lokale Logfiles): PV-Leistung, Globalstrahlung auf die senkrechte Fläche des Kollektors, Kollektortemperatur, Außentemperatur.

… bzw. kann das ‚Portal-Logging‘ auf cmi.ta.co.at konfiguriert werden …

Konfiguration des Loggings direkt am Portal cmi.ta.co.at – als mögliche Loggingquellen stehen nur UVR1611 und UVR16x2 zur Verfügung. Die interessanten CAN-Ausgänge müssen in den rechten Bereich gezogen werden – dann kann dieser Parameter in einem Profil ausgewählt werden und das Diagramm des Werteverlaufs wird online angezeigt.

… und online mitverfolgt …

Anzeige Logging-Profil auf cmi.ta.co.at. In diesem Fall werden die Daten beim Logging vom CMI an das Portal gesendet und dort gespeichert.

Würde man alle Outputwerte des Fronius-Datamanagers auf diese Art loggen, hätte man außerdem schnell die Limits betreffend Netzwerkvariablen und Loggingplätzen erreicht. Wenn man unbedingt jede Minute die Spannung zwischen Phase 1 und 2 oder die Blindleistung wissen will, verwendet man besser einen eigenen Logger, z.B. Rasperry Pi. Hier ist ein perfekt dokumentiertes Projekt: Logging der Daten von Fronius Symo mit Python über Modbus TCP, plus Datenbank und Weboberfläche.

Nur Werte, die tatsächlich auch zum  Regeln benötigt werden, sollten beim Fenster rausgeworfen und bei der Türe wieder hereingebeten werden!