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 🙂

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!

Unpannonische Heizsaison 2016-2017

Die Siedler hatten den Bogen endgültig überspannt. Jahrelang wurde hier berichtet über Winter, die zu pannonisch waren oder nicht kanadisch genug waren. Irgendwie war das auch ein Ausdruck ihrer Frustration: Man musste zu drastischen Maßnahmen greifen, um einen echten Winter zu simulieren und endlich einen ordentlichen Eiswürfel zu erzeugen.

Und so haben die Siedler sie heraufbeschworen – die Heizsaison 2016 / 2017 mit dem kältesten Jänner (Januar) seit 30 Jahren. So sieht die Bilanz aus:

Der positive Rekord: 14m3 Eis ganz ohne Trickersei! Und das, obwohl das Obergeschoß wieder mit dem Holzofen beheizt wurde:

(Zu der eigenartigen ‚Schwingung auf dem Eisplateau‘ siehe die Geschichten von Blubber und Orkrakel.)

Die lange Periode von mittleren Außentemperaturen unter Null, ganz ohne Warmlufteinbruch lässt aber Schlimmes erahnen: Ein trauriger Rekord wurde erreicht – der grüne Balken der Monatsarbeitszahl hält sich im Jänner 2017 doch deutlich fern von der 4er-Marke:

In diesem Monat wurden über 3.000 kWh Heizenergie benötigt; im ganzen Jahr wurden ca. 16.600 kWh verbraucht inkl. Warmwasser – gleich wie wie in der vorigen Saison, in der die ganze Siedlerhütte mit der Wärmepumpe beheizt wurde. Zu beachten: Trotz heroischer punktueller Renovierungsmaßnahmen wird der Großteil der Heizenergie im Untergeschoß noch über Radiatoren verteilt – im Januar bei einer mittleren Heizkreis-Vorlauftemperatur von 37°C.

Der Kollektor konnte in diesen Wochen vergleichsweise wenig Energie liefern, während die fleißige Wärmepumpe täglich ca. 100 kWh Heizenergie ‚produzierte‘:

Damit konnte der Kollektor heuer auch seine übliche Kennzahl nicht ganz erreichen: Wie die Siedler und ihre Krake nicht müde werden zu betonen, liefert er ‚üblicherweise‘ in einer ‚typischen‘ Eisperiode über 75% der Umweltenergie für die Wärmepumpe.

In der letzten Saison folgte aber der kalte Rekord-Jänner auf einen ebenfalls schon kollektorunfreundlichen Dezember. Die Auftauphase im Februar folgt dann wieder dem üblichen Rekordernte-Muster.

Zu beachten ist aber, dass der Kollektor auch in dieser Saison wieder nur zu 50% genutzt wurde. Irgendwer wollte ja seine Forschungsschaltung ordentlich testen: Seit Herbst 2014 musste sich die Wärmepumpe mit 12 statt 24m2 Kollektorfläche begnügen – eine Fläche, die die Siedler angesichts des typischen Energiebedarfs ihrer historischen Siedlerhütte eigentlich als zu gering betrachten.

Etwas getröstet wurden die Siedler allerdings dann im heißen Sommer 2017 – durch Spielereien mit der passiven Kühlung. Sie konnten sich den Eiswürfel für Kühlzwecke zwar nicht lange aufheben, aber in diesem (Hitze-)Rekord-Sommer wurde die bis jetzt höchste Kühlenergie von insgesamt ca. 600kWh benötigt.

Der Kollektor kühlt in vergleichsweise kühlen Nächten den Eisspeichertank; der kalte Tank kühlt wiederum den Pufferspeicher – pro Tag werden von den ‚Heiz‘-Kreisen bis zu 30kWh Kühlenergie entnommen.

Nach dem Bericht über die Herausforderungen und das schwierige Umfeld kommt normalerweise der optimistische Blick in die Zukunft. Chief Engineer Somebody enthüllt die strategische hydraulische Weichenstellung für die eben gestartete Saison: Die zweite Hälfte des Kollektors wurde wieder zugeschaltet!

____________________________________

Die Messdaten aller Jahre und weitere Details und technische Daten zum System sind wie immer zu finden in unserer Messdatendokumentation (PDF)

Der Blubber: An der Klippe …

