Über elkement (Elke Stangl)

Physicist, engineer, geek, dilettante science blogger, IT security consultant, search term poet, Subversive El(k)ement.

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!

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!

Ingenieurssoftware-Archäologie

Ingenieurssoftware hat oft eine kleine aber feine Zielgruppe – ein Grüppchen, das globale Softwarekonzerne nicht unbedingt im Visier haben. Dementsprechend atmet die Benutzeroberfläche oft nolstalgisch-spartanischen Charme.

Aber auch in den Tiefen solcher Software gibt es aufsehenerregende Funde aus dem Software-Paläozoikum – genau das richtige für das Elkement, das diese Bugs versteckten Features unerbittlich erschnüffelt. Von einem Paradebeispiel aus der täglichen Schnüffelpraxis soll diese Geschichte handeln! Wie der prähistorische Schnüffler aus Ice Age ist das Elkement beharrlich … und wird aber am Ende ausgetrickst.

Was man hätte sehen sollen (in jener Software): Ein Bild der Bedienelemente einer Regelung und darüber schwebende Zahlen. Mit Rumspielen an den abgebildeten Knöpfchen hätte man das echte Gerät simulieren können.

Was man sah: Eine Fehlermeldung in einem mutmaßlich fernöstlichen Zeichensatz.

Natürlich fragt der geübte Sniffer als Erstes Google Translate um Hilfe:

Die [XY]-Gerätedatei kann nicht gelesen werden.

… und es gibt tatsächlich eine Datei xydevice.xls … die sich aber mit Excel lesen lässt (?!) … also zumindest lassen sich die überwiegend fernöstlichen Zeichen in den Tabellen darin betrachten.

Nächster Schritt: Wahlloses Durchtesten der üblichen Fallstricke für Software aus vergangenen Epochen? 32bit versus 64bit? Administrator-Rechte? Dateiberechtigungen? Muss eine alte Windows-7-Maschine wiederbelebt werden? … und tatsächlich: Ein einziges Mal sieht der erschöpfte Schnüffler ganz kurz die Animation der XY-Regelung: Beim ersten Test auf einer paläozoischen Maschine (Windows 7 und 32bit). Leider ist der Test nicht reproduzierbar, also wird unerschrocken weitergeforscht.

Ein professionelles Schnüffelwerkzeug – Microsoft Sysinternals Process Monitor – zeigt, dass die Software erfolgreich auf die rätselhafte Datei zugreift:

Process Monitor: Prüfung Zugriff auf xls-Datei durch Anwendung

Kurz vor dem Zugriff arbeitet sich die Software durch Datenbanktreiber (‚JET‘) für Office-Dateien – die letzte davon ist msexcl40.dll – damit kann eine XLS-Datei wie eine Datenbank abgefragt werden.

Aber in dieser Schnüffelspur sieht man keine Fehlermeldung: Die xls-Datei wird geschlossen, bevor das Popupfenster mit Fehlermeldung erscheint … also ist die Anwendung halbwegs kontrolliert mit dem Fehler fertig geworden und hat ihn richtig ‚gehandled‘.

Das Elkement bzw. die Datenkrake haben langjährige einschlägige Erfahrung im wilden Basteln mit Konstrukten aus Excel- / Access- und Textdateien, die zu fragilen Datenbanken vereinigt werden. D.h. im Programmierer aus der fernen Zeitzone erkannte das Elkement eine verwandte Seele. Es versuchte, sich in diesem Lao Tse der Office-Programmierung hineinzufühlen. Beim einzig erfolgreichen Start des Programms waren einige XML-Dateien erzeugt worden. Soweit erahnbar durch Zeichenvergleich, wurden aus der xls-‚Datenbank‘ Einträge zu einem Gerät bestimmten Typs gelesen und in die XML-Datei geschrieben.

Aber was ging schief? Der Schnüffler der nächsten Tiefe wird gestartet – der Windows Debugger WinDbg (Teil der Debugging tools for Windows). Mit Reverse-Engineering-Halbwissen stolpert das Elkement zur nächsten unhandled oder handled exception – und wieder fällt msexec40.dll unangenehm auf:

Output Windows Debugger - Fehler bei Datenbankzugriff - msexec40.dll

Und da war sie endlich – die google-bare Fehlermeldung im Microsoft-O-Ton:

Unexpected error from external database driver (1).

