Das Farbenkastl

Es war wieder soweit.

Irgendwer hatte den großen Schalter umlegt – und endlich wurden wieder Daten geloggt. Die Datenkrake blickte jedoch vorerst auf ein Knäuel von verknoteten Tentakeln!

Wie Anno 2016 gab es einen Bruch im Raum-Zeit-Kontinuum: Irgendwessen Regelungsbastelei hatte sich der Aufbau der mittels Winsol exportierten Logdateien grundlegend geändert. Es gibt jetzt komplett neue Sensoren und erstmals geloggte Werte. Die bekannten Werte stehen in anderen Spalten im Logfile. Das Logfile hat mehr Spalten. Die Kompressorleistung wird endlich als positiver Wert gemessen. Zähler wurden genullt während des Umbaus. Mehrmals.

Glücklicherweise hatte die Datenkrake weitgehend vorgesorgt! Als sich Ende 2016 eine neue Logfilestruktur ankündigte, wurde in einem klassischen Über-die-Feiertage-Marathon-IT-Projekt die ‚Softwarearchitektur‘ geändert.

(Symbolbild.)

Seit damals gibt es als Vorgruppe zur mächtigen SQL-Server-Krake eine Access-Krake: Diese Proto-Krake enthält die Dokumentation aller Messwerte inklusive der Information, seit wann es diesen Wert bzw. diesen Sensor gibt, an welcher Stelle in der Logdatei der Messwert steht, und wann er ggf. wieder ausgeschieden wurde. Aus dieser Kraken-DNA bastelt ein Powershell-Tentakel dann die eigentlichen SQL-Server-Datenbank-Objekte. So wie Forscher eventuell einmal ein Mammut klonen werden aus Fossilien, kann die komplette Datenbank aus den alten Logfiles neu aufgebaut werden – egal wie durcheinander gewürfelt die Spalten werden.

Ebenfalls festgehalten in der DNA sind die für die eigentliche Auswertung benötigten Funktionen. Lebenssinn der Datenkrake ist ja die Zusammenführung der Logdateien diverser Logger und die Berechnung von Kennwerten, die über einfache Mittelwerte und Zählerstände etc. hinausgehen. So berechnete die Krake die Arbeitszahl der Wärmepumpe ursprünglich aus den manuell vom Display der Wärmepumpe abgelesenen Werten. Schrittweise wurden aber die verwendeten Zähler automatisiert, d.h. die Krake muss Ihre Tentakel zum richtigen Zeitpunkt in eine andere Tabelle ausstrecken. Außerdem muss immer berücksichtigt werden, dass bestimmte Mittelwerte nur Sinn machen, wenn Kritierien erfüllt sind: Die Krake berechnet zum Vergleich auch eine Arbeitszahl aus einer selbst erstellten Fitkurve für die Wärmepumpenleistung in Abhängigkeit von Quellen- und Senkentemperatur. Zu diesem Mittelwert dürfen nur Zeitinervalle beitragen, in denen die Wärmepumpe auch gelaufen ist.

Solchen Anforderungen stellen also kein Problem für die Krake dar! Die Siedler fürchten sich immer schon ein wenig davor, dass die Datenkrake tatsächlich Bewusstsein erlangt und das Leben in der Siedlerhütte zu einem Science-Fiction-Alptraum wird. Glücklicherweise schützt die Siedler hier ein ungelöstes Problem. Bis zur tiefsten Ebene des Kraken-Genmaterials ist die Automatisierung nämlich noch nicht vorgedrungen. Wie sollte das auch aussehen – eine Mini-Drohne oder ein Roboter, der versucht, Irgendwessen Sensor-Verkabelungsmutationen live mitzudokumentieren?

Hier kommt nun endlich das titelgebende Farbenkastl ins Spiel. Ja, so ist es mit den Namen strategischer wichtiger Entwicklungen: Der erste Code-Name, der in einem internen IT Strategy Meeting achtlos in dem Raum geworfen wird, bleibt für alle Ewigkeit. Überraschend war auch für die Siedler, wo dieser Name eigentlich herkommt. Umgangssprachlich steht ‚Farbenkastl‘ im Land der Siedler meist für ewas bunt Geschecktes, Geschmackloses – z.B. im Zusammenhang mit Kleidung oder Inneneinrichtung oder der politischen Parteienlandschaft. Ursprünglich wurde der Begriff offenbar verwendet, um sich über den überaus komplizierten ‚Farb-Code‘ der militärischen Uniformen zur Zeit der k.u.k Monarchie lustig zu machen.

