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.

Wärmepumpen-Forensik – Teil 2: Mitloggen der Heizenergiewerte

Nachdem sich der neue CAN-Bus-Sniffer warmgeschnüffelt hatte mit nicht sehr spannenden Testwerten, wurde es Zeit für den Einsatz im Feld.

Der Raspberry Pi erhielt zunächst einmal einen würdigen Platz, um sich Überblick über den Heizraum zu verschaffen …

Raspberry Pi hat Alles im Blick

Eine typische provisorische Teststellung. Die einzige Stelle, an der am Beginn der Tests das WLAN-Signal halbwegs OK war. Ein ausgekreuztes Ethernet-Kabel gibt’s außerdem auch noch!

Das CAN-Bus-Kabel wurde entsprechend der Bedienungsanleitung an die Wärmepumpe angeklemmt:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, Abschnitt Kleinspannung

Abschnitt 12.2.3 – Kleinspannung, Bus-Leitung. Die optionale zusätzliche Stromversorgung („+“) wurde nicht verwendet.

Wie beim Testen mit UVR1611 wurde der ebenfalls kurze CAN-Bus nicht speziell terminiert:

Bedienungsanleitung Stiebel-Eltron WPF 7 basic, CAN-Bus angeschlossen

Stiebel-Eltron WPF 7 basic mit offenem Gehäuse – High (rot), Low (blau) und Ground (gelb) sind angeschlossen.

Damit konnten die elkementaren Tests beginnen …

Der beste Arbeitsplatz

(Für eine mögliche Einreichung bei Wettbewerben wie ‚Great place to work…‘)

… und die CAN-Schnittstelle wurde aktiviert, entsprechend der Anleitung von messpunkt.org mit einer Bitrate von 20kbit/s:

sudo ip link set can0 type can bitrate 20000
sudo ifconfig can0 up

Ohne aktive Kommunikation sind auf dem Bus mit Wireshark dann nur alle paar Minuten zwei Pakete zu sehen – die Wärmepumpe will also gefragt werden.

Besten Dank wieder an juerg5524.ch für die Bereitstellung von CAN-Tools und der Elster-Tabellen, die die diversen interessanten Parameter / ‚Indizes‘ enthalten!

Wir verschaffen uns zuerst einen Überblick darüber, welche CAN-IDs die Wärmepumpe überhaupt verwendet. Eine CAN-ID repräsentiert ein Set von Eigenschaften wie z.B. Ausgänge und kann auch Informationen über die Knoten-ID am CAN-Bus enthalten (Zu CAN-Grundlagen siehe z.B. dieses Dokument.)

Wird der CAN-Bus angefragt mit einer Sender-ID von 680 (siehe ) …

./can_scan can0 680

… erhält man folgende IDs …

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

scan on CAN-id: 680
list of valid can id's:

  000 (8000 = 325-07)
  180 (8000 = 325-07)
  301 (8000 = 325-07)
  480 (8000 = 325-07)
  601 (8000 = 325-07)

Fragt man gezielt nach jeder dieser IDs …

./can_scan can0 680 180

… sieht man die Liste der Elster-Indizes mit selbst erklärenden Namen der einzelnen Parameter. Die Siedler finden die interessanten (Logging-würdigen) Parameter alle ‚unter‘ der CAN-ID 180 – hier ein Auszug aus dem Output:

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

0001:  0000  (FEHLERMELDUNG  0)
0003:  019a  (SPEICHERSOLLTEMP  41.0)
0005:  00f0  (RAUMSOLLTEMP_I  24.0)
0006:  00c8  (RAUMSOLLTEMP_II  20.0)
0007:  00c8  (RAUMSOLLTEMP_III  20.0)
0008:  00a0  (RAUMSOLLTEMP_NACHT  16.0)
0009:  3a0e  (UHRZEIT  14:58)
000a:  1208  (DATUM  18.08.)
000c:  00e9  (AUSSENTEMP  23.3) 
000d:  ffe6  (SAMMLERISTTEMP  -2.6)
000e:  fe70  (SPEICHERISTTEMP  -40.0)
0010:  0050  (GERAETEKONFIGURATION  80)
0013:  01e0  (EINSTELL_SPEICHERSOLLTEMP  48.0)
0016:  0140  (RUECKLAUFISTTEMP  32.0) 
...
01d4:  00e2  (QUELLE_IST  22.6) 
...
092a:  030d  (WAERMEERTRAG_WW_TAG_WH  781)
092b:  0000  (WAERMEERTRAG_WW_TAG_KWH  0)
092c:  0155  (WAERMEERTRAG_WW_SUM_KWH  341)
092d:  001a  (WAERMEERTRAG_WW_SUM_MWH  26)
...
092e:  02db  (WAERMEERTRAG_HEIZ_TAG_WH  731)
092f:  0006  (WAERMEERTRAG_HEIZ_TAG_KWH  6)
0930:  0073  (WAERMEERTRAG_HEIZ_SUM_KWH  115)
0931:  0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39)