So richtig optimistisch machte dieser eher generisch und schlicht gehaltene Text ja nicht. Aber man glaubt es kaum – es gab tatsächlich einen relativ neuen Microsoft-Artikel, der exakt diesen Fehler im genau passenden Kontext auflistet. In einem Überblick über  Betriebssystem-Updates von Herbst 2017 wird über ein Problem mit älteren JET-Datenbanktreibern für xls-Dateien brichtet – über einen neuer Fehler, der genau seit diesem Windows-Updates auftritt:

Microsoft-Artikel - Problem mit JET-Treiber / xls-Dateien nach Update

Damit kann endlich eine plausible Erklärung für den einzig erfolgreichen Test formuliert werden: Die Software wurde auf diesem länger nicht gestarteten Windows-7-Computer getestet – exakt als die Updates der letzten Monate noch nicht installiert worden waren, inklusive dem in diesem Artikel erwähnten Update.

Auch der dezente Hinweis von Microsoft, doch einen neueren Datenbanktreiber zu verwenden – neuer als Stand Office 2007 – passt dazu: Die ausführbaren Dateien der prähistorischen Softwaren waren alle ca. 10 Jahre alt.

Wie der possierlich-zappelige Schnüffler aus Ice Age wurde das Elkement damit mit einem Dilemma konfroniert und ausgetrickst: Um die Sicherheit nicht zu gefährden [Bitte Buzz Words passend einsetzen: Cyber Security – Internet of Things] wurde das unerbittliche Windows Update nicht mehr deinstalliert. Damit bleibt nur zu hoffen, dass entweder Lao Tse den Datenbanktreiber austauscht oder dass Microsoft, wie im Artikel angekündigt, das prähistorische Feature wieder aktiviert.

Was man so alles in einem Hydraulikschema findet

Wie diese Internetpostille zeigen soll, ist der Bau eines Wärmepumpensystems ein wahrlich interdisziplinäres Unterfangen für einen Leonardo da Vinci – einen Pionier der nicht davor zurückschreckt, sich als Installateur, Tischler, Maurer, Elektriker und IT-Techniker zu versuchen.

Aber selbst die Siedler sind dann immer wieder überrascht, wie sehr sich dieser kühne, ganzheitliche Ansatz schon in jedem Hydraulikschema findet – in radikaler Ausrpägung!

Sowohl im Heizkreis als auch im Solekreis findet man Plutonium – Pu

Unklar ist, ob das ein Risiko darstellt, oder sich positiv auf die Energieernte auswirkt. Aber überraschend ist es nicht – ist doch Doc Emmett Brown der Held der Siedler.

Aber vielleicht kann man die Auswirkungen der Kontamination schon erkennen – wie könnte man sonst diese mutierten Schmetterlinge mit den drei Flügeln erklären? Die Markierung M muss ja auch eine Bedeutung haben …

Neben Nuklearenergie findet man aber auch eine andere – besonders innovative – Energiequelle. Als Standard-Notheizung wird offenbar Facebook Messenger verwendet …

… das muss eines dieser Energie-aus-der-Cloud-Projekte eines Internetgiganten sein!

Aber welche Bedeutung hat der Tennisball namens DF?

 

5 Jahre Tüftelei

Am dreiundzwanzigsten Dezember, Anno 2012 spitzte Irgendwer zum ersten Mal seinen virtuellen Federkiel und schrieb eine kleine Geschichte:

Doch dann hatte Irgendwer eine Idee ausgetüftelt, sich ans Reißbrett gesetzt, unzählige Entwürfe gezeichnet und wieder zerknüllt, nächtelang recherchiert und gegrübelt. Schließlich war ihm das Elkement mit seinem spitzen Rechenstift zu Hilfe gekommen und hatte theoretisch bestätigt, was er intuitiv vermutet hatte. Dann wurde in der Werkstatt gezimmert, geschraubt, geklebt, gepinselt und abgedichtet …

Zum ersten Mal wurde der Weltöffenlichkeit ein Blick auf den Kollektor 1.0 gewährt:

Der Urkollektor.

Mittlerweile sind 5 Jahre in das idyllische Land gezogen und die Anlage von Irgendwem und dem Elkement erlebte unzählige Mutationen. Irgendwer musste viele Abenteuer bestehen, die ihn oft an seine mentalen und physischen Grenzen brachten. Vom White-Out…

White-Out

… bis zum Kampf mit gar unheimlichen Kreaturen:

Kampf mit der Flexschlauch-Anaconda

Irgendwer folgte seiner innerem Stimme, die ihm sagte, dass er mutig vorangehen musste.

Und jetzt Du!

Die sehr scheuen pannonischen Tüftler schreckten sich fast, als sie telegraphische Post von anderen Siedlern erhielten – die Irgendwessen Aufruf tatsächlich folgen wollten!!

