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!

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

Gönnen wir dem CMI sein eigenes Netz!

oder:

Wie Irgendwessen Problem gelöst wurde, weil das elkement gerne schnüffelt, was die ‚Dinge‘ so machen im Internet of Things.

Irgendwer stand vor einer besonderen Herausforderung: Der Chefingenieur und Regler-Freak hatte das ideale Plätzchen gefunden: Genügend Platz und Ruhe, um UVR16x2, CMI & Co für seine Projekte aufbauen, verkabeln und testen zu können. Fast ideal, wenn man es genau nahm. Denn die Siedler hatten diesem Plätzchen kein LAN gegönnt. Das CMI  – das Control and Monitoring Interface, also das ‚Ethernet-Gateway‘ des Reglers – konnte nicht angeschlossen werden. Damit wäre Irgendwer zurück in die Steinzeit des SD-Karten-Hin-und-Hertragens geworfen worden.

Aber ‚glücklicherweise‘ legten gerade einige ganz besonders fiese Kameras und Videorekorder das halbe Internet lahm – und das elkement erinnerte sich dadurch an eine bereits einmal hier publizierte Anleitung zum Thema: Wie kann man als normaler Windows-Benutzer ohne Hackererfahrung herausfinden, welche Botschaften diese (bösen?) Dinge in die Welt senden und empfangen?

Hier wurde ein von Profis oft belächeltes Feature von Windows genutzt – die so genannte Internetverbindungsfreigabe: Ein normaler Windows-PC kann damit in einen Router verwandelt werden: Der PC verbindet sich wie immer per WLAN ins lokale Siedlernetzwerk – und damit ins Internet. Das ‚Ding‘ wird mit den LAN-Anschluss des PC verbunden und kann die ‚freigebene‘ Internetverbindung nutzen. Nachdem der PC jetzt höchspersönlich alle Netzwerkpakete des Dinges weiterreicht, kann der investigative Benutzer diese auch mit Sniffer-Software auf diesem PC untersuchen.

Aber eigentlich kann man diese Funktion ja einfach so verwenden, wie sie vielleicht gedacht war: Einem WLAN-unfähigen Ding wird eine Brücke ins Internet gebaut.

Aus Klimaschutzgründen wurde natürlich ein ausrangiertes Testnotebook verwendet, dem so ein zweites Leben als wichtiger Router ermöglicht wurde.

Die folgende Grafik zeigt die ‚Netzwerkarchitektur‘:

Netzwerk zum Testen eines CMI mit Regler UVR16x2 in seinem eigenen Subnetz

Der Ethernetanschluss des Laptop-Routers wird von Windows mit der IP-Adresse 192.168.137.1 konfiguriert, sobald die Internetfreigabe aktiviert wurde. Dieser Computer wird zum DHCP-Server und weist dem dem ‚Ding‘ eine dynamische IP-Adresse aus demselben Netzwerk zu, z.B. 192.168.137.2. Der WLAN-Adapter erhält eine Adresse aus dem sonst verwendeten ‚Office‘-Netzwerk (oft: 192.168.0.x)

Für Details zu den Einstellungen am PC siehe den früheren Artikel über das Internet der Dinge. Unter Windows 10 muss/kann jetzt auch die Netzwerkverbindung nicht mehr ausgewählt werden, auf der das Ding sitzt. Kleiner Tipp, bestätigt durch die bewährte Methode ‚Googlen in Foren‘: Wenn unter Windows 10 die Internetverbindungsfreigabe nach einem Neustart nicht mehr funktioniert, muss sie nochmals in den Eigenschaften des WLAN-Adapters deaktiviert und wieder aktiviert werden.

Wie früher schon berichtet wurde, kann so eine Kaskade von Netzwerken auch sinnvoll sein, um ein sensibles Ding (wie den Logger BL-NET) vor einem besonders gesprächigen Ding (IP-TV) zu schützen.

Irgendwer konnte somit wahlweise über das Router-Notebook lokal auf das CMI zugreifen oder über das Internet, also sozusagen bei der Türe raus und beim Fenster wieder rein. Da man vom lokalen ‚Office‘-Netzwerk gar nicht direkt lokal auf das CMI kommt (sondern nur über die ‚Cloud‘), ist das auch halbwegs realistischer Test der späteren Fernwartung über das Internet.

Die Reglerprogrammierung ging damit eigentlich fast schneller als das Aufräumen des Spielplatzes Arbeitsplatzes danach:

irgendein-stilles-plaetzchen-unaufgeraeumt

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

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

 

 

 

UVR1611, BL-NET und die Gefahren des Fernsehkonsums (X-Akten, Teil 3)

Wieder erreichte uns ein Hilferuf eines tapferen UVR1611-Nutzers – die Siedler möchten die Lösung der Weltöffentlichkeit nicht vorenthalten.

Der im letzten X-Akten-Posting angesprochene UVR1611 Data Logger Pro erfreut sich offenbar großer Beliebtheit: Anstelle von Winsol (aber unter Nutzung des gleichen Protokolles) liest diese Anwendung die von BL-NET geloggten Daten in Echtzeit aus – und macht damit die Logging-Funktion und den Webserver des BL-NET überflüssig. Ressourcen-bewusste Siedler möchten ihren lieb gewonnenen BL-NET daher noch lange weiter verwenden, aber was tun in folgendem Fall?

Im schwarz-rot-goldenen Nachbarland bietet ein namhafter rosaroter Fernmeldedienst IP-TV an. Beim Einschalten des TV fühlt sich der BL-NET offenbar bedroht, und fällt in eine Schockstarre, gekennzeichnet durch ein dauerhaft blinkendes Lämpchen.

Folgender Tüftlervorschlag hatte geholfen: Der BL-NET muss in einem eigenen kleinen Subnetz vor dem TV in Schutz gebracht werden – indem man an die LAN-Seite des Internet-Routers einen weiteren Router hängt, und erst an dessen vom Haupt-LAN abgewandte Seite den BL-NET. Damit kann man zwei Fliegen mit einer Klappe schlagen:

  • Als ‚böse‘ eingestuften Netzwerkpakete werden vom BL-NET ferngehalten. Wir vermuten, dass irgendein Multicast / Broadcast-‚Angriff‘ für den BL-NET zu sehr Science Fiction war.
  • Bei unstillbarem Forscherdrang könnte man als Router auch einen PC mit Sniffer-Software installieren und ggf. das böse Paket identifizieren.

Was uns noch nicht ganz gefällt, ist der zusätzliche Energiebedarf für einen weiteren Router. Mögliche Lösungen sind:

  • Einen Internet-Router verwenden, der mehrere virtuelle LANs unterstützt, oder ein ‚Gästenetz‘. (Geschwätzige und vielleicht auch schnüffelnde Dinge im Internet der Dinge auf diese Art abzuschotten wäre generell keine so schlechte Strategie.)
  • Den Server, auf dem die Datenbank für den Logger Pro läuft, mit einer zusätzlichen Netzwerkkarte als Router zu verwenden.

Die Verwendung eines Windows-PCs als Router und Sniffer-Station wurde in diesem Posting beschrieben.

SW Testbild

Damals waren Fernseher noch ungefährlich für die restlichen Geräte im Dumb Home (Bild: Benutzer Dreinagel, Wikimedia)