Um z.B. den Stand der Raumheizungsenergie in MWh abzufragen, sendet man …

./can_scan can0 680 180.0931

… und der Output enthält gleich die Summe der MWh- und kWh- Angaben (Indices 0930, 0931):

elster-kromschroeder can-bus address scanner and test utility
copyright (c) 2014 Jürg Müller, CH-5524

value: 0027  (WAERMEERTRAG_HEIZ_SUM_MWH  39.115)

Beim Mitschnüffeln mit Wireshark sieht man die beiden Abfagen (Sender-ID 680) und Rückgabe der beiden Werte:

Mitsniffen am CAN-Bus: Wärmepumpe, Abfrage Heizenergie

Netzwerk-Pakete am CAN-Bus: Abfrage der Elster-Indices 0930 (kWh Heizenergie) und 0931 (MWh Heizenergie) mit can_scan. Die Bedeutung der einzelnen Bits wird im Englischen elkementaren Artikel zu diesem Thema beschrieben.

Um das Monitoring dieser Werte zu automatisieren, wird can_scan alle paar Minuten für die interessanten Parameter ausgeführt und der Zahlenwert aus dem Output in eine CSV-Datei geschrieben. Eine andere Option wäre, nur die Abfrage mit can_scan zu starten und den Output dann mit can_logger einzusammeln.

Die CSV-Datei wird dann per FTP an den Server geschickt, der als Datenkrake sämtliche Logfiles aus unterschiedlichen Quellen (UVR1611 / 16×2, PV-Wechselrichter, Smart Meter) zusammenfasst.

Das komplette Skript – wie auch noch etwas mehr Details zur CAN-Forschung – findet man wie immer auf dem elkementaren Blog.

Natürlich muss der neue Logger auch das Professionalitäts-Level des UVR16x2 einhalten, was die Montage betrifft: Deshalb sind im Routinebetrieb nun beide friedlich auf ihrem Holzbrettchen vereint zu finden (und nach einer Restrukturierung der Netzwerk-Architektur gibt es im Heizraum auch verlässliches LAN und WLAN):

Raspberry Pi mit PiCAN-Board von SK Pang, neben UVR16x2

Raspberry Pi mit PiCAN-Board von SK Pang neben UVR16x2 auf ökologischem Brettchen.

Wie der aufmerksame Leser sieht, wurde auch das CAN-Board getauscht – eine serielle Schnittstelle eröffnet Perspektiven für zukünftige Forschungsprojekte. Danke an SK Pang für ein eigentlich gar nicht mehr verfügbares Board!!

Die UVR16x2. Und ihr soziales Umfeld.

Kaum zu glauben. Es ist jetzt auch schon wieder fast 2 Jahre her, seit die UVR16x2 der Technischen Alternative das Licht der Welt erblickt hatte und in seiner Urversion ausgeliefert worden war.

Auch wenn Irgendwer gewusst hatte, dass die ’neue UVR‘ zu diesem Zeitpunkt noch nicht ‚ganz fertig‘ gewesen war, hatten sich doch der Spieltrieb und der Forscherdrang hinterlistig gegen die Vernunft verbündet und nach einem kurzen Widerstreit die Oberhand gewonnen. Sodass die UVR16x2 bald darauf im Maschinenraum der Siedler – so wie ihre älteren Schwester UVR1611 – einen festen Platz auf einem hübschen Holzbrettchen gefunden hatte…

UVR16x2-am Brettchen

Die UVR16x2 am rechten Brettchen und ihre ältere Schwester die UVR1611 (links).