Und so ritt Irgendwer an einem legendären Morgen im Februar 2014 in den Sonnenaufgang – bepackt mit den Bauteilen für einen Tank-Wärmetauscher:

PVC-Trägerkonstruktion: Transport

Auf dieser Baustelle kam auch Cutting Edge Technology zum Einsatz  …

Internet-of-Things und Basteln 4.0

… und die Siedler begannen intern zu scherzen als (Ex-)Computer-Fuzzis :

Irgendwann machen wir so ein Wärmepumpenprojekt komplett als Fernprojekt!

Und im Herbst 2014 kam sie dann, die Rohrpost vom anderen Ende des Kontinents – der Beginn eines außergewöhnlichen Projektes, das ob der großen Entfernung zwischen dem Hohen Norden und Pannonien alleine auf die Mittel der modernen Kommunikation angewiesen war.

Seitdem wurden Elkement und Irgendwer ordentlich gefordert. Es gab offenbar ein kleines aber feines Grüppchen unerschrockener, verwegener und manchmal sogar tollkühner Siedler, die ihre Begeisterung für Eisspeicher, Wärmepumpen, Selber-Bau und Regelungs-Tüfteleien teilten.

Zaghafte Ideen irgendetwas zu ’standardisieren‘ wurden glücklicherweise durch die Ideen dieser motivierten Siedler im Keim erstickt:

Siedler bauten ihre Eisspeicher-Keller neu

Wärmetauscher in neu gebauten 'Eisspeicher-Keller'

… oder sie nutzen vorhandene Hohlräume wie  Zisternen oder Senkgruben

Flexschläuche -Senkgrube als Eisspeicher

Ein cleverer Siedler adaptierte ein altes Schwimmbecken. Ein anderer griff zum Vorschlaghammer, um einen bereits vorhandenen Eisspeicher umzubauen!

Eisspeicher waren eckig oder rund

Zylindrischer Eisspeicher selbst gemauert

… oder gebräuchliche Betonzisternen – eine oder zwei …

… oder besonders futuristische Kunststofftanks:

NEO und QUADRO

Diese Speicher wurden verbunden mit Kollektoren aller Art: Der zeitlos-klassische Schlauchkollektor auf Lärchenholz kann zaunartig montiert werden…

Kollektor auf Garagendach

… oder auch kühn an die Wand eines Hochbunkers gelehnt werden:

Kollektor am Hochbunker

Innovative Siedler bauten solarthermische Kollektoren um oder installierten einen Kollektor als Kühlung für ihre PV-Module. Ein echter Pionier arbeitet mit dem, was da ist: Auch industrielle Stahlwärmetauscher die irgendwo übrig geblieben waren hatte ein Ingenieur-Siedler in Erwägung gezogen.

Aber die Kombiquelle Eisspeicher und Kollektor ist für manche Siedler nicht Herausforderung genug. So erhielten Frau El(k)ement und Herr Irgendwer eine Anfrage zu einer Tüftelei, die dieser Bezeichnung alle Ehre machte. Seitdem wurde auch die Eisspeicher-Brunnenquelle ins Programm aufgenommen.

Auch was Verteilung und Speicherung der Wärme in der Siedlerhütte betrifft, sind die Siedler-Erfinder kreativ. Vorhandene Speicher mit kryptischem hydraulischen Verhalten wurden erforscht und so manches Wochenende der Bastelei im Heizraum gewidmet. Speicher wurden über engste Kellerstiegen in Heizungsräume transportiert die so klein waren, dass es physikalisch zunächst unmöglich erschien, alle nötigen Anlagenkomponenten dort unterzubringen. – Aber wo ein Wille, da auch ein Weg!

Mit Irgendwem hatten die Siedler diverse hydraulische Schaltungen ausgetüftelt, um u.a. aktivierte Betonkerne einzubinden – oder Wärmetauscher für Kühlung bzw. Wärmerückgewinnung.

Dank peniblester Dokumentation und ausführlichen Berichten der mutigen Siedler hatten die Pannonier immer das Gefühl, direkt in deren Werkstatt live dabei zu sein …

Siedlerwerkstatt: Kappsäge

Natürlich wurden auch unterschiedlichste Wärmepumpen ausprobiert – von den klassischen Fabrikaten aus Deutscher Ingenieurshand

Satelliten-Wärmepumpe

… bis zur berühmt-berüchtigten Chinesischen Wärmepumpe

Verwegen! (HISEER-Wärmepumpe)

