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

Die Datenkrake wird täglilch 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. 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 – als Teil des immer schon genutzten CAN-Loggings:

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!

Die Kunst des Zählens

Es gibt drei Sorten von Menschen:
Die, die zählen können und die anderen.

–Quelle: Das Internet.

Zählen als Kunst und als Handwerk darf wahrlich nicht gering geschätzt werden. Das letzte Technologie-Auswahl-Projekt der Siedler zeigte dies wieder deutlich. In diesem Posting geht es um mehr oder weniger Intelligente Messgeräte zur Erfassung der elektrischen Energieströme zu und von der Siedlerhütte.

Derzeit kennen die Siedler die momentane Ausbeute ihres Kraftwerks genau, aber nicht ihren eigenen Verbrauch. Entsprechend dem ursprünglichem Anforderungskatalog im Projekt Sonne und Wölkchen loggt der Siedler-Wechselrichter alle 5 Minuten Messdaten (auf einen USB-Stick). Die Diagramme in den letzten Postings basieren auf diesen Daten.

Die sprichwörtliche Wankelmütigkeit der erneuerbaren Energie lässt sich veranschaulichen, wenn man in noch kürzeren Zeitabständen die aktuelle Leistung direkt von der Website des Wechselrichter abgreift (Danke, Powershell!) oder eine der anderen offenen Schnittstellen verwendet.

PV-Leistung, teilweise Wolken

Leistung nach Messung des Wechselrichters, beim Durchzug von Wolken. Durch die zwischenzeitliche Kühlung der Module fallen die Spitzen besonders hoch aus (4,77 kWp, verteilt auf SO- und SW-Dach)

Aber auch der Stromverbrauch der Siedler ist wankelmütig. Insgeheim hatten sie gehofft, dass ihr neuer elektronischer Zweirichtungszähler die 15-minütigen Messwerte schon in die Smarte Pannonische Cloud speichern würde. Aber: Der Zähler ist Borg, und nur schlau, wenn er an sein Kollektiv angeschlossen ist. Allerdings existiert die entsprechende Infrastruktur (PLC-Datenverbindungen, Datenkonzentratoren in Trafostationen) in Pannonien noch nicht.

Siemens-amis-td-3511-smart-meter

Links der neue Siemens-Zähler (TD-3511); im oberen linken Eck die IR-Schnittstelle.

Nach Jahren des Selbstablesens und Auf-der-Website-Abschickens des Zählerstandes von alten Ferraris-Zählers wurden die Siedler mit dem neuen Zähler wieder zurückgeworfen in eine Ära des Es-kommt-jährlich-irgendwer-ablesen. Dieser Irgendwer (nicht zu verwechseln mit Irgendwem, dem Chefingenieur!) kommt aber mit Hightec-Equipment – einem Infrarot-Lesekopf. Der bedauernswerte neue Zähler ist auch nur eine Zwischenlösung und wird vom Netzbetreiber in einigen Jahren durch einen wirklichen schlauen ersetzt werden.

Womit wir schon mitten in unserer spannenden Forschungsreise durch die Welt der möglichen technischen Lösungen sind, derweil wir noch täglich am Abend manuell die Messwerte vom Display des Zählers ablesen.

Die Anforderungen:

  • Mitloggen des Eigenverbrauchs, mindestens im Abstand von 15 Minuten, entsprechend dem offiziellen Messintervall. Output sollte eine simple CSV-Datei sein, die sich dann auf die bewährte Weise in die Datenkrake der Siedler importieren lässt.
  • Wenn möglich: Erfassung von Daten für die drei Phasen – auch wenn das die Schieflastigkeit der über Jahrzehnte gewachsenen Elektro-Infrastruktur der Siedlerhütte schonungslos demonstrieren wird.
  • Idealerweise mit Option zum ‚Mitschauen‘ in kürzeren Abständen, z.B. um eine Spannungsspitze beim Einschalten eines Gerätes zu verfolgen.
  • Speichern der Daten in einem energiesparenden Logger, also ohne Notwendigkeit, einen ‚Datenerfassungs-PC‘ laufen zu haben.
  • Zugriff über ein auch für Computer-Fuzzis interpretierbares Protokoll – auch wenn es sehr interessant wäre, sich in weitere Protokolle einzuarbeiten.
  • Idealerweise auch über WLAN, also Minimierung der zusätzlich nötigen Verkabelung.
  • Wenn Funkprotokoll, dann möglichst so, dass man dieses nicht 24/7 aktiviviert haben muss, um den Energieverbrauch des Zählers zu optimieren.

Folgende Lösungen hatten die Siedler ins Auge gefasst:

M-Bus-Modul des offiziellen Smart Meters: Der Siemens-AMIS-Zähler (TD-3511) verfügt über die Option, ein Modul für die Datenerfassung über M-Bus anzuschließen. Dieses Modul wurde früher den Kunden im Herkunftsland der Siedler angeboten (zur Selbstinstallation). Die Siedler-Steuerung könnte prinzipiell mittels Buskonverter M-Bus auf CAN-Bus umsetzen. Diese Lösung scheitert an zwei Dingen:

IR-Schnittstelle des Zählers: Diese Schnittstelle (IEC 62056-21) wird für Service-Zwecke verwendet, kann aber auch die vom Großen Regulator gewünschte unidirektionale Kundenschnittstelle darstellen. Jener eben erwähnte innovative Netzbetreiber aus der Siedler-Heimat nutzt die IR-Datenausgabe als Kundenschnittstelle und bietet seinen Siedlern hier ein ‚Paket‘ an (Edit 2017: Link zum Paket ging nicht mehr, ersetzt durch archivierte Version).

Siedler aus einem anderen Bundesland müssten die Einzelkomponenten kaufen  – Loxone Miniserver Go oder klassischer Loxone Miniserver plus Loxone Air Base Extension, und das Zählerinterface Air. Zur Inbetriebname ist der individuelle Zähler-/Kundenschlüssel nötig; diesen würden die Siedler von Ihrem Pannonischen Netzbetreiber erhalten. Dann müsste noch ein Logging-Baustein konfiguriert werden und der Miniserver wird zum Datenlogger.

  • Vorteil und Versuchung: Endlich wieder in eine neue Steuerungswelt einarbeiten – Spielzeug-Alarm!
  • Nachteil: Eben dieses.

Elektronik-Bastlerei: Genau für den Zähler TD-3511 bietet volkszaehler.org auch eine Anleitung zur Datenkommunikation und zum Selber-Löten der entsprechenden Bauteile. Vor- und Nachteile wie gerade beschrieben, nur krasser (dafür viel billiger).

Das fremdkontrollierte Smart Meter zum Wechselrichter. Jeder Wechselrichterhersteller hat mittlerweile nicht nur eine Cloud, sondern googleartige künstliche Intelligenz (inkl. Konsultation eines Internet-Wetterorakels) und natürlich diverse Apps. Um diese schönen animierten Bildchen vom Energietransport zwischen Wechselrichter, Batterie und Hausnetz anzeigen zu können, muss die App auch die lokalen Eigenverbrauchsdaten kennen. Das wird durch den Einbau eines Smart Meters des Wechselrichterherstellers gelöst, der mit dem Wechselrichter kommuniziert (Z.B.: SMA Smart Meter, Fronius Smart Meter).

  • Vorteil: Logging integriert mit denen der PV-Erzeugung – im Fall der Siedler am gleichen Logging-USB-Stick, also nur ein CSV-Import, bzw. Nutzung der gleichen sonstigen Schnittstelle am Wechselrichter (wie Modbus TCP)
  • Nachteile: (1) Warum muss die Cloud den Siedler-Eigenverbrauch kennen, der einen Fingerabdruck ihres aufregenden Lebens liefert? (2) Noch ein Kabel vom Wechselrichter zum Zählerkasten, da der Zähler ja unmittelbar hinter dem ‚offiziellen‘ montiert wird.

Glücklicherweise ist es nicht so schwierig herauszufinden, welches OEM-Gerät hinter den ‚re-brand-eten‘ Zählern steckt und so stoßen die Siedler auf diese Variante:

Ein eigenes Smart Meter mit Loggerfunktion misst – unabhängig vom Logger des Wechselrichters – direkt hinter dem dummen schlauen Siemenszähler die eingepeiste und gelieferte Energie auf den drei Phasen und speichert sie lokal in einem Logfile. Diese Datei kann über LAN oder WLAN abgeholt werden.

In der Endauswahl waren folgende Typen – alles Zweirichtungs-Drehstromzähler mit Logging und TCP/IP-Schnittstelle:

  • EM210 von TQ-Systems / B-Control: Daten im Logfile alle Minuten, Echtzeit-‚Mitschauen‘ in höherer Auflösung über eine Website, WLAN und LAN. Allerdings kein Echtzeit-Logging über Protokolle wie Modbus TCP.
  • EM300 von TQ-Systems / B-Control: Gleiches Gerät wie der EM210, aber Echtzeitlogging in konfigurierbaren und viel kleineren Abständen – über Modbus RTU, Modbus TCP. Der Webserver wird nur zur Konfiguration verwendet. Es wäre interesant, Tools wie dieses zu verwenden, aber: Damit muss beim Loggen immer ein PC mitlaufen.
  • EMU Professional mit TCP/IP-Modul: Ähnlicher Funktionsunmfang wie der EM210, aber ohne WLAN (und mit einem Firmenlogo, das die Siedler unmittelbar anspricht). Pluspunkt: die ausführliche Doku der Schnittstelle.

Nach einem langen Auswahlprozess wurde es dann der EM210. Die Siedler sind zuversichtlich, ggf. das fehlende hochaufgelöste Echtzeitlogging über die bewährte Methode ‚Live-Logging-HTTP-Parsen‘ lösen zu können. Trotz aller Begeisterung für hochauslösendes Logging sollte nicht vergessen werden, dass auch der abrechnungsrelevante Zähler einen Lastgang mit 15-Minuten-Werten speichert.

Hier ist er jetzt – mit einem entzückenden Produktnamen!! – und wartet auf seine Installation.

herzstueck-em210_______________________

Der übliche Disclaimer: Die Siedler betreiben keinen Handel mit Elektronik. Die Nennung von Produkt- und Herstellernamen stellt keine Werbung dar und soll aussschließlich anderen Siedlern Recherche-Arbeit ersparen – hier gibt es keine ’sponsored posts‘. Wir recherchieren sorgfältig, sind aber auch nur menschliche Lebensformen: Fehler nicht ausgeschlossen.