Irgendwen hatte von Beginn an die konsequente Philosophie der TA begeistert, die sich im herben Charm des Designs, der lieb gewonnenen Logik der Bedienoberfläche und der klassischen Stift-Bedienung des Touch Screens widerspiegelte. Er war fast enttäuscht, als er das erste Mal den Regler-Teil aus seinem Sockel zog und sich dieser problemlos(!) ohne minutenlangem Rütteln und Zerren (wie bei der 1611) entfernen ließ.

UVR16x2-Aus-dem-Gehäuse-nehmen

Unglaublich! Ohne Spezialwerkzeug mit bloßen Händen ließ sich die UVR16x2 vom Sockel abziehen und aus dem Gehäuse nehmen …

Ja, in einer modernen Welt muss man auch lernen, sich von lieb gewonnenen Gewohnheiten zu verabschieden. 😉

Am Anfang war die UVR16x2 – was will man von einem Teenager erwarten – noch etwas unreif und bockig gewesen. Und die Kommunikation mit ihrem sozialen Umfeld, wie etwa dem CMI, hatte sie konsequent verweigert. Daher konnte sie von Irgendwem nur mit unkritischen Mess- und Regelungsaufgaben betraut werden und war lange Zeit zu einem Schattendasein verurteilt.

Aber glücklicherweise war sie – ebenso wie ihr soziales Umfeld – lernfähig. Eine Reihe von ‚Firmware- und Software-Upgrades‘ waren notwendig, bis sie alle sozialen Umgangsformen beherrschte, die für die Steuerung von LEO_2 unverzichtbar waren:

TAPPS2

Das begann mit der Programmierung der UVR16x2 in TAPPS2. Es gab eine Reihe überarbeiteter und neuer, interessanter Funktionsbausteine, wie z.B. eine ‚Kennlinienfunktion‘ oder das unscheinbare ‚Sample&Hold‘, die sich beide für die Forschung der Siedler noch als echte Bereicherung herausstellen sollten. Aber es war vor allem die von der UVR1611 bekannte Konfiguration des Datenloggings, die Irgendwer für die UVR16x2 am Anfang vergeblich in TAPPS2  gesucht hatte.

Aber nachdem sich Irgendwer etwas in Geduld geübt hatte, war er für das anfängliche Fehlen inzwischen mit deutlich umfangreicheren Konfigurationsmöglichkeiten für das Datenlogging entschädigt worden. Viele Funktionsparameter waren nun als ‚Ausgangsvariable‘ der jeweiligen Funktionsbausteine und damit für das Logging verfügbar geworden.

UVR16x2-Datenlogging

Die ‚Ausgangsvariablen‘ und damit die verfügbaren Parameter für das Datenlogging waren für die UVR16x2 deutlich umfangreicher geworden. Die besten Voraussetzungen um die Anlage eingehend zu analysieren …

C.M.I.

Abgeschnitten vom CMI (und damit vom Internet) hatte die UVR16x2 auf ihrem Holzbrettchen lange Zeit ein einsames Dasein fristen müssen, hätte sie nicht Irgendwer zu regelmäßigen Firmware-Updates besucht. Diese mussten – wie in alten Zeiten – auf einer SD-Karte zwischen PC und UVR hin und her transportiert werden.

UVR16x2-SD-Karte

Firmware-Update mittels altertümlichem Datentransport …

Aber inzwischen hatte auch die Kommunikation mit dem CMI ein Niveau erreicht, das (fast) keine Wünsche mehr offen ließ: Irgendwer musste seine Kommandozentrale nicht mehr verlassen, um die UVR16x2 zu bedienen …

UVR16x2-CMI-Fernbedienung

Über das CMI -Webinterface ließ sich die UVR16x2 vollständig fernbedienen.

oder Updates von Firmware und Funktionsdaten einzuspielen …

UVR16x2-CMI-Datenverwaltung

In der ‚Datenverwaltung‘ des CMI-Webinterfaces war es nun möglich, Updates für Firmware und Funktionsdaten mittels ‚Drag & Drop‘ auf die UVR16x2 zu übertragen.

TA-Designer

Kein LEO_2 ohne Online-Schema. Aber auch die Erstellung eines solchen war zu den Anfängen von der UVR16x2 noch nicht möglich gewesen.