Keine Metapher könnte passender sein für dieses imperiale Tool! Als Vorstufe zur Vorstufe der Krakendatenbank wird ein Farbenkastl erstellt … in Microsoft Excel! Nur so kann das Elkement seine kreative Ader ausleben und die diversen Kategorien von mutierenden Sensoren einmal optisch ansprechend einfärben, zwecks leichterer Erstellung des nächsten Skripterls (Skript-chens).

Das erste Farbenkastl 2016 sah noch vergleichsweise langweilig aus:

Beim Screenshot-ten des Farbenkastls Reloaded 2018 stoßen wir aber schon an die Grenzen des Zoomens in Excel!

Und nun warten wie immer in diesen Fällen auf die überraschende Nominierung für einen Kunstpreis! In der Zwischenzeit erfreuen sich die Siedler wieder an den regelmäßig vorgeführten Kunststückchen der Krake!

(Symbol-Video. An der automatischen Änderung der PVC-Verrohrung mittels Krake und 3D-Druck arbeiten wir noch!)

Krakenwanderung

Die Datenkrake ist ein nützliches Haustier in der Siedlerhütte: Sie frisst simple Textdateien – Logdateien im CSV-Format, wie sie von Winsol produziert werden – und spukt dann ihre Meinung dazu in Form von Tabellen und Bildchen aus.

Zu diesen Kunststückchen wird sie vom Krakenbändiger durch eine Reihe netter Tools motiviert:

Die Krake arbeitet genügsam im Hintergrund und erfordert wenig Aufmerksamkeit – abgesehen von extremen Ausnahmesituationen wie Firmwareupgrades, die die Logfiles-Struktur durcheinander werfen.

Ein altmodisches Biotop war lange Zeit ausreichend, und eine sehr smarte Steuerung achtete genau darauf, dass die Datenkrake nicht zuviel Energie verbrauchte:

Der Kippschalter der Krake und seine intelligente Steuerung

Der Kippschalter der Krake und seine intelligente Steuerung

Aber irgendwann wuchs der Hunger der Datenkrake und sie benötigte einfach mehr Ressourcen …

Was man in einem dünn und schwächlich anmutenden Notebook so alles findet...

Was man in einem dünn und schwächlich anmutenden Notebook so alles findet…

… und so ließ sie in ihrem neuen Biotop nieder:

Ökologisch korrektes Krakenbiotop.

Ökologisch korrektes Krakenbiotop.

Aber das Elkement packte der Ehrgeiz und ein nostaglischer Schub: die Urkrake sollte in ihrer Kippschalter-gesteuerten Heimat auch noch weiterleben dürfen. D.h. die Krake wurde trotz der ökologisch korrekt anmutendenden Züchtungsweise de facto geklont.

Hier muss nun ein Software-Tool besonders hervorgehoben werden:

Winsol: Wir wissen nicht, warum das Logo ein zerbrochenes W zeigt - funktioniert eigentlich alles super!

Wir wissen nicht, warum das Logo ein zerbrochenes W zeigt – funktioniert eigentlich alles super!

Jegliches scheinbare Product Placement in diesem Posting ist unbeabsichtigt und rein zufällig – egal ob die Logos aus Redmond oder Amaliendorf kommen.

In der grafischen Oberfläche von Winsol werden die Daten der ausgewählten (angeklickten) Siedler zum automatischen Abholen reserviert. Automatisch heißt: beim Start des PCs:

Winsol: Autostart-Einstellungen

Winsol: Autostart-Einstellungen. Geschwärzt: Die Namen jener Siedler, deren Daten man vom CMI – Control and Monitoring Interface – ‚automatisch‘ abholen möchte, zwecks weiterer Analyse durch die Datenkrake

Das automatische Abholen wird über eine Verknüpfung in folgendem Ordner durchgeführt: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

… und in den Eigenschaften der Verknüpung verbirgt sich ein Schatz!

winsol -a

Winsol: Eigenschaften der beim Setup erstellten Verknüpfung im Startup-Ordner.

Winsol: Eigenschaften der beim Setup erstellten Verknüpfung im Startup-Ordner.

Damit die Urkrake mit Kippschalter und die Turbokrake mit Touchscreen friedlich koexistieren können, sollen die Logfiles kontrolliert abgeholt werden – unmittelbar bevor die anderen Tools Powered by Microsoft & Elkement zum Einsatz kommen. Die Verknüpung wird daher aus dem Startup-Ordner verschoben und dafür winsol mit der Option -a in der  Krakenkommandozentrale ergänzt.

