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 🙂

Die Datenkrake – Reloaded

Unsere Datenkrake wächst und mutiert still und heimlich. Nachdem Irgendwer ein Tentaktel einen Teilaspekt beleuchtet hat, wird es Zeit für ein umfassenderes Update.

Unter Datenkrake verstehen wir Infrastruktur und Software zur Auswertung von Messdaten des Wärmepumpensystems LEO_2 oder von weiteren ‚Energie-relevanten‘ Systemen wie Photovoltaik-Generator und Stromverbrauch.

Sensoren und Original-Messdaten

Am Anfang der Datenlawine stehen die Messdaten diverser Sensoren – diese müssen in kurzen Zeitintervallen auf einem Logger abgelegt werden. Vom Logger werden die Daten über Ethernet weiter transportiert in ein 0815-Computernetz-Netzwerk.

In der Siedler-Infrastruktur ist der wesentliche Datenlogger das zu den Steuerungen UVR1611 und UVR16x2 gehörende C.M.I – Control and Monitoring Interface. Alle 1,5 Minuten werden über den CAN-Bus Werte für Temperatur, Durchfluss, Strahlung, Druck etc. gesendet. Die aktuellen Werte sind auch im Online-Schema sichtbar – einer Darstellung, die vom Webserver auf dem CMI erzeugt wird:

Online-Schema: CMI punktwissen

Der Zugriff auf das Online-Schema ist nur mit einem registrieren Benutzer möglich. Wir wiederholen unser Angebot, interessierten Siedlern (temporären) Zugriff zu geben – bitte E-Mal an:
punkt [ät] punktwissen [dot] at

Die Sensoren sind …

  • direkt an den Eingang einer der Steuerungen angeschlossen,
  • über den DL-Bus an die UVR1611 oder UVR16x2
  • oder über Erweiterungsmodule wie CAN-IO – hier ist z.B. der Globalstrahlungssensor angeschlossen – oder CAN-EZ, von den Siedlern als Stromzähler für Verbrauch der Wärmepumpe verwendet.

Das CMI ist ebenso ein Gerät am CAN-Bus, der insgesamt momentan so aussieht:

CAN-Bus punktwissen, Darstellung CMI

BL-NET ist der Vorgänger-Logger, der nur zu ‚Forschungszwecken‘ angeschlossen bleibt. Dieses parallele Logging wird vom Hersteller nicht empfohlen!

Neben Logging und Online-Schema dient das CMI auch als Fernbedienung für die Regler, zur Einstellung von Parametern oder Firmware-Updates. Über das Webportal der Technischen Alternative ist das CMI (optional) auch von extern über das Internet erreichbar.

2015 wurde die Siedler-Infrastruktur um zwei weitere Datenquellen mit Logger erweitert, beide sind über WLAN angebunden:

Einen Fronius Symo-PV-Wechselrichter mit eingebautem Datalogger (mit einem USB-Stick als lokalem Speicher) …

Fronius Symo Wechselrichter mit Data Logger - WLAN-Antenne und USB-Stick

… und ein Smart Meter zur Messung des Eigenverbrauchs:

Smart Meter EM210 mit WLAN-Antenne, montiert im Zählerkasten über dem Siemens-Zähler des EVU.

Nähere Details zu den Features dieser Logger wurden hier beschrieben. Wichtig war für die Siedler, dass Messdaten immer lokal – also nicht nur über eine ‚Hersteller-Cloud‘ zur Verfügung stehen und dass sich die Daten einfach zusammenführen lassen mit den UVR-Daten, um z.B. den Haushaltsstromverbrauch mit dem Strom für den Kompressor der Wärmepumpe vergleichen zu können oder eine Korrelation von Außentemperatur und PV-Ausbeute zu finden.

Die CSV-Datei als das ultimative Austauschformat

Das endgültige Ziel des Messdatensammlers ist eine einfache Auswertung der interessanten Kenndaten, wie z.B. der monatlichen Arbeitszahlen der Wärmepumpe oder der Autarkiequote für die PV-Anlage.

Man kann die Daten vom eigentlich Logger sofort abzugreifen und in eine Datenbank schreiben – das ist z.B. der Ansatz des UVR Data Logger Pro, der CMI (oder den Vorgänger BL-NET) wie ein CAN-Ethernet-Gateway verwendet.

Die Siedler als IT-Dinosaurier verlassen sich auf simple Textdateien als Zwischenspeicher: CSV-Dateien können in beliebige Datenbankserver importiert werden, und die Daten anderer Siedler können analysiert werden auch wenn man in deren Infrastruktur nicht direkt eingreifen kann.

Der Datenbankserver …

… stammt von jener Firma, deren Gründer heute sehr aktiv im Bereich erneuerbarer Energien ist.

Logfiles werden von den drei Loggern CMI, Fronius Data Logger und EM210-Zähler abgeholt und mittels SQL-Skript in einen Microsoft SQL Server importiert. Zusätzlich wird der Server mit einer CSV-Tabelle von einigen Daten gefüttert, die noch oder zusätzlich manuell abgelesen werden (z.B. dem Wärmemengenzähler in der Wärmepumpe).