Aber die Zeit heilt ja bekanntlich alle Wunden. Inzwischen verstand der TA-Designer auch die Funktionsdaten der UVR16x2, womit Irgendwessen Anforderungen an die Gestaltung eines vernünftiges Onlineschemas mehr als erfüllt wurden.

UVR16x2-TA-Designer

Umfangreiche Möglichkeiten bei der Gestaltung eines Online-Schemas im TA-Designer.

Und ein kleines aber wichtiges Detail gefiel Irgendwem beim TA-Designer besonders gut: Er war sehr häufig ‚Erfolgreich‘!

UVR16x2-Erfolgreich

Wärmepumpen-Forensik – Teil 1: Mithorchen am Test-CAN-Bus

In grauer Vorzeit war die Aufnahme von Messdaten eine Herausforderung, die an physische und psychische Grenzen ging:

White-Out

White-Out im Winter 2012/13. Bodentemperaturen mussten trotzdem Irgendwer messen!

Wurzelsepp misst

Warten auf das Temperaturgleichgewicht…

Mittlerweile werden fast alle Messdaten automatisch aufgenommen:

Online-Schema CMI/UVR1611/UVR16x2

Online-Schema CMI/UVR1611/UVR16x2 mit den für die Steuerung nötigen Temperatur- und Durchflusssensoren und einigen weiteren Sensoren für ‚Forschungszwecke‘ (Bodentemperatur, Strahlung)

Aber ein wesentlich Sensor hatte sich der Automatisierungswut der Siedler bis jetzt widersetzt: Die offizielle Arbeitszahl in der Messdaten-Dokumentation wird berechnet aus der Wärmeenergie, die Irgendwer tagaus, tagein am Display der Wärmepumpe abliest.

Die Siedler-Wärmepumpe ist zwar ‚absichtlich dumm gewählt‚ – aber vielleicht gibt es ja doch smarte Ansätze? Im Handbuch der Stiebel-Eltron WPF 7 basic werden sie fündig: Im Abschnitt Kleinspannung, BUS-Leitung werden die Anschlüsse CAN-Bus für Fernbedienung angeführt – vielleicht könnte man ja hier die Ergebnisse der bisherigen CAN-Bus-Forschung nutzen? Und vielleicht sogar den derzeit nicht produktiven Raspberry Pi verwenden?

Wie praktisch immer, wenn man glaubt ein Pionier zu sein, findet man im Internet bereits Anleitungen und Tools. Besten Dank an die Stiebel-Eltron-Raspberry-Pi-CAN-Bus-Hacker von messpunkt.org und juerg5524.ch!

CAN-Erweiterungsboard für Raspberry Pi

Erste Herausforderung: Unser Pi ist das ältere ‚Modell B‘. Im Gegensatz zum Nachfolgermodell B+ hatte dieser Pi nur 26 GPIO-Pins für Steuerungszwecke anstatt 40. Die PIN-Belegung hat sich zwar nicht geändert, aber neuere CAN-Boards für 40 Pins passen nicht auf den alten Pi. Der versierte Bastler wird aber auf ebay fündig und freut sich über dieses kleine Board passend für 26 Pins.

Damit ist die CAN-Schnüffel-Hardware einsatzbereit:

Raspberry Pi mit CAN-Board

Raspberry Pi mit aufgestecktem CAN-Board und verdrahtetem CAN-Kabel (grau). Blaues Kabel: Ethernet, schwarzes Kabel: Stromversorgung.

Um nicht gleich die Energieversorgung der Siedlerhütte lahm zu legen und Software zu testen, schnüffeln wir zuerst in einer…

Testumgebung: UVR1611 mit Logger BL-NET

Der Pi-Schnüffler wird daher an einen Test-Bus angeschlossen der aus den folgenden altbekannten Geräten besteht:

  • UVR1611-Steuerung mit einem angeschlossenen Temperatursensor
  • Datenlogger BL-NET, per ausgekreuztem Ethernet-Kabel mit einem Test-PC verbunden, auf dem Winsol läuft. Daten werden jede Minute geloggt. (Überblick zu Logging mit UVR1611 und BL-NET).