Zwei Kraken nutzen dann friedlich das gleiche Datenverzeichnis für Winsol, solange nicht beide gleichzeitig den Zauberspruch winsol -a aufsagen: Jede Krake befüllt das gemeinsame Verzeichnis wechselweise – die jeweils andere Krake findet dann beim nächsten Start der Krakenauswertungen oder der grafischen Oberfläche von Winsol automatisch die aktuellen Daten vor!

Diese Vorgangsweise wird möglicherweise vom Softwarehersteller nicht supported.

Was sich die Siedler noch wünschen würden, wäre ein Befehl:

winsol -a [Siedler]

… um das Aus- und Anhaken automatisieren zu können.

Die ganz Mutigen können aber auch in Winsol.xml-Datei im Benutzerprofil schreiben um die Hakerl (Häkchen) zu automatisieren – eine möglicherweise vom Softwarehersteller nicht supportede Vorgehensweise …

Winsol: Konfigurationsdatei winsol.xml im Profil des aktuellen Benutzers

Winsol: Konfigurationsdatei winsol.xml im Profil des aktuellen Benutzers: Die automatisch / per winsol -a abzuholenden Kunden werden im Autostart-Element eingetragen. (Diese XML-Datei ist zu unterscheiden von den zusätzlichen Konfig-Dateien pro CMI / pro Kunde in den jeweiligen Datenordnern).

____________________________________________________________________

Epilog: Das Elkement begab sich auf die Suche nach lehrreichen Informationen zur Wanderung echter, biologischer Kraken. Google fragte aber, ob wir nicht nach Krötenwanderung suchen wollen … aber dann finden wir die echte Krakenwanderung: Streetart aus Hamburg!

Die Datenkrake – ein Formwandler

Die Siedler sind immer wieder fasziniert von den seltsamen Lebensformen, die sich rund um die Siedlerhütte so tummeln. Auch altbekannte Spezies sind immer wieder für eine Überraschung gut!

Wie wir alle wissen, sind Kraken ja wahre Formwandler:

(…was an ihrem fehlenden Rückgrat liegt – aber soweit wollen wir diese Metapher nicht ausreizen…)

Jedenfalls zeigt auch die hauseigene Krake eine erstaunliche Wandlungsfähigkeit – ein Glück angesichts solcher Herausforderungen:

Wenn Irgendwer mit diversen anderen Lebensformen kämpft, dann vergisst er Zeit, Raum und vor allem dem Wissenschaftsoffizier zu melden, dass sich die Sensorlandschaft der Siedler über Nacht grundlegend verändert. Das Elkement steht dann vor der Herausforderung, der Krake wieder neu beizubringen, wie sie z.B. jetzt erkennen soll, ob die Wärmepumpe gerade läuft oder nicht. Soll man die Anforderung der Wärmepumpe heranziehen? Oder die Anforderung der Solepumpe? Oder doch eine Temperaturdifferenz und den Durchfluss im Solekreis?

Generell erfordert die scheinbar so volksschulmäßig simple Mittelwertbildung einiges an FingerspitzenTentakelgefühl: Abgesehen von Raum- und Außentemperatur sind die meisten Mittelwerte nur sinnvoll in Messintervallen, in denen bestimmte Bedingungen erfüllt sind. In die mittlere Vorlauftemperatur des Heizkreises sollten natürlich nur Werte einfließen, die gemessen wurden während die Heizkreispumpe läuft – andererseits müssen aber die Werte während der sommerlichen Kühlphasen ausgenommen werden. Vor allem muss die Krake lernen, welche Sensorwerte evtl. als Fehler zu werten sind!

Um das Elkement zu verwirrend, fügt Irgendwer aber nicht nur dauernd neue Sensoren hinzu, sondern ändert fieserweise auch die Rollen etablierter Sensoren. So wird schnell einmal eine neue Wandheizung eingebaut und was der (Regelungs-)Welt bisher als Radiatorheizkreis bekannt war, wird nun zu einem neuen Wandheizkreis.

Aber auch das Elkement selbst ist an der ständigen Krakenmutation nicht unschuldig: Während sich Irgendwer lange zufrieden gab mit zwei unterschiedlichen ‚Logging-Quellen‘ – der UVR1611 / UVR16x2 – und einigen manuell gemessenen Werten, hat das Elkement einen Zähler-Zoo herangezüchtet und schreckt nicht davor zurück, die Krake ihre Tentakel direkt in das Innere der Wärmepumpe vordringen zu lassen. All das erzeugt neue Logfiles mit Daten, die zu anderen Zeitpunkten in anderen Zeitintervallen gemessen werden und die von der Krake mit den UVR-Daten verknüpft werden müssen.

