Alte Heizung – Neue Regelung: Phase 2 – Programmierung

Die Rahmenbedingungen waren abgesteckt. Nun galt es, der bestehenden Heizungsanlage eine neue Intelligenz einzuhauchen, also zuallererst einmal alle Sensorsignale richtig zu verstehen.

Sensor

Irgendwem erschien es manchmal so, als wäre es eine Frage der Ehre für jeden Heizungshersteller, seinen eigenen Sensortyp zu verwenden. Umsomehr wusste er es zu schätzen, dass er auch diesen Exoten (NTC 5kOhm) in der Auswahlliste für mögliche UVR16x2-Sensoren wiederfand.

Sensor-Eingang-NTC

Aber auch das Ansteuern der Anlage, stellte ihn vor keine großen Schwierigkeiten:

Da noch keine hochgezüchteten elektronisch geregelten Pumpen eingebaut waren, war es neben einem simplen EIN/AUS auch möglich, TRIAC-Ausgänge der UVR16x2 für die Drehzahlregelung zu verwenden.

Auch die eingebauten automatischen Ventile und Heizungsmischer hörten – wie es sich gehört – auf Ein/Aus Signale mit 230V.

Einbindung-Mischer-Bestand

Einbindung und Ansteuerung des bestehenden Heizungsmischers

Und obwohl schon etwas betagt, hatte der Heizkessel einen potentialfreien externen Anforderungskontakt, über den er von der UVR16x2 direkt ein- und ausgeschaltet werden konnte.

Einzig der elektrische Heizstab, der im Warmwasserspeicher eingebaut war, erforderte ein zusätzliches Schütz, das über 230V von der UVR angesteuert werden konnte und das Schalten der hohen elektrischen Leistung übernahm.

Etwas kniffliger wurde es schon mit der Regelungslogik. Denn neben der Steuerung der nicht ganz alltäglichen Hydraulik sollten auch die Schwächen der alten Regelung ausgebügelt werden. Und um spezielle Anforderungen zu erfüllen, musste Irgendwer manchmal schon recht tief in seine Trickkiste greifen …

Regelungslogik

Die grafische Darstellung der Verknüpfung von Funktionsbausteinen im Programmiertool TAPPS war überaus hilfreich, um den Überblick über die Regelungslogik nicht zu verlieren…

Parallel zur Programmierung hielt Irgendwer alle relevanten Einzelheiten vom Hydraulikschema, über die Belegung der Ein-/Ausgänge, die Verdrahtung der Komponenten bis zur Regelungslogik in einem Handbuch fest. Denn der Besitzer sollte ja am Ende in der Lage sein, seine neue Regelung vollständig selbst zu verkabeln und in Betrieb zu nehmen.

Handbuch

Unverzichtbar: Das individuelle Siedler-Handbuch …

Damit wären wohl viele zufrieden gewesen. Nicht aber Irgendwer, der genau wusste, dass der wichtigste Teil erst nach der Inbetriebnahme wartete, nämlich die Optimierung der Regelung und die Anpassung an das tatsächliche Anlagenverhalten.

Daher war es aus seiner Sicht unverzichtbar, zu jeder Zeit – für ihn auch aus der Ferne – einen Überblick über die Anlage zu behalten und ein bestimmtes Regelungsverhalten auch im Nachhinein analysieren zu können.

Daher baute er mit Hilfe des TA-Designer ein Onlineschema, das den aktuellen Anlagenzustand auf eine Blick darstellte…

TA-Designer

Erstellen des Onlineschemas im TA-Designer

… und selektierte kritische Messwerte und Regelparameter, die er in die  Datenaufzeichnung aufnahm.

Konfiguration Datenlogging

Konfiguration des Datenloggings in TAPPS

Jetzt musste er nur noch warten, bis der Siedler seine neue UVR16x2 beschafft, über das CMI erfolgreich mit dem Internet verbunden, und ihm Fernwartungszugang gestattet hatte.

CMI-Fernwartung