Die wesentliche Herausforderung, diese Krake bei Laune zu halten, besteht in der laufenden Änderung des Systems durch neu hinzugekommene Sensoren oder neue Auswertungen. Die SQL-Scripts werden so angepasst, dass die komplette Datenbank jederzeit neu aus den sich langsam ändernden Logfiles aufgebaut werden kann.

SQL Server Manager - Views und Scripts

Auswertung und ‚Front-End‘

Die Ansichten in jener Datenbank enthalten alle gewünschten Berechnungen, wie z.B. Mittelwerte und Arbeitszahlen. Bei Mittelwerten muss berücksichtigt werden, dass viele Messdaten nur während bestimmten Betriebszuständen Sinn machen: Z.B. dürfen bei der Ermittlung der Kollektorernte nur Zeitintervalle beitragen, in denen der Kollektor auch zugeschaltet war. Da es sich um reale Messwerte handelt, ist insbesondere das automatische Ausblenden von ‚Sensor-Auszuckern‘ wichtig.

Wie Experten an unseren Diagrammen sicher schon gesehen hatten, wird Microsoft Excel zur Darstellung der Daten verwendet. Die Siedler schätzen die Möglichkeit, gewisse Details wie Farben von Linien manuell einzustellen und andererseits die gewünschten Zeiträume oder Auswahl von Feldern aus der Datenbank zu automatisieren.

Excel 'Plottomat' - zur automatischen Erstellung von Diagrammen aus SQL-Daten

Die puristische Excel-All-in-One-Variante

Jeder IT-Dinosaurier weiß, dass ein Haufen CSV-Dateien eigentlich schon eine Datenbank ist. Zur Analyse von Kundendaten wurde daher eine spezielle Variante der Auswertung entwickelt – auf dieses Tool bezieht sich auch Irgendwessen Posting.

Wesentliche Kennzahlen, wie sie in den SQL-Server-Ansichten definiert wurden, wurden in diesem Tool durch einen direkten Zugriff auf die monatlich erstellten UVR-CSV-Logs ersetzt. Um z.B. Summen oder Mittelwerte über Messwerte unter bestimmten Bedingungen zu erstellen (wie: Temperatur X für Tag Y wenn Wärmepumpe ein), kommt man um Excel-Matrixformeln nicht herum.

Wenn man es noch genauer wissen will:

Die Standard-Krake enthält UVR-Daten für alle 90 Sekunden, PV-Daten alle 5 Minuten und Zählerdaten alle Minuten. Daraus werden Ansichten für Tage, Monate, Kalenderjahre und Heizsaisonen gebildet.

Will man aber ausnahmsweise Daten sekündlich auslesen, stehen je nach Logger diverse Profi-Schnittstellen zur Verfügung wie Modbus TCP (einige wurden hier beschrieben). Was aber praktisch immer geht, ist das direkte Abgreifen der Daten von der entsprechenden Website zum ‚Mitschauen‘.

Greift man z.B. die große blaue Zahl hier jede Sekunde ab…

PV: Aktuelle Leistung, Anzeige Webportal

… kann man auch kurze Spannungspitzen sehen, die im 5-Minuten-Logging weggemittelt würden:

PV-Leistungsspitzen - nur wenige Sekunden breit

Siedler-Sonnenenergie: Zwischenstand

Einige Monate sind ins Land gegangen, seitdem die Siedler ihr Solarkraftwerk in Betrieb genommen hatten, ihre Zählerlandschaft erweitert und die Messdaten in ihre persönlichen Datenkrake integriert.

Wie sehen ‚die Zahlen‘ aus?

Besondere Tage und Effekte

Der Mai begann vielversprechend: Der absolute tägliche High Score seit der Inbetriebnahme wurde bereits am 11. Mai erzielt. Dagegen war die geringste gemessene Ausbeute an einem verregneten Septembertag eher jämmerlich:

PV: Tage mit max. und min. Ausbeute, Mai-Sept 2015

Der beste Tag: 11.Mai mit einer Ausbeute von fast 33 kWh. Der schlechteste Tag: 25.September bis nicht einmal 1 kWh. AC = Wechselspannung, Output-Leistung. DC = Gleichspannungs-Leistung der beiden Strings – 10 Module Richtung SO, 8 Module Richtung SW, 4,77 kWp insgesamt.

Die höchsten Leistungsspitzen wurden an sonnigen, aber nicht zu heißen, Tagen mit durchziehenden Quellwolken beobachtet – im Datenlogging (Intervall 5 Minuten) finden sich an drei Tagen einige wenige Spitzen mit 4,3 kW:

PV: AC-Leistung 2015-06-21

Typische Leistungsspitzen nahe an der Nennleistung des Wechselrichters (4,5 kW), abwechselnd mit Einbrüchen beim Durchzug von Wolken (Datenlogging Fronius Symo).

Noch weitere Details – und das ‚dramatische Ausmaß‘ dieser Spitzen – wird deutlich, wenn das Logging-Intervall auf 1-2 Sekunden erniedrigt wird:

PV: Leistung, Logging-Intervall 1-2 Sekunden