Eigentlich müsste jeder CAN-Bus an beiden Enden terminiert werden. Da dieser Test-CAN-Bus wie auch der Wärmepumpen-CAN-Bus nur sehr kurze Kabel verwenden und sie keine negativen Erfahrungen gemacht hatten mit kurzen falsch terminierten Bussen, verzichten die Siedler auf eine korrekte Terminierung.

Test Can-Bus: UVR1611 und BL-NET

Test Can-Bus: UVR1611 (Mitte) mit einem Pt1000-Temperatursensor (Metallhülse, schwarzes Kabel) und Datenlogger BL-NET (oben, weiß). Das CAN-Kabel (grau) verbindet 1) UVR1611, 2) BL-NET (blauer Stecker) und Raspberry Pi (nicht im Bild). Am LAN-Kabel (gelb) ist ein PC mit Winsol angeschlossen.

Software und Konfiguration

Zuerst wird der Kernel des Raspberry Pi auf eine Version upgedated, die die CAN-Schnittstelle unterstützt. Für Details siehe z.B. diesen Blog-Artikel (Abschnitt Software Installation).

In der Raspberry-Pi-Konfiguration muss der für CAN benötigte SPI-Bus aktiviert werden. Dies wird im Detail beschrieben im Blog des CAN-Board-Herstellers SK Pang.

Bitrate einstellen

Der UVR-CAN-Bus verwendet eine Bitrate von 50kbit/s – im Gegensatz zum Wärmepumpen-Bus, der 20kbit/s benötigt. Mit folgendem Befehl wird die Bitrate eingestellt und die CAN-Schnittstelle ‚aktiviert‘:

sudo ip link set can0 type can bitrate 50000
sudo ifconfig can0 up

Bei falscher Bitrate sieht man beim Mitschnüffeln keine Pakete weil das CAN-Interface ’stummgeschaltet‘ wurde (Fehler BUS OFF [*]).

Wenn man alles richtig macht, sind jetzt alle zwischen BL-NET und UVR1611 ausgetauschten Pakete auch für den Raspberry Pi lesbar. Installiert man Wireshark, kann die CAN-Schnittstelle ausgewählt werden … und die Pakete werden korrekt dem CAN-Protokoll zugeordnet:

CAN-Bus-Netzwerkverkehr mitsniffen mit Wireshark

Nachdem Steuerung und Logger diesen Test überstanden haben, wagen sich die Siedler an die Kommunikation mit der Wärmepumpe heran. Fortsetzung folgt …

[*] Etwas mehr Details im elkementaren Artikel zu diesem Thema.

Photovoltaik und Wärmepumpe: Tagesverläufe

… aber den Strom, den kann ich mir auch selber machen – im Gegensatz zu Pellets, Holz, Gas oder Öl  …

So ähnlich begründen viele Siedler und Wärmepumpenfreaks die Wahl ihrer PV-Anlage. Auch auf diesem Blog wurde zu diesem Thema schon berichtet und philosophiert – mit der gebotenen Vorsicht: Die täglichen Energiebilanzen zeigten, dass es ohne Batterie nur schwer gelingt, Eigenverbrauch und ‚Autarkie‘ deutlich zu steigern gegenüber einem Haushalt ohne Wärmepumpe – trotz des Energiehungers der Wärmepumpe, der Optimierung des Warmwasserprogrammes und der obsessiven Beschäftigung mit den Eigenheiten sämtlicher Stromverbraucher.

Die folgenden Bildchen aus dem ersten Betriebsjahr sollen das an einigen täglichen ‚Leistungskurven‘ im Lauf eines Jahres zeigen. Uhrzeiten werden ohne Berücksichtigung der Sommerzeit dargestellt.

Verglichen wird jeweils der tägliche Verlauf …

  • … der vom PV-Generator gelieferten elektrischen Leistung (Geloggt am Fronius-Symo-Wechselrichter)
  • … der benötigten Leistung für den Kompressor der Wärmepumpe (Gemessen mittels Energiezähler CAN-EZ an der Steuerung UVR1611)
  • … dem Nettostromverbrauch des gesamten Hauses inklusive Wärmepumpe, wobei die Überschusseinspeisung positiv gezählt wird (Smart Meter EM210, direkt hinter dem Siemens-AMIS-Zähler des Netzbetreibers angebracht).