Fernwartung über CMI und das Webportal der Technischen Alternative

Dann folgten noch einige Standard-Fernwartungs-Handgriffe: Firmware von CMI und Regler aktualisieren, Funktionsdaten und Onlineschema aufspielen, Abruf der Messdatenaufzeichnung über Winsol konfigurieren.

Und damit war alles bereit für die Inbetriebnahme …

Frage an die Datenkrake: Was ist wo in Winsol?

Kürzlich erreichte die Siedler ein Hilferuf eines anderen UVR-Tüftlers – ausgelöst durch brisante Berichte von der Krakenwanderung:

Wie schafft es die Datenkrake, dass unterschiedliche Windows-Benutzer die gleichen Log-Dateien in Winsol verwenden und die gleiche setup.xml-Datei?

Die ganz kurze Antwort: Indem unterschiedliche Windows-Benutzer in Ihren Winsol-Grundeinstellungen den gleichen Logfile-Ordner eintragen. Dann schreibt jeder Benutzer die Logfiles in den gleichen Ordner und verwendet auch die gleiche setup.xml-Datei.

Nach den Infos zur letzten CMI-Firmware-Upgrade (2.09 – 20.April 2018) ist das jetzt auch eine unterstützte Vorgansgweise:

Unterstützt exklusiven Schreibzugriff auf Kundenordner:
Wird von mehreren Computern (Programminstanzen) auf denselben Kunden im gemeinsamen Datenpfad zugegriffen, wird ein gleichzeitiges Bearbeiten verhindert. An allen beteiligten Computern muss dazu dieselbe Version von Winsol verwendet werden.

Folgendes ist eventuell noch zu beachten:

Frühere Winsol-Versionen haben die Logfiles im Windows-Programme-Ordner abgelegt bzw. haben das zumindest versucht. Nachdem Microsoft das aus Sicherheitsgründen nicht mehr erlaubt, gab’s eine u.U. vewirrende Umleitung in einen ‚versteckten‘ Ordner im Profil des jeweiligen Benutzers (VirtualStore). Näheres zu den Speicherorten in dieser Geschichte. Installiert man eine neuere Winsol-Version neu, liegt der Standardordner jetzt auch ‚wirklich‘ und sichtbar im Benutzerprofil; aktualisiert man eine ältere Winsol-Version, wird eventuell noch der VirtualStore verwendet. Je nachdem, wie man ‚in den Logfile-Ordner schaut‘, sieht man dann die Logfiles im Profil oder im Programme-Ordner. In letzterem Fall sieht es also so aus, als ob alle Benutzer in den gleichen Ordner schreiben würden:

Standard-Ordner in älteren Winsol-Versionen (Winsol 2.07, aktualisiert von früheren Versionen, Windows 10 32bit). Direkt im Windows Explorer sieht man keine Logfiles im Ordner Program Files – im Gegensatz zum Winsol-Dialog. Erklärung: Der tatsächlich verwendete Ordner ist
C:\Users\[Benutzer]\AppData\Local\VirtualStore\Program Files\Technische Alternative\Winsol
(Weitere Details hier.)

Wenn man immer sofort nach der Winsol-Installation einen Nicht-Standard-Ordner außerhalb des Benutzerprofils und außerhalb anderer spezieller Systemordner einstellt, braucht man sich damit nicht zu beschäftigen.

Zusätzlich zum Logfile-Ordner gibt es noch einen weiteren Ordner mit den persönlichen  Winsol-Einstellungen – der war ‚immer schon‘ im Windows-Benutzerprofil zu finden: Hier wird das Cookie für den Zugriff auf das CMI-Webportal abgelegt und in der (benutzerspezifischen) Winsol.xml-Datei wird der Pfad zu den Logdateien eingestellt. Dieses Cookie muss einmalig kopiert werden oder jeder Windows-Benutzer muss sich einmal mit dem / seinem Portalbenutzer anmelden.