Leistung beim Durchzug von Wolken. Die Daten wurden einige Stunden lang mit einem Script direkt von der Website des Wechselrichters abgegriffen.

Die besonders hohe Leistung nach dem Durchzug von Wolken wird durch zwei Effekte verursacht:

  • Die ‚Fokussierung‘ von Strahlung (Reflexion oder Brechung) am Rand der Wolken – damit gelangt auf das ‚Loch‘ zwischen den Wolken mehr Strahlung (Details dazu siehe z.B. hier)
  • die zwischenzeitliche Abkühlung der Module, die zu einer Erhöhung des Wirkungsgrades führt.

Ohne Temperatursensor in der Nähe der Module lässt sich nicht sagen, welcher Effekt überwiegt. Generell können die Siedler aber den negativen Effekt sehr hoher Temperaturen qualitativ nachweisen:

Als Referenzwert dient die gemessene Tagessumme der Globalstrahlung auf eine senkrechte nach SO ausgerichtete Fläche. Wir suchen zwei fast perfekte Tage mit gleicher gemessener Referenzstrahlung, mit wenigen Tagen dazwischen (daher geringem Unterschied im Sonnenstand) und sehr unterschiedlichen Temperaturen. Am Tag mit der höheren Lufttemperatur ist die Energieausbeute deutlich geringer:

PV: Vergleich von PV-Ausbeute, Globalstrahlung und Lufttemperaturen.

Vergleich der täglichen PV-Energie-Ernte mit der Globalstrahlung pro m2 auf eine senkrechte nach SO ausgerichtete Fläche und der mittleren und maximalen Lufttemperatur. Mit grün gepunkteten Linien markiert: 1.August und 12.August mit gleichen Globalstrahlungswerten, aber sehr unterschiedlichen Temperaturen und PV-Ernten.

Am 1. August war der Ertrag trotz einigen Wölkchen höher als am 12. August, dem Rekordhitzetag dieses pannonischen Sommers:

PV: Vergleich heißer und kühlerer Tag im August.

An diesen beiden Tage wurde am Kollektor die gleiche Globalstrahlungssumme gemessen. Die Unterschiede in der PV-Leistung können in erster Linie durch die sehr unterschiedlichen Lufttemperaturen erklärt werden. (Logging Symo-Wechselrichter, kombiniert mit Daten UVR1611 / CMI).

Statistik

Zur Beurteilung wie gut die Anlage zum Eigenverbrauch ‚passt‘ kann man den direkt in der Siedlerhütte verbrauchten PV-Strom entweder mit dem eigenen Gesamtverbrauch vergleichen oder der gesamten täglichen PV-Ausbeute:

PV: Direktverbrauch, Netzbezug, Netzeinspeisung monatlich.

Monatsübersichten. Der Mai ist nicht vollständig, da die Anlage mit Zähler erst am 5.5. in Betrieb genommen wurde. Eigenverbrauchsdaten wurden bis Mitte Juni täglich manuell vom ’smarten‘ Zähler des Netzbetreibers abgelesen (Siemens AMIS TD-3511 und ab dann aus dem Logging des eigenen, zusätzlichen (wirklich) smarten Zählers ermittelt (B-Control EM210, Intervall 15 Minuten).

In der Sprache der PV-Kennzahlen: Die Siedler konnten Juni-August 60% ihres Bedarfs ‚direkt von der Sonne‘ decken (Autarkiequote) bei einer Eigenverbrauchsquote von ca. 25%; im September sinkt die Autarkiequote und steigt der Eigenverbrauch:

PV: Autarkiequote vs. Eigenverbrauchsquote

Autarkiequote: PV-Direktbezug zu Siedlerhüttenverbrauch. Eigenverbrauchsquote: PV-Direktbezug zu PV-Ernte.

Dieses Bild wird sich in der Heizsaison schlagartig ändern. Am ‚jämmerlichsten‘ Tag, dem 25. Sept., konnte z.B. eine Eigenverbrauchsquote von 100% erreicht werden, da die Solarausbeute gering war und sich der Herzschlag von LEO_2 an diesem Tag mit dem ersten Heiz-Lebenszeichen bemerkbar gemacht hatte:

PV: September 2015, tägliche Energiebilanz

Wie man aus dieser Darstellung erahnen kann, bieten die Energieverbrauchsdaten auch einen Fingerabdruck des nicht allzu aufsehenerregenden Lebens der Siedler. ‚Aus Sicherheitsgründen‘ werden diese Messdaten daher immer erst nachträglich veröffentlicht. (Na ja, im Voraus wäre es ohne Zeitmaschine ohnehin nicht möglich…)

Im Juli beispielsweise konnten die Siedler während einer dreitägigen Forschungsreise ihrem minimalen täglichen Stromverbrauch ermitteln:

PV: Juli 2015, tägliche Energiebilanz

Die Siedlerhütte hatte tatsächlich täglich 4 kWh benötigt, um sich mit sich selbst zu beschäftigen. Die genaue Analyse und Reduktion dieser Grundlast ist Thema eines neuen Forschungsprojektes und zukünftiger Geschichten.