Außerdem soll nicht unerwähnt bleiben, dass man gar keine Wärmepumpe haben muss, um ein Teil der Siedler-Tüftler-Community zu sein: Auch Solaranlagen geben Irgendwem immer wieder interessante Regelungsrätsel auf.

In diesem Sinne möchten sich die pannonischen Siedler nach 5 Jahren der abenteuerlichen Tüfteleien bei allen anderen Siedlern für ihren Mut bedanken!

__________________________________

Weiterführende Literatur: Die chronologische Liste aller veröffentlichten Geschichten anderer Siedler sind auf dieser Seite aufgelistet.

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

Das Kollektor-Paradoxon

Kürzlich wurde hier das übliche Messdaten-Update abgefeiert. Die PDF-Messdatendokumentation enthält inzwischen schon fünf komplette Heizsaisonen:

Heizenergien (inkl. Warmwasser), elektrische Energien (inkl. Solepumpe) und die resultierende Arbeitszahl für die bisherigen Saisonen. Zu speziellen Experimenten in jedem Jahr siehe Text des Postings oder das oben verlinkte PDF.

Es wird Zeit, endlich die fundamentalen Fragen der Eisspeicher- und Kollektor-Forschung in Angriff zu nehmen.

Welchen Einfluss hat die Fläche des Kollektors auf die Performance der Anlage?

und

Wie stark ist der Kollektor?

Im Herbst 2014 hatte Chefingenieur dieses Forschungsprojekt gestartet und schnell einmal den Kollektor umgebaut. Nicht nur wegen der Ästhetik der Lärchenholzkonstruktion, sondern um die nutzbare Fläche umschalten zu können – von 12m2 auf 24m :

Kollektorschaltungen

OBEN: Voller Kollektor, Schaltung wie in den Heizsaisonen 2012, 2013 und 2017 (aktuell). UNTEN: Halber Kollektor, verwendet in den Saisonen 2014, 15, und 16.

Nun gilt es, Heizsaisonen zu finden, die sich (fast) nur durch die genutzte Kollektorfläche unterscheiden.

Die Saisonen 2014 und 2016 fallen einmal weg, da die Siedler hier versucht haben, einen riesigen Holzhaufen ökologisch sinnvoll wegzubringen … ein Problem mit dem ein renovierungswürtiger Siedler sich hin und wieder konfrontiert sieht:

Die Siedler vor über eine Dekade – zum Zeitpunkt der größten Zerstörung. Das Bild zeigt einen kleinen Teil des übrigen ‚Brennholzes‘.

So wurde in diesen Saisonen nur das Untergeschoß mit der Wärmepumpe beheizt. Aufgrund des atypischen Kollektorbetriebs während der Eisspeicher-Challenge muss man die Saison 2014 ohnehin aus der Wertung nehmen.

Dann sollte auch der Jahres-Energiebedarf vergleichbar sein: Die kalten Winter 2012 und 2016 fallen damit weg.

Es bleiben die eher wärmeren Saisonen 2013 (ganzer Kollektor) und 2015 (halber Kollektor): Das ganze Haus wurde mit der Wärmepumpe beheizt; Heizenergien und Entzugsenergien waren sehr ähnlich.

Aber der Blick auf die Jahresarbeitszahlen verursachte ein erstes Stirnrunzeln. Die waren praktisch identisch (!). Um eine Tendenz erkennen zu können, musste man tiefer graben und die Eisperioden (Dez/Jan/Feb) vergleichen. Dort erkennt man zwar einen Unterschied, der fällt aber weit geringer aus, als man ihn vielleicht erwarten würde

In der Eisperiode für den halben Kollektor war:

  • die Kollektorernte um ca. 10% niedriger
  • die Arbeitszahl um ca. 0,2 Punkte geringer
  • die Sole-Eintrittstemperatur in die Wärmepumpe um ca. 1,5K geringer
Halber-Kollektor-vereist

Der halbe Kollektor in Betrieb.

Die Siedler überprüften Ihre Datenkrake auf Bugs und versuchten alte handschriftliche Notizen zu entziffern. Kann das stimmen?

Aber eigentlich hätte sie es schon lange wissen müssen: Das Orkrakel – ihre Simulation des Wärmepumpensystems hatte diesen Trend vorhergesagt. Aber auch die ersten Berechnungen aus grauer Vorzeit liefern den Schlüssel zur Lösung des Rätsels. So hatten die Siedler doch tatsächlich verdrängt, dass sie sich vor Jahren – vor dem Bau von LEO_2 – schon theoretisch damit beschäftigt hatten, was eine Vergrößerung der Kollektorfläche bringen kann.