Ordner mit den persönlichen Winsol-Einstellungen in C:\Users\[Benutzer]\AppData\Roaming\Technische Alternative\Winsol – dieser Speicherort kann / braucht nicht geändert zu werden.

Verwaltet man mehrere ‚Winsol-Profile‘ / Kunden, dann werden deren Logdateien im Ordner Infosol abgelegt. Für welche Kunden Logfiles automatisch (winsol -a) abgeholt werden, wird auch in der Winsol.xml festgelegt –  die betreffenden Kunden werden in einem XML-Tag alle namentlich erwähnt:

Inhalt der Winsol.xml-Datei. Der Tag Autostart enthält die Liste der abzuholenden Kunden, als Werte der Attribute K1, K2 etc.

Will man nun tatsächlich hier dauernd rumklicken – d.h. bestimmte Kunden beim automatischen Abholen mit winsol -a einmal dazunehmen und dann wieder ausschließen – dann müsste man entweder:

  • winsol.xml zwischen den verschiedenen Windows-Benutzern synchroniseren oder
  • Die ‚Abhollliste‘ irgendwo zentral speichern und alle winsol.xml-Dateien mit Scripts anpassen.

 

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

Die Datenkrake wird täglilch herausgefordert: So viele Möglichkeiten gibt es, neue Tentakel in bisher unerforschte Gebiete auszustrecken!

Das CMI ist seit einiger Zeit selbst eine Datenkrake: In den Einstellungen können Ein- und Ausgänge am CAN-Bus oder für Modbus-TCP konfiguriert werden.

Logisch und physisch getrennt von Wärmepumpe und Hydraulik arbeitet der PV-Wechselrichter der Siedler (Fronius Symo 4.5-3-M). Die PV-Daten werden lokal auf einen USB-Stick geloggt; das minimale Loggingintervall beträgt 5 Minuten. An manchen dunklen Abenden werden die gesammelten Daten dann an die Krake verfüttert. Der Fronius-Datenlogger hat eine WLAN-/Internet-Verbindung und einen lokalen Webserver, aber direkt ‚online runterkopieren‘ von diesem Stick kann man die Daten nicht.

Aber es gibt eine Modbus-TCP-Schnittstelle: Damit können die aktuellen Daten von einem Computer im  lokalen Netzwerk abgefragt werden oder von einem anderen Dings im Internet of Things. Die Siedler wollten nun wissen, ob der Modbus-Client des CMI das USB-Logging ersetzen könnte. Oder könnte gar die künstliche Intelligenz der Regelung auf die aktuelle PV-Leistung reagieren? Der Wechselrichter hat eine Energiemanagement-Funktion, aber 1) er könnte nur sehr schlicht über ein Relay ‚kommunizieren‘ und 2) das natürlich nicht über WLAN.

Nötige Schritte und einige Erkenntnisse:

Modbus wird aktiviert am Datenlogger des Wechselrichters. Wir entscheiden uns für echte Kommazahlen und erlauben keine Änderungen über Modbus:

Modbus-Einstellungen am lokalen Webserver des Fronius-Symo-Wechselrichters. 502 ist der Modbus-Standardport. Die Alternative zu float wären Ganzzahlen mit Skalierungsfaktor SF (Faktor steht dann in anderem Register).

Check der Modbus-TCP-Dokumentation von Fronius: Benötigt werden die Register (‚Speicherplätze‘) der interessanten Werte, z.B. die aktuelle Outputleistung. Das ausführliche PDF ist aktuell hier zu finden. Eventuell Logging-würdige Werte sind in verschiedenen Tabellen (‚Models‘) zu finden – z.B. Daten die dem Wechselrichter ‚als Ganzes‘ zugeordnet werden oder nur einem String von PV-Modulen.

Dokumentation S.30, Common Inverter Model. Zum Loggen der Wechselstrom-Leistung werden folgende Angaben benötigt: Adresse 40092, Registertyp 3 (read and hold), Datentyp float32 (Platz entspricht zwei 16bit-Register, daher ist die Endadresse 40093) und die Einheit Watt.