Eine (nicht modulierende) Wärmepumpe liefert immer die nominelle Heizleistung und benötigt daher als Input ca. 1/4 dieser Energie. Die Siedler verwenden eine 7kW-Wärmepumpe. Damit muss der PV-Wechselrichter – je nach aktuell benötigter Heizungs- oder Warmwasservorlauftemperatur – zwischen 1,5 und 2,5kW liefern. Je mehr Heizenergie benötigt wird, umso länger / öfter läuft die Wärmepumpe. Der PV-Generator muss also genau zum richtigen Zeitpunkt eine relativ hohe Leistung zur Verfügung stellen.

Das bestmögliche Ergebnis im tiefsten Winter

An einem sonnigen Tag nahe der Wintersonnenwende kann im besten Fall zwischen 10:00 und 14:00 durch Sonnenenergie alleine geheizt werden:

2015-12-31: Stromzeugung Photovoltaik, Energieverbrauch Komporessor waermepumpe, gesamter Stromverbrauch (Smart Meter)

Diese Tage sind aber selten und in der kalten und langen Nacht wird ein wesentlicher Teil der Heizenergie benötigt.

Sommerlicher Überschuss

Im Sommer liefert die PV-Anlage untertags genug Energie um den Haushaltsstrombedarf zu decken und sogar zweimal Warmwasser aufzuheizen – in der Früh und am Nachmittag:

2015-07-01: Stromzeugung Photovoltaik, Energieverbrauch Komporessor waermepumpe, gesamter Stromverbrauch (Smart Meter)

Aber selbst wenn die Spitzen wolkenbedingt abgeschnitten würden, würde es an der gesamten Tagesbilanz gar nicht so viel ändern: Die Wärmepumpe benötigt im Sommer nur einen Bruchteil der gesamten verbrauchten Energie – 1-2kWh von 10-11kWh pro Tag.

Fette Ernte im Frühling

An einem ebenso schönen Frühlingstag ist der PV-Output aufgrund der geringeren Außentemperatur höher als an einem heißen Sommertag. Da noch geheizt wird, können neben der Warmwasserbereitung auch weitere Heizintervalle abgedeckt werden – die optimale Situation.

2016-04-29: Stromzeugung Photovoltaik, Energieverbrauch Komporessor waermepumpe, gesamter Stromverbrauch (Smart Meter)

Die elektrischen Leistungen für den Kompressor der Wärmepumpe liegen in der gleichen Größenordnung wie die Leistungsspitzen von Haushaltsgeräten wie Herd oder Wasserkocher zum Erhitzen benötigt werden. Kochen während eines Heizintervalls könnte man ’stromautark‘ mit der 5kW-PV-Anlage der Siedler nur zu Mittag an solchen Tagen.

Der Normalfall: Schlechtes Timing

An einem typischen Tag in der Übergangszeit wechseln Wolken und Sonnenschein rasch ab. In diesem Beispiel passt das Timing der Warmwasserbereitung genau nicht zu den optimalen Ernteintervallen.

2016-03-29: Stromzeugung Photovoltaik, Energieverbrauch Komporessor waermepumpe, gesamter Stromverbrauch (Smart Meter)

Zu Mittag wurden an dem Tag mehr als 3,5kW verbraucht (negative blaue Spitze) – hier siegte das unkontrollierbare Bedürfnis nach Kaffee oder Tee über die Energiespar-Begeisterung. Auch die smarteste Regelung könnte diesen raschen Wechsel von Sonne und Wolken nicht vorhersehen (außer man verfolgt einzelne Wolken…). Aus diesem Grund sind die Siedler auch etwas skeptisch, was das Anfordern der Wärmepumpe durch ein Signal der PV-Anlage betrifft.

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

 

 

 

Jenseits von Pannonien: Die Stunde des Wissenschaftsoffiziers

Wie schnell doch die Zeit vergeht! Ja, es war wirklich schon wieder über ein Jahr her, seit die Bewohner in die Siedlerhütte jenseits von Pannonien eingezogen waren und LEO_2 dort verlässlich für wohlige Wärme sorgte.

Jenseits von Pannonien - Kollektor

Seit über einem Jahr schon wärmte LEO_2 die Bewohner dieser Siedlerhütte jenseits von Pannonien…

