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.

 

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.

Die Datenkrake – ein Formwandler

Die Siedler sind immer wieder fasziniert von den seltsamen Lebensformen, die sich rund um die Siedlerhütte so tummeln. Auch altbekannte Spezies sind immer wieder für eine Überraschung gut!

Wie wir alle wissen, sind Kraken ja wahre Formwandler:

(…was an ihrem fehlenden Rückgrat liegt – aber soweit wollen wir diese Metapher nicht ausreizen…)

Jedenfalls zeigt auch die hauseigene Krake eine erstaunliche Wandlungsfähigkeit – ein Glück angesichts solcher Herausforderungen:

Wenn Irgendwer mit diversen anderen Lebensformen kämpft, dann vergisst er Zeit, Raum und vor allem dem Wissenschaftsoffizier zu melden, dass sich die Sensorlandschaft der Siedler über Nacht grundlegend verändert. Das Elkement steht dann vor der Herausforderung, der Krake wieder neu beizubringen, wie sie z.B. jetzt erkennen soll, ob die Wärmepumpe gerade läuft oder nicht. Soll man die Anforderung der Wärmepumpe heranziehen? Oder die Anforderung der Solepumpe? Oder doch eine Temperaturdifferenz und den Durchfluss im Solekreis?

Generell erfordert die scheinbar so volksschulmäßig simple Mittelwertbildung einiges an FingerspitzenTentakelgefühl: Abgesehen von Raum- und Außentemperatur sind die meisten Mittelwerte nur sinnvoll in Messintervallen, in denen bestimmte Bedingungen erfüllt sind. In die mittlere Vorlauftemperatur des Heizkreises sollten natürlich nur Werte einfließen, die gemessen wurden während die Heizkreispumpe läuft – andererseits müssen aber die Werte während der sommerlichen Kühlphasen ausgenommen werden. Vor allem muss die Krake lernen, welche Sensorwerte evtl. als Fehler zu werten sind!

Um das Elkement zu verwirrend, fügt Irgendwer aber nicht nur dauernd neue Sensoren hinzu, sondern ändert fieserweise auch die Rollen etablierter Sensoren. So wird schnell einmal eine neue Wandheizung eingebaut und was der (Regelungs-)Welt bisher als Radiatorheizkreis bekannt war, wird nun zu einem neuen Wandheizkreis.

Aber auch das Elkement selbst ist an der ständigen Krakenmutation nicht unschuldig: Während sich Irgendwer lange zufrieden gab mit zwei unterschiedlichen ‚Logging-Quellen‘ – der UVR1611 / UVR16x2 – und einigen manuell gemessenen Werten, hat das Elkement einen Zähler-Zoo herangezüchtet und schreckt nicht davor zurück, die Krake ihre Tentakel direkt in das Innere der Wärmepumpe vordringen zu lassen. All das erzeugt neue Logfiles mit Daten, die zu anderen Zeitpunkten in anderen Zeitintervallen gemessen werden und die von der Krake mit den UVR-Daten verknüpft werden müssen.

Datenkrake: Tentakel in der Wärmepumpe

Insbesondere die früher manuell abgelesenen Daten waren der Krake ganz besonders schwer beizubringen: Irgendwer war zwar ein verwegener Messdatenableser, weigerte sich aber beharrlich, jeden Tag exakt um 00:00:00 Energiewerte aufzunehmen. Da die dumme Wärmepumpe entweder an oder aus ist, macht eine Interpolation der Werte wenig Sinn und das Elkement musste jene erwähnten Mittelwerte für irgendwelche seltsamen Zeitintervalle berechnen.

Aber nicht nur irgendwelche Experimente fordern die Krake heraus: So mancher Hersteller von Steuerungen kommt ja hin und wieder auf die Idee, ’schnell einmal über die Feiertage‘ die Struktur der Loggingdaten mit einem Firmwareupdate durcheinanderzuwirbeln! Die Tentakel der Krake müssen dann bis zum Äußersten gedehnt werden, um die Daten wieder richtig einzusammeln.

Wie regelmäßige Leser dieses ‚Wissenschaftsblogs‘ erahnen werden, muss natürlich jeder dieser Laborversuche ausführlich dokumentiert und nachvollziehbar qualitätsgesichert werden. Gerade bei Tierversuchen gibt es ja sehr strenge Auflagen!

Nach langem Tüfteln – und dem Konsum vieler klischeehafter Filme über künstliche Intelligenz – hat das Elkement jetzt der Datenkrake ein paar weitere Metaebenen verpasst: Die DNA der Krake – also die Beschreibung der Logdateien und Sensoren, wird in einer separaten Vor-Krake abgelegt. Schonungslos wird hier jeder Messfauxpas von Irgendwem dokumentiert: So enthält die Vor-Krake eine Tabelle, in der man Zeitbereiche findet mit Kommentaren wie Irgendwie bastelt und hat versehentlich die Sicherung ausgeschaltet.

Aus der Vor-Krake entsteht dann ‚per Knopfdruck‘ die Große Krake, die automatisch Logdateien in der richtigen Reihenfolge frisst. Nach der Entschlüsselung der Kraken-DNA lässt sich diese auch klonen und frisst auch die CSV-Dateien anderer Siedler.

Nur wenn man diese Vorgeschichte kennt, kann man die kindliche Freude des Elkementes nachvollziehen, wenn die sehr schlichte Benutzeroberfläche dann das Durchklicken der wichtigen Kennwerte für LEO_2-Anlagen erlaubt – für Tage, Monate, Jahre oder Heizsaisonen.

Datenkrake: Excel-Auswertung

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

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!!

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

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

White-Out

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

Wurzelsepp misst

Warten auf das Temperaturgleichgewicht…