Wichtig dazu ist dieser Hinweis auf S.15:

D.h. auf einem Modbus-Client muss bei der Abfrage der Leistung 40091 angegeben werden.

Mit diesen Infos und der IP-Adresse des Wechselrichters in lokalen Netz wird ein entsprechender analoger Modbus-Eingang am CMI festgelegt:

Modbus-Analogeingang 1 liest die aktuelle PV-Leistung vom Wechselrichter. Der ‚Eingangswert‘ ergibt sich, wenn die Daten als Integerzahl interpretiert werden. ‚Aktueller Wert‘: Der Integer-Teil der ‚wahren‘ Gleitkommazahl.

Ja, wir haben uns das in einem Netzwerk-Trace angeschaut 😉 nachdem uns das Dropdown-Menü zur Byte-Reihenfolge etwas verwirrt hatte: Modbus-TCP sollte immer Big Endian verwenden laut Protokollspezifikation.

Faktoren und Datentypen: Am CAN-Bus werden nur Integer-Werte verarbeitet – evtl. mit einem Skalierungsfaktor als Zusatzinformation. Bei der Leistung in Watt gibt es da glücklicherweise keinen Handlungsbedarf. Würde man aber z.B. die 15A Strom mit einer Kommazahl loggen wollen, müsste man den Faktor auf 10 setzen um eine Kommastelle aus der Floatzahl ‚mitzunehmen‘. Vorher am Symo Integer + Skalierungsfaktor einzustellen ist nicht sinnvoll, da dieser Faktor in einem anderen Register des Wechselrichters steht … das das CMI natürlich nicht kennt.

Wenn man statt relativ stabilen Werten irgendwelche Zahlen zwischen ca. -32000 und + 32000 sieht 😉 merkt man, dass hier etwas schiefgegangen ist.

Diese Einstellung bedeutet noch nicht, dass das CMI die Modbus-Daten schon ‚hat‘ und mitloggt. Alles, was man bis jetzt davon ‚hat‘, ist die Anzeige des aktuellen Wertes in der CMI-Modbus-Einstellung. Zur Weiterverarbeitung inklusive dem Logging am CMI selbst muss wieder ein passender Ausgang definiert werden. Das CMI kann nur über CAN- oder DL-Bus loggen. Also brauchen wir einen…

… analogen CAN-Bus-Ausgang am CMI:

Das CMI hat die Standard-Knotennummer 56. Jedes andere Gerät am CAN-Bus kann damit diesen Wert auslesen durch Angabe der Knotennummer und der Nummer des Analogausgangs – 1.

Diese Geräte nutzen aktuell den CAN-Bus:

Darstellung der Geräte durch das CMI. Beim Klick auf (unterstützte) Geräte kommt man in das entsprechende Konfigurationsmenü.

Wenn man sich die Logging-Einstellungen am CMI ansieht, könnte man in Versuchung kommen, einfach das CMI selbst – CAN 56 – auszuwählen:

Am CMI konfiguriertes lokales CAN-Logging (Nutzung mit Winsol) – von UVR1611 (1), UVR16x2 (2) und dem Energiezähler CAN-EZ (41).

Erkenntnis: Das CMI kann aber seinen eigenen CAN-Ausgang nicht loggen. Man kann zwar CAN 56 als Logging-Quelle im Dropdown-Menü anklicken, aber das endet dann so:

CAN-Fehler am CMI – ausgelöst durch den Versuch, das CMI als Logging-Quelle einzutragen (so dass es gleichzeitig Logger und Quelle spielt).

Hier ist das ‚Durchschleifen‘ des Wertes durch die ‚loggingfähige‘ UVR nötig – womit endlich der Titel des Postings erklärt wäre!

An der UVR16x2 wird der CAN-Ausgang des CMI jetzt als CAN-Eingang (‚Netzwerkvariable‘) verbunden:

Definition des Netzwerkeingangs auf der UVR16x2. Quelle ist der CAN-Ausgang am CMI (Knoten 56, Ausgang 1).