Über den Fernwartungszugang hatte Irgendwer zwar immer wieder einen Blick auf den aktuellen Zustand des Wärmepumpensystems geworfen, aber abgesehen davon interessierte ihn inzwischen vielmehr die langfristige Performance der Anlage.

Das erforderte eine eingehende Analyse der laufend aufgezeichneten Monitoring-Daten, was ja prinzipiell keine unbekannte Aufgabe war. In diesem Fall hatte das aber den kleinen aber nicht unwesentlichen Haken, dass die manuelle Ablesung von Zählerständen aus der Entfernung nicht wirklich möglich war. Dadurch fehlten zwei entscheidende Messpunkte zur Bestimmung der Arbeitszahl, nämlich (1) die von der Wärmepumpe erzeugte Wärmeenergie (Ablesen des Wärmemengenzählers der Wärmepumpe) und (2) die von der Wärmepumpe benötigte elektrischen Energie (Ablesen des Stromzählers).

Wie konnte man aber trotzdem aus den automatisch erfassten Monitoring-Daten die Arbeitszahl der Wärmepumpe ermitteln? – Das war eindeutig ein Fall für das El(k)ement, das mit List und Heldenmut auch schon die scheinbar unbezwingbare hauseigene Datenkrake niedergerungen hatte.

JVP-Wärmepumpen-Temperaturen

Die Sole-Eintrittstemperatur und die Wärmepumpen-Vorlauftemperatur wurden jenseits von Pannonien in einem Intervall von ca. 1 Minute permanent aufgezeichnet. Aufgrund einer technischen Panne stehen für den Zeitraum zwischen Mitte August und Mitte Oktober 2015 leider keine Monitoring Daten zur Verfügung.

Nachdem sich das El(k)ement versichert hatte, dass die Messpunkte ‚Wärmepumpen-Vorlauftemperatur‚ und ‚Sole-Eintrittstemperatur‚ in den Monitoring Daten vorhanden waren, verschwand es siegessicher hinter seinem Bildschirm. Dann hörte Irgendwer nur noch das Klappern der Tastatur, gemischt mit einem unverständlichen Programmier-Kauderwelsch und schließlich ein triumphierendes Ha!. – Das untrügliche Zeichen, dass der Wissenschaftsoffizier wieder eines seiner berühmt-berüchtigten ‚Excel-Tools‘ vollendet hatte …

‚Schau her! Ganz einfach …‘

wurde Irgendwem erklärt,

‚Durch einen Polynom-Fit der technischen Daten der Wärmepumpe aus dem Handbuch habe ich die Wärmeleistung, die elektrische Leistungsaufnahme und die Leistungszahl der Wärmepumpe als Funktion der Sole-Eintrittstemperatur und der Wärmepumpen-Vorlauftemperatur ermittelt …‘

Die weiteren Details, die sich Irgendwer geduldig und anerkennend anhörte, sollen dem Leser an dieser Stelle erspart bleiben …

Technische Daten Wärmepumpe

Im Handbuch der Sole-Wasser Wärmepumpe fand das El(k)ement diese technischen Daten in Abhängigkeit von der Sole-Eintrittstemperatur: Die elektrische Leistungsaufnahme (P.EL), die Heizleistung (P.HZ) und die Leistungszahl (LZ). Die Farben kennzeichnen unterschiedliche Wärmepumpen-Vorlauftemperaturen.

Was Irgendwen aber letztlich vollständig von den theoretischen Berechnungen überzeugte, war die überraschend gute Übereinstimmung mit den praktischen Messungen, die das El(k)ement kurzerhand schon an den eigenen Messdaten verifiziert hatte.

Und so konnte Irgendwer schließlich zufrieden auf die Performance-Daten von LEO_2 (‚Jenseits von Pannonien‘) blicken:

JVP-Leistungsdaten-LEO_2

Theoretisch berechnete Leistungsdaten aus tatsächlich gemessenen Temperaturen (Sole-Eintrittstemperatur, Wärmepumpen-Vorlauftemperatur).  Aufgrund der Lücke in den Messdaten-Aufzeichnungen fehlt der September 2015 vollständig. Die Werte für August und Oktober wurden beruhend auf den teilweise vorhandenen Daten ermittelt.