Irgendwer hätte dem beruhigenden Blubbern noch stundenlang zuhören können. Aber leider war das Messintervall für den Füllstand schon wieder vorüber und der Blubber verstummte unvermittelt. So schloss er den Eisspeicher-Deckel, und zog zufrieden Bilanz über die Feuerprobe des Blubbers (… die ja – genau genommen – eine ‚Eisprobe‘ gewesen war).

Blubber-1-Wasser

(1) Nur Wasser, kein Eis (mehr) im Eisspeicher

Der kälteste Pannonische Jänner seit 30 Jahren hatte für genügend Eis im Eisspeicher und damit für optimale Blubber-Testbedingungen gesorgt. Trotz dieser harschen Umgebungsbedingungen hatte der Blubber verlässlich seinen Dienst getan und den Füllstand kontinuierlich aufgezeichnet.

Blubber-Fuellstand

Obwohl dieser Blubber-Füllstand natürlich unmittelbar mit der Eisbildung zusammen hing, zeigte er trotzdem einen Verlauf, der auf den ersten Blick vielleicht etwas unlogisch erscheinen konnte. Besonders die starken Schwankungen in der Auftauphase (3) und der ’negative‘ Füllstand gegen Ende der Eisperiode (4)…

Eine direkt Umrechnung des Füllstandes in Eisvolumen war nur unter bestimmten Bedingungen möglich. Dazu musste man sich erst einmal vergegenwärtigen, was sich so im Laufe eines Winters im Eisspeicher abspielte:

Blubber-Phasen-der-Eisbildung

Schematische Darstellung der Eisphasen: (1) nur Wasser (2) kontinuierlicher Eiszuwachs um die Wärmetauscherrohre und an der Oberfläche (3) (temporärer) Eisrückgang und Wiederanstieg (4) Endphase der Eisschmelze: der Eisdeckel schmilzt zuletzt.

In der Phase der kontinuierlichen Eisbildung (2) entsteht Eis um die Wärmetauscherrohre und an der Wasseroberfläche. Da das Wasser durch das wachsende und an der Trägerkonstruktion festgefrorene Eis an die Oberfläche verdrängt wird, ist das gesamte Eisvolumen unter Wasser. – Der Füllstand kann direkt in Eisvolumen umgerechnet werden.

Blubber-2-Wasser-Ueber-Eis

(2) In der Phase der kontinuierlichen Eisbildung befindet sich das gesamte Eisvolumen unter Wasser

Sobald die erste Tauwetterphase einsetzt (3), schmilzt Eis zuerst an den Wärmetauscher-Rohren. Der Wasserstand sinkt und das nach wie vor an der Trägerkonstruktion festgefrorene Eisgebilde erhebt sich wie eine Klippe über das Wasser. Da ein Großteil der Oberfläche gefroren ist, sinkt der Wasserspiegel in den eisfreien Zonen überproportional stark.

In dieser Phase wird das direkt aus dem Füllstand ermittelte Eisvolumen unterschätzt. Dafür sind kleinste Änderungen im Eisvolumen durch starke Schwankungen des Füllstandes in relativ kleinen eisfreien Zonen sehr genau messbar.

Gefrier- und Tauphasen wechseln sich quasi wie Flut und Ebbe zwischen den Klippen ab.

Blubber-3-Klippe

(3) In Tauwetterphasen sinkt der Wasserspiegel in den eisfreien Zonen überproportional schnell und Eisklippen erheben sich über das Wasser

Gegen Ende der Eisperiode (4) sinkt der Wasserspiegel sogar kurzfristig unter den ursprünglichen Stand. Während das Eis um die Wärmetauscherrohre bereits vollständig geschmolzen ist, schmilzt der ‚Eisdeckel‘ mangels direkter Wärmezufuhr (fehlender Kontakt zu Wärmetauscherschläuchen und  zum Wasser) zuletzt.

Blubber-4-Eisscholle

(4) Am Ende der Eisperiode hängt der ‚Eisdeckel‘ in der Luft und schmilzt zuletzt.

Fortsetzung: Orkrakel und Peak Ice

Erde, Luft, Wasser und Eis – wozu das alles?

Jahrelang kämpften die Siedler mit der einen großen Herausforderung des Eisspeicher-Journalismus. Wie stellt man am besten dar, wie das Zusammenspiel von Kollektor und Eisspeicher funktioniert? Wie beantwortet man solche Fragen:

Was bringt der Kollektor eigentlich?

oder

Wozu braucht man den Kollektor überhaupt, wenn die Arbeitszahl während einer Eisspeicher-Challenge ohne Kollektor eh nicht so stark absinkt?

und vor allem

Wie groß ist eigentlich der Beitrag der Erde?

Kann hier die Datenkrake helfen, besser darzustellen, was im Lauf einer Heizsaison passiert?

Aus dem Eisvolumen und der aktuellen Tanktemperatur wird der Energievorrat im Tank berechnet. Die Energie im Tank ändert sich vor allem dadurch …

  1. dass aus dem Tank laufend Energie durch den Wärmetauscher entnommen (Wärmepumpenbetrieb) oder zugeführt (Kollektor) wird.
  2. und dass über die Wand und den Boden des Tanks Wärme mit der Umgebung ausgetauscht wird.

Der Beitrag der Erde kann aus Eisvolumen, Tanktemperatur und der gemessenen Wärmetauscher-Energie berechnet werden. Ergo:

Vorratsänderung (Eis, Wasser) = Energie Tankwärmetauscher + Energie Erde

In stundenlangen Sitzungen von Forschungs- und Ingenieursabteilungen wurden dabei folgende Definitionen für die Vorzeichen dieser Beiträge festgelegt:

Energiequellen, -austausch, -vorrat - Vorzeichenfestlegungen

Wenn der Kollektor aktiv ist, sind drei Wärmetauscher in Serie geschaltet: Der Kollektor, der Wärmetauscher im Tank und der Verdampfer der Wärmepumpe. Die Wärmepumpe entnimmt ihre Entzugsenergie entweder nur aus dem Eisspeicher (wenn der Kollektor weggeschaltet ist) oder aus der kombinierten Quelle gebildet aus Kollektor und Tank.

In den folgenden Diagrammen für die ‚Eisspeicher-Challenge-Saison‘ 2014-2015 werden Entzugsenergie, Kollektorernte, Energiefluss über den Tank-Wärmetauscher, Beitrag der Erde und die Änderung des Eis-/Wasser-Energievorrats gegenübergestellt.

Saison 2014-2015: Monatsbilanzen: Energiequellen, -austausch, -vorrat

Von September bis Jänner steigt die benötigte Entzugsenergie – aber auch der Kollektorbeitrag! Je länger die Wärmepumpe gleichzeitig mit dem Kollektor läuft und je kälter der Tank im Vergleich zur Luft ist, umso mehr Energie kann geerntet werden. In einer typischen Saison deckt der Kollektor in den Eismonaten Dez / Jan / Feb ca. 75% der benötigten Entzugsenergie ab – aber nur in Zusammenspiel mit dem Eisspeicher!

Am Anfang der Saison 2014/15 – solange sich noch kein Eis gebildet hat – folgen die Tanktemperatur und die Soleeintrittstemperatur ungefähr der Außentemperatur. Ende November ist die Außentemperatur aber schnell gesunken – damit kann über den Kollektor aus der vergleichsweise kalten Luft wenig in den noch warmen Tank geerntet werden. Daher wird der Eis-Wasser-Vorrat angezapft und die Erde beginnt zu liefern.

2014-09-01 - 2015-05-15: Temperaturen und Eisbildung

2014-09-01 - 2015-05-15: Tagesbilanzen: Energiequellen, -austausch, -vorrat Am 10.1.2015 konnte dank des Wintersturms Felix extrem viel Kollektorenergie geerntet werden.

Erst nach Abschalten des Kollektors mit Anfang Februar (‚Eisspeicher-Challenge‚), ändert sich der Vorrat beim Vereisen deutlich.

Da der Kollektorbeitrag im Februar gleich Null ist, entspricht der Energieaustausch über den Tank-Wärmetauscher genau der Entzugsenergie. Die Erde liefert dann ca. ein Drittel der Entzugsenergie.

Mitte März startet der Auftauvorgang: Der Kollektor kann aufgrund der konstant auf 0°C bleibenden Tanktemperatur viel ernten und der Tankvorrat wird schlagartig wieder aufgepumpt. Der Energieaustausch mit der Erde ist sehr klein, während der Wärmefluss über den Tankwärmetauscher fast gleich der Vorratsänderung ist.