Datenkrake: Tentakel in der Wärmepumpe

Insbesondere die früher manuell abgelesenen Daten waren der Krake ganz besonders schwer beizubringen: Irgendwer war zwar ein verwegener Messdatenableser, weigerte sich aber beharrlich, jeden Tag exakt um 00:00:00 Energiewerte aufzunehmen. Da die dumme Wärmepumpe entweder an oder aus ist, macht eine Interpolation der Werte wenig Sinn und das Elkement musste jene erwähnten Mittelwerte für irgendwelche seltsamen Zeitintervalle berechnen.

Aber nicht nur irgendwelche Experimente fordern die Krake heraus: So mancher Hersteller von Steuerungen kommt ja hin und wieder auf die Idee, ’schnell einmal über die Feiertage‘ die Struktur der Loggingdaten mit einem Firmwareupdate durcheinanderzuwirbeln! Die Tentakel der Krake müssen dann bis zum Äußersten gedehnt werden, um die Daten wieder richtig einzusammeln.

Wie regelmäßige Leser dieses ‚Wissenschaftsblogs‘ erahnen werden, muss natürlich jeder dieser Laborversuche ausführlich dokumentiert und nachvollziehbar qualitätsgesichert werden. Gerade bei Tierversuchen gibt es ja sehr strenge Auflagen!

Nach langem Tüfteln – und dem Konsum vieler klischeehafter Filme über künstliche Intelligenz – hat das Elkement jetzt der Datenkrake ein paar weitere Metaebenen verpasst: Die DNA der Krake – also die Beschreibung der Logdateien und Sensoren, wird in einer separaten Vor-Krake abgelegt. Schonungslos wird hier jeder Messfauxpas von Irgendwem dokumentiert: So enthält die Vor-Krake eine Tabelle, in der man Zeitbereiche findet mit Kommentaren wie Irgendwie bastelt und hat versehentlich die Sicherung ausgeschaltet.

Aus der Vor-Krake entsteht dann ‚per Knopfdruck‘ die Große Krake, die automatisch Logdateien in der richtigen Reihenfolge frisst. Nach der Entschlüsselung der Kraken-DNA lässt sich diese auch klonen und frisst auch die CSV-Dateien anderer Siedler.

Nur wenn man diese Vorgeschichte kennt, kann man die kindliche Freude des Elkementes nachvollziehen, wenn die sehr schlichte Benutzeroberfläche dann das Durchklicken der wichtigen Kennwerte für LEO_2-Anlagen erlaubt – für Tage, Monate, Jahre oder Heizsaisonen.

Datenkrake: Excel-Auswertung

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

 

 

 

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.

Die Datenkrake

Es soll hier nicht um jene Amerikanischen Datenkraken gehen, die ein F oder G als Logo verwenden.

Fsa09, Datenkrake

Datenkrake als Kunstaktion (Wikimedia-User Nicor)

Nein – es ist die ganz gewöhnliche und harmlos wirkende Datenkrake wie man sie eigentlich in jeder beheizten ’smarten‘ Siedlerhütte finden kann.

Während Chefingenieur Irgendwer erfolgreich verschiedenste Würmer gebändigt hat, versuchte Wissenschaftsoffizier Elkement, die häusliche Datenkrake zu zähmen.

Bratislava Slovakia 183

Unsere Datenkrake ist harmlos und lebt harmonisch im Einklang mit Mensch und  Natur – ähnlich der auf diesem Foto dargestellten (Wikimedia-User Doko, Aufnahme aus Bratislava).

Seit dem denkwürdigen Tag der Inbetriebnahme des Wärmepumpensystems im Oktober 2012 wächst sie unaufhörlich. Viele Postings wären ohne sie nicht möglich gewesen – siehe die Liste der Artikel zu Messdaten und überblicksmäßigen Auswertungen auf unserer neuen Sitemap (…ihrerseits ein Versuch, die Datenkrake dieser Blogartikel zu bändigen).

Zu Beginn hatten die Siedler versucht, die Datenkrake mittels einer Software zu bändigen, die völlig zu Unrecht als Kuchendiagramm-Erstellprogramm für Manager verschrien ist.