Schon damals war ihnen die Bedeutung der Serienschaltung des Kollektors mit dem Wärmetauscher im Eisspeicher bewußt gewesen.

Für the ‚theoretische Abhandlung von Wärmetauschern in Serie‘ muss man eigentlich nur zwei Dinge wissen:

  1. Die Leistung eines Wärmetauschers kann man auf zwei Arten darstellen: Einerseits als proportional zur Differenz der Soletemperaturen beim Ein- und Austritt – und andererseits als proportional zur mittleren Temperaturdifferenz zwischen Sole und dem umgebenden Medium (Luft oder Wasser im Tank).
  2. Wenn man Wärmetauscher in einem Kreis zusammenhängt, sind ihre Leistungen nicht unabhängig, da sie die Temperaturen an den Verbindungspunkten gemeinsam haben.

Wenn die Wärmepumpe nicht läuft, dann müssen Kollektor und Tankwärmetauscher beide genau die gleiche Leistung ‚tauschen‘. Kennt man Luft- und Tanktemperatur, Schlauchlängen und Übertragungsfaktoren – dann kann man die Wärmetauscherleistung ausrechnen.

Das Orkrakel kennt die Leistung der Wärmepumpe und deren Spreizung im Solekreis – und berechnet nach diesen Prinzipien so die Soletemperatur an den interessanten drei Verbindungspunkten im Solekreis:

3-Punkte-Methode - Wärmeaustauscher und Solekreis: Eisspeicher, Wärmepumpe, Kollektor.

Überblick über Wärmeaustauscher und Solekreis. Die drei ‚interessanten‘ Temperaturen im Solekreis, vor/nach Wärmepumpe, Kollektor und Tank können berechnet werden aus der aktuellen Wärmepumpenleistung, Außen- und Tanktemperatur.

Der entscheidende Punkt lässt sich schon erkennen, wenn man den ‚Regenerationsbetrieb‘ ohne Wärmepumpe betrachtet:

Die aktuelle Ernte-Leistung des Kollektors ist proportional zum Temperaturunterschied von Luft und Tank … nicht sehr überraschend! Je wärmer die Luft im Vergleich zum Tank, umso mehr kann man ernten.

Dann spielt die Kombination der Wärmeübertragungseigenschaften der beiden Wärmetauscher eine Rolle: Wie man – eigentlich auch wieder ohne Forschungsprojekt – erwarten hätte könne, ist die übertragene Leistung sehr klein, wenn einer der beiden Wärmetauscher sehr ’schlecht‘ ist im Vergleich zum anderern: Wenn z.B. der Schlauch im Tank unverhältnismäßig kurz wäre, oder wenn statt einem Schlauchkollektor (mit gutem Wärmeübergang durch Konvektion) ein Flachkollektor verwendet würde.

Wenn man in so einem suboptimalen Fall den ohnehin schon viel besseren Wärmetauscher noch besser macht, dann ändert sich nicht viel. Macht man stattdessen den schlechteren besser, sieht man – eh klar – eine deutliche Verbesserung. Haben beide Wärmetauscher Übertragungseigenschaften in der gleichen Größenordnung – wie das die typischer ‚Siedler-Dimensionierung‘ vorsieht, dann kann die Größe oder ‚Stärke‘ jedes Wärmetauschers vergleichsweise deutlich ändern, ohne drastische Auswirkung. Z.B. wird durch Vergrößerung der Kollektorfläche die Leistung besser, aber sie wächst weniger als linear.

Damit ist auch die Frage nach der Stärke des Kollektor beantwortet: Man kann nicht sagen, wieviel ein Kollektor in kW oder in kW pro Fläche bringt, wenn man nicht auch die Eigenschaften des dazugehörigen Wärmetauschers im Tank kennt.

Noch einen subtilen Effekt gilt es zu berücksichtigen: Der halbe Kollektor bringt nun fast die doppelte Leistung pro Fläche. Aber damit alles zusammenpasst, muss nach den genannten ‚Wärmetauschergrundsätzen‘ auch die mittlere Temperaturdifferenz zum umgebenden Medium größer werden: das Produkt aus Fläche und dieser Temperaturdifferenz darf sich ja fast nicht ändern.

Nachdem die Lufttemperatur vorgegeben ist, muss damit die mittlere Soletemperatur sinken und damit sinkt die Arbeitszahl etwas – genau der Effekt, den die Siedler in den Daten für die Eisperioden sehen.