Anfang Mai startet der Sommerbetrieb: der Kollektor ist aus, um den Tank solange wie möglich auf 8°C zu halten – was zu einem kleinen Wärmefluss der schon warmen Erde in den Tank führt.

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

Endlich! Der Blubber.

Der metrische Sensor zur visuellen Erfassung des Füllstandes im Eisspeicher von LEO_2 war eine Innovation der ersten Stunde gewesen. – Einfach, robust, verlässlich und unschlagbar günstig!

blubber-metrischer-fuellstandsmesser

Der Klassiker unter den Füllstandsmessern …

Er hatte nur einen entscheidenden Nachteil: Das technische Personal – also Irgendwer – musste zur Erfassung des Füllstandes direkt vor Ort sein – also am Einstieg zum Eisspeicher. Und das natürlich genau zu jenen Zeiten, zu denen sich Eis im Eisspeicher bildete.

Über die nun doch schon einige Jahre dauernde Beobachtungsphase hatte sich inzwischen herausgestellt, dass die Phasen mit Eisbildung ziemlich gut mit widrigen äußeren Wetterbedingungen im Zusammenhang standen. Das wiederum bedeutete, dass Irgendwer regelmäßig seinen Hintern aus der warmen Stube in die unwirtliche Kälte des pannonischen Winters hinausbewegen musste, um diesen entscheidenden Messpunkt einzusammeln.

Und so, wie immer Mangel und Not die besten Innovationen hervorbringen, war es auch diesmal. Es war allerdings ein langer und steiniger Weg gewesen, bis Irgendwessen Forschungen im Bereich der Füllstandsmessung die gewünschten Ergebnisse gezeitigt hatten.

blubber-vorgaenger

Die Entwicklung der Füllstandsmessung hatte einige Prototypen hervorgebracht, bevor mit dem Blubber der Schritt von der diskreten Niveau-Überwachung zur kontinuierlichen Messung des Wasserstands im Eisspeicher gelungen war.

Wollte Irgendwer doch die Änderung des Wasserspiegels mit einer Auflösung von 1 mm messen, was einer Änderung des Eisvolumens von ca. 0,15 m3 entsprach. Und das in einem Eisspeicher, in dem man darauf achten musste, dass die Füllstandsmessung nicht einfror oder durch Eis verfälscht wurde. Außerdem wollte er diesen Sensor natürlich an seine Universalregelung anschließen, um den kontinuierlichen Verlauf des Füllstandes zu erfassen und bei Bedarf auch (regeltechnisch) darauf reagieren zu können.

Und so war er nach langem Tüfteln schließlich auf den ‚Blubber‘ gekommen, wie er ihn liebevoll nannte. Mit einer Belüftungspumpe, wie sie auch gerne für Teiche oder Aquarien verwendet wird, blies er Luft über ein Messrohr in den Eisspeicher ein. Wie der Physiker weiß, steigt der dafür notwendige Druck linear mit der Höhe des Wasserspiegels.

blubber-messrohr-3

Der ‚Blubber‘ in Aktion …

Für die Messung, und Aufzeichnung dieses Drucksignals sowie für die Umsetzung von ‚Druck‘ in ‚Wasserstand‘ und ‚Eisvolumen‘, fand er alle notwendigen Funktionen in seinem neuen Spielzeug, der UVR16x2, sodass er schließlich Wasserstand und Eisvolumen brandaktuell im Onlineschema darstellen konnte.

blubber-onlineschema

Der relative Wasserstand zum Soll-Füllstand (h.rel) und das Eisvolumen (V.Eis) waren dank ‚Blubber‘ nun aktuell im Online-Schema ablesbar …

Wenn es draußen stürmt und schneit, bin ich zum Messen stets bereit!‚ dachte sich Irgendwer, der damit – nachdem das El(k)ement die Wärmepumpe gehackt hatte – nun auch den letzten Messpunkt in die automatische Datenerfassung integriert hatte.

Und ganz nebenbei glaubte irgendwer, mit dem ‚Blubber‘ auch das Problem der potentiellen Sensor-Vereisung gelöst zu haben. Die Nagelprobe stand mit der beginnenden ‚Eisperiode‘ unmittelbar bevor…

____________________________________________

Fortsetzung – der Bericht nach dem Ende der Eisperiode: Der Blubber: An der Klippe