Excel ist immer für Sie da!

Neue Erkenntnisse machen Ihre Daten noch wertvoller

(Quelle)

Ja, Excel war immer für uns da und machte unsere Messdatenkrake besonders wertvoll. Aber es hat uns auch verleitet, eine vielköpfige Hydra zu züchten von Formeln, Formeln die auf andere Formeln verweisen, Formeln die auf Formeln verweisen die auf Formeln verweisen.

Nicht zu vergessen: Unsere Freude an der Automatisierung mit Visual Basic for Applications – für Bastler, Tüftler und Dilettanten, bzw.

…Hauptbenutzer von Excel, die noch keine Programmierer sind

(Quelle)

Die Siedler bzw. deren Datenlogger nehmen alle drei Minuten Messwerte auf. Für spezielle Forschungen wie der Analyse des Elementaren Duschvorgangs oder der momentanen Performance der besten Solarkollektoren ist es sinnvoll, diese Daten in noch kürzeren Zeitintervallen zu messen.

Elementares Duschen

Wie oft in den Medien beschrieben liefert ein detailliertes Datenmonitoring des Energieverbrauchs einen perfekten ‚Fingerabdruck‘ des Hausbesitzer-Verhaltens. So exzessiv duscht nur ein Subversives Element (Details in diesem Posting).

Aber einen Überblick über die Leistungsfähigkeit der Anlage erhält man durch die Ermittlung von Kennzahlen für sinnvolle Perioden – wie Monate, Kalenderjahre oder Heizperioden.

So lernte Elkement die Datenkrake mittels automatisch angewandtem Excel-Autofilter auszuwerten. Diese Forschung förderte auch erstaunliche Eigenschaften der Datenkrake zu Tage – wie einen ca. 99%iger Performancegewinn wenn man sich dazu entschließt alle Formatierungen im Rohmessdatenblatt zu löschen.

Aber einige 100 Megabyte später wurde es langsam lästig, diese riesige Krake in ihrem Bau – neuerdings Cloud genannt – artgerecht zu halten.

So begann das Elkement eine Odyssee der Datenanayse und Aufzwirbelung der fraktalen Formelstruktur und folgte dabei seinem geheimen Motto: Das ganze Leben muss sich in einer simplen Textdatei beschreiben lassen. Für den Lebenszyklus der Krake konnte das jetzt realisiert werden: Die virtuelle Krake kann jederzeit neu zum Leben erweckt werden – aus den Originalmessdaten (CSV), die die Logger CMI oder BL-NET liefern. Ein Script – also ebenfalls eine Textdatei – baut daraus eine richtige Datenbank auf.

SQL scripts

Ein für uns ungelöstes Problem des populären Technologie-Journalismus: Wie stellt man Programmcode ansprechend dar? Wir entscheiden uns für den üblichen mysteriösen Matrix-Ansatz. „Das ist der genetische Code der Krake – diese kann damit jederzeit neu geklont werden!“.

Das liebgewonnene Bildchen-Erstellungs-Programm wird weiterhin verwendet – als ‚Frontend‘ für diese Lösung.

Wäre das ein abstraktes akademisches Projekt – dann wäre das einfach gewesen. Aber eine echte lebendige, organisch gewachsene Datenkrake folgt keiner Best-Practice-Datenstruktur. Sensoren messen nicht immer was man möchte, und leider haben wir nur bedingt Gewalt über die nicht immer fehlerfreie künstliche und natürliche Intelligenz sämtlicher beteiligter Lebensformen.

Ja – das ist ein Bug! Da muss eine neue Firmware eingespielt werden!

(Quelle wird aus Diskretionsgründen nicht genannt.)

So muss jedes Datententakel in liebevoller Handarbeit nachgebildet werden, und die Textdatei des Lebens enthält eine Geschichte bizarrer Anweisungen im Stil von:

Wenn Datum zwischen X und Y, dann ist jenes Tentakel doch etwas röter …. äh… ist die Soleeintrittstemperatur um Z°C zu korrigieren.

Wie auch immer: So wie die diversen Ripplinge letzendlich von Irgendwem gebändigt wurden, konnte auch as Elkement der Datenhydra alle hässlichen Köpfe abschlagen – so dass die verbleibende Datenkrake handzahm wurde und uns gute Dienste leistet.

Oder?

Standard Oil Octopus

Ein böser, fossil betriebener ‚Standard Oil Octopus‘. Eventuell sollten gerade wir die Krakenmetapher doch überdenken?