Mittlerweile werden fast alle Messdaten automatisch aufgenommen:

Online-Schema CMI/UVR1611/UVR16x2

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

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

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

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

CAN-Erweiterungsboard für Raspberry Pi

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

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

Raspberry Pi mit CAN-Board

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

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

Testumgebung: UVR1611 mit Logger BL-NET

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

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

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

Test Can-Bus: UVR1611 und BL-NET

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

Software und Konfiguration

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

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

Bitrate einstellen

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

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

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

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

CAN-Bus-Netzwerkverkehr mitsniffen mit Wireshark

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

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

_______________________________________________

Weitere Details zur CAN-Kommunikation der UVR1611

UVR1611, CMI und Logging (X-Akten, Teil 2)

Aus der Reihe Leser fragen; das war Teil 1: ‘Error!’ oder: Die Wahrheit ist irgendwo da draußen.

Dieses Mal erreichten uns folgende – zusammen hängende – Fragen ambitionierter Regelungs-Hacker aus dem IT-Bereich:

  1. Das Web-Interface zum CMI sieht etwas altbacken aus – gibt es da einen Webservice, den man anprogrammieren könnte?
  2. Ich habe mir den UVR1611 Data Logger Pro angesehen – was macht jetzt dieser BL-NET und wozu brauche ich den?
  3. Ihr Siedler sagt, ihr greift über das lokale Netzwerk auf das CMI zu – wie wertet ihr die Messdaten aus?

Das Elkement erinnert sich an seine ersten Versuche, mit BL-NET, UVR1611 und später CMI Kontakt aufzunehmen. Für klassische IT-Freaks doch etwas gewöhnungsbedürftig!

Alvim-correa12

Zu 1) Es gibt keinen Webservice. Auf die Logging-Daten beider Logger – BL-NET und CMI kann mittels der TA-Software Winsol zugegriffen werden, d.h. es ist ein Windows-PC oder eine virtuelle Maschine erforderlich. Winsol lädt die Logfiles auf diesen PC. Diese Dateien sind nicht direkt lesbar und werden in Winsol angezeigt bzw. wahlweise auch aus Winsol in Textdateien (CSV) exportiert. Da das CMI eine SD-Karte als Speicher verwendet, braucht dieser – im Vergleich zu BL-NET – auch nur sehr selten ausgeleert werden.

Zu 2) Nach der Beschreibung des UVR1611 Logger Pro (mit dem wir selbst keine Erfahrung haben) wird der BL-NET hier nur als CAN-Ethernet-Gateway verwendet, aber nicht mehr als Logger. Durch das Loggen in eine andere Datenbank wird ebenfalls das Problem des schnell ausgenutzten BL-NET-Datenspeichers umgangen, außerdem lässt sich der Zugriff von extern sicherer konfigurieren.

Man findet bei der Suche nach UVR1611 Logger Pro Heizungs-Websites im Internet, die im Gegensatz zu unseren Stichproben zur CMI- oder BL-NET-Website wahrscheinlich auch absichtlich so konfiguriert wurden – wir aber trotzdem hier nicht verlinken wollen.

Aus dem verwendeten Port (40000 laut Config-Datei) lässt sich schließen, dass der Logger-PC, z.B. Raspberry Pi, das gleiche Protokoll verwendet wie WinSol in der Kommunikation mit BL-NET. Kurzes Sniffen des HTTP-Traffics zwischen einem Winsol-PC und CMI (Port 80) zeigt im Vergleich zum Winsol-BL-NET-Traffic, dass ein anderes Protokoll verwendet wird. Nach den Infos in dieser Diskussion (Stand Dezember 2014) wird das CMI-Protokoll derzeit vom Logger Pro noch nicht unterstützt.

Update im Herbst 2015: CMI wird jetzt vom Logger Pro unterstützt, ebenso UVR16x2.

Zu 3) Was machen wir Siedler? Wir importieren diese CSV-Dateien in unseren SQL-Server, konsolidieren die Daten dort, führen sie mit manuell gemessenen Daten zusammen und berechnen wichtige Kenndaten wie Arbeitszahlen. Alle in diesem Blog gezeigten Plots werden mit Excel als ‚Frontend‘ zu dieser SQL-Datenbank erstellt, aktuelle Daten sehen wir uns einfach in Winsol an. Außerdem arbeiten wir an einer Excel-Auswertung, die die wichtigsten Kennzahlen direkt aus den CSV-Dateien ermittelt.

Auf der Basis der exportierten Logfiles anderer Siedler können wir mittels Winsol Detektivarbeit zu betreiben – unabhängig von deren Logger (CMI oder BL-NET) oder deren Firewall-Einstellungen. Praktisch ist es aber, dass CMI mit der letzten Firmware nun auch das Logging ‚direkt vom Portal‘ unterstützt.

Winsol: Warmwasser-Durchfluss und Speichertemperaturen

Winsol: Durchfluss Warmwasser und Temperaturen (von Warmwasser und Hygienespeicher). Hier ist nicht einmal besondere Detektivarbeit nötig, um zu sehen, dass manche Lebensformen in dieser Siedlerhütte einen wahrhaft elementaren Warmwasser-Verbrauch haben. Beliebige Ausschnitte lassen sich durch ‚Zeichnen eines Rechtecks‘ heranzoomen.

Zusätzlich sind die aktuellen Messdaten auch in unserem Online-Schema über das Webportal cmi.ta.co.at verfügbar – allerdings nicht für anonyme Benutzer. Wir geben unser Schema gerne frei, bitte ggf. um den TA-Benutzernamen an das elektronische Postfach der Siedler unter punkt [ät] punktwissen.at.

Online-Schema CMI

Online-Schema, Anzeige durch das CMI