Die Leistung in Watt wird als Integer übergeben. Hätte man am Modbuseingang einen Faktor 10 verwendet, müsste hier die Einheit auf ‚dimensionslos,1‘ gesetzt werden.

Aktueller Wert am CAN-Netzwerkeingang.

Die UVR16x2 kennt damit die PV-Leistung. Dieser Wert steht für Regelungszwecke zur Verfügung und Irgendwer kann beginnen, das Warmwasser-Zeitprogramm durch eine Digitalisierte Smarte 4.0 Big Data AI Bot Version abzulösen. Skynet entwickelt ein Bewusstsein!

Andererseits kann der Wert durch das CMI von der UVR geloggt werden – als Teil des immer schon genutzten CAN-Loggings:

Anzeige der geloggten Daten mit Winsol (Zugriff auf lokale Logfiles): PV-Leistung, Globalstrahlung auf die senkrechte Fläche des Kollektors, Kollektortemperatur, Außentemperatur.

… bzw. kann das ‚Portal-Logging‘ auf cmi.ta.co.at konfiguriert werden …

Konfiguration des Loggings direkt am Portal cmi.ta.co.at – als mögliche Loggingquellen stehen nur UVR1611 und UVR16x2 zur Verfügung. Die interessanten CAN-Ausgänge müssen in den rechten Bereich gezogen werden – dann kann dieser Parameter in einem Profil ausgewählt werden und das Diagramm des Werteverlaufs wird online angezeigt.

… und online mitverfolgt …

Anzeige Logging-Profil auf cmi.ta.co.at. In diesem Fall werden die Daten beim Logging vom CMI an das Portal gesendet und dort gespeichert.

Würde man alle Outputwerte des Fronius-Datamanagers auf diese Art loggen, hätte man außerdem schnell die Limits betreffend Netzwerkvariablen und Loggingplätzen erreicht. Wenn man unbedingt jede Minute die Spannung zwischen Phase 1 und 2 oder die Blindleistung wissen will, verwendet man besser einen eigenen Logger, z.B. Rasperry Pi. Hier ist ein perfekt dokumentiertes Projekt: Logging der Daten von Fronius Symo mit Python über Modbus TCP, plus Datenbank und Weboberfläche.

Nur Werte, die tatsächlich auch zum  Regeln benötigt werden, sollten beim Fenster rausgeworfen und bei der Türe wieder hereingebeten werden!

Unfreundliche Anwendungen mit schlechtem Benehmen

(… oder: Endlich wieder ein Beitrag aus der Akte-X-Serie…)

Das Elkement ist eine typische IT-Security-Abteilung und versucht daher den produktiven Ingenieursabteilungen die tägliche Arbeit so mühsam wie möglich zu machen.

So wurde auf dem Chefingenieurs-Notebook das neueste Windows-10-Feature gleich ausprobiert – Controlled Folder Access. Windows 10 Defender wacht über Zugriffe auf definierte Ordner und wehrt Angriffe von unfreundlichen Applikationen ab.

Und als ebensolche wurden gleich Winsol (und dann auch TAPPS) eingestuft:

Fügt man Winsol.exe in der Windows Defender Konfiguration zur Liste der erlaubten Anwendungen hinzu (Allow an App), ist der Spuk vorbei.

Beim Testen dieser Funktionen wurde das Elkement auf folgendes fundamentale Rätsel der Winsol-Konfiguration aufmerksam: Wo werden die Winsol-Daten eigentlich per Default gespeichert? …. ein jahrelang vernachlässigtes Forschungsgebiet! Die Siedler hatten ja in jeder Winsol-Installation immer gleich ihren eigenen speziellen Logfile-Ordner eingestellt – dort wo z.B. die hungrige Datenkrake auf die Logfiles wartet.

In einer frischen Winsol-Installation begegnet einem aber dieses Mysterium:

Aus Winsol heraus betrachtet – beim Versuch den Standardordner zu ändern, sieht man die neuesten Logfiles in C:\Program Files\Technische Alternative\Winsol\LogX (rechts im Bild). Direkt im Explorer (links im Bild) sucht man den LogX-Ordner aber vergeblich, ebenso wie die Infosol-Ordner mit den Kundendaten:

Bevor sich das Elkement mit so etwas theoretisch beschäftt, wird einmal geschnüffelt mit Microsoft Sysinternals Process Monitor.

Aha! Winsol greift in Wirklichkeit auf einen Unterordner VirtualStore im Benutzerprofil zu – hier gibt es eine ‚Umleitung‘ (REPARSE):

Die Logfiles verstecken sich somit hier:

C:\Users\[Benutzer]\AppData\Local\VirtualStore\Program Files\Technische Alternative\Winsol

Dieser VirtualStore ist ein seit Vista genutztes Sicherheits-Features, wenn Anwendungen etwas zu ‚anmaßend‘ sind. Hier ein Beispiel:

…  in most cases when a developer tells his program to save data in the Program Files folder, for example, program settings, he has completely forgotten that program settings should be a per-user thing! … In other words, a well-behaved application should instead save its settings in the
C:\Users\<User Name>\AppData\Local\<Manufacturer>\<Product>\<Product Version>

Ever since Windows Vista, applications that are not running with raised privileges that try to write to the Program Files (or Program Files (x86)) folder will in fact write to the VirtualStore folder, unknowingly.

Es gibt es aber auch einige offizielle Winsol-Einstellungen pro Benutzer im Ordner:

C:\Users\[Benutzer]\AppData\Roaming\Technische Alternative\Winsol

Hier wird z.B. das Cookie für die Anmeldung am Webportal abgelegt – aber eben nicht die Logfiles.

Zusammengefasst: Möchte man jetzt die aktuelle Winsol-Installation auf einen anderen PC übertragen oder lokal den Ordner ändern – und in mehrfacher Hinsicht ’sicher‘ konfigurieren, also sicher vor Hackern und vor allem für sich selbst auffindbar, geht der unerschrockene Monitoring-Bastler so vor:

  • Winsol wird auf dem Ziel-PC neu installiert.
  • In den Grundeinstellungen wählt man einen Ordner außerhalb von ‚Programme‘ – am besten dort, wo man auch andere Projektdateien speichert – also in einem Ordner für den eine regelmäßige Sicherung erfolgt (Z.B.: Cloud und externe Festplatte)
  • In diesen neuen Ordner werden die Dateien aus dem alten Winsol-Ordner kopiert, also alle ‚eigenen‘ Logdateien, exportierte CSV-Dateien und ggf. auch die Unterordner anderer Kunden im Ordner Infosol. (Das gilt nur dann uneingeschränkt, wenn auch die gleiche Winsol-Version verwendet wird – vor ca. 1 Jahr gab es ja eine subtile mehrstufige ‚Migration‘ bedingt durch Regler- und Software-Updates.)
  • Um sich das einmalige Anmelden am Portal zu sparen, kann auch der Inhalt von C:\Users\[Benutzer]\AppData\Roaming\Technische Alternative\Winsol kopiert werden.
  • In Controlled Folder Access in Windows 10 muss Winsol.exe in die Liste der erlaubten Anwendungen eingetragen werden (oder der Logfile-Ordner ausgenommen – sicherer ist, nur Winsol zu erlauben).

_______________

Nachtrag 2018-01-31: Die Tests wurden mit der Winsol-Version 2.07 durchgeführt, kurz bevor die Version 2.08 zur Verfügung gestellt wurde. 2.07 war auf diesem PC ein Upgrade einer früheren Version.

Installiert man Winsol 2.08 neu (auf Windows 10), dann wird mittlerweile als Standardordner ein Unterordner im Profil vorgeschlagen – gutes Benehmen wie von Microsoft empfohlen 😉

C:\Users\[Username]\Documents\Technische Alternative\Winsol

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

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