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

Manual (nicht mehr online) – 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. Die Bedeutung der einzelnen Bits wird im Englischen elkementaren Artikel zu diesem Thema beschrieben.

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.

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 (Edit: 2019: Nicht mehr online – Englisches Manual hier) 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 privates Heizungs-Websites im Internet. Wahrscheinlich wurden diese im Gegensatz zu unseren Stichproben zur CMI- oder BL-NET-Website auch absichtlich für anonymen Zugriff konfiguriert – wir wollen sie aber trotzdem hier nicht verlinken.

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.

Online-Schema CMI

Online-Schema, Anzeige durch das CMI

Die Datenkrake

Es soll hier nicht um jene Amerikanischen Datenkraken gehen, die ein F oder G als Logo verwenden.

Fsa09, Datenkrake

Datenkrake als Kunstaktion (Wikimedia-User Nicor)

Nein – es ist die ganz gewöhnliche und harmlos wirkende Datenkrake wie man sie eigentlich in jeder beheizten ’smarten‘ Siedlerhütte finden kann.

Während Chefingenieur Irgendwer erfolgreich verschiedenste Würmer gebändigt hat, versuchte Wissenschaftsoffizier Elkement, die häusliche Datenkrake zu zähmen.

Topiary octopus, Nad lúčkami, Karlova Ves, Bratislava

Unsere Datenkrake ist harmlos und lebt harmonisch im Einklang mit Mensch und Natur – Symbolfoto (Wikimedia-User Doko).

Seit dem denkwürdigen Tag der Inbetriebnahme des Wärmepumpensystems im Oktober 2012 wächst sie unaufhörlich. Viele Postings wären ohne sie nicht möglich gewesen – siehe die Liste der Artikel zu Messdaten und überblicksmäßigen Auswertungen auf unserer neuen ‚Sitemap‘ (…ihrerseits ein Versuch, die Datenkrake dieser Blogartikel zu bändigen).

Zu Beginn hatten die Siedler versucht, die Datenkrake mittels einer Software zu bändigen, die völlig zu Unrecht als Kuchendiagramm-Erstellprogramm für Manager verschrien ist.

Excel ist immer für Sie da!

Neue Erkenntnisse machen Ihre Daten noch wertvoller

(Quelle)

Ja, Excel war immer für uns da und machte unsere Messdatenkrake besonders wertvoll. Aber es hat uns auch verleitet, eine vielköpfige Hydra zu züchten von Formeln, Formeln die auf andere Formeln verweisen, Formeln die auf Formeln verweisen die auf Formeln verweisen.

Nicht zu vergessen: Unsere Freude an der Automatisierung mit Visual Basic for Applications – für Bastler, Tüftler und Dilettanten, bzw.

…Hauptbenutzer von Excel, die noch keine Programmierer sind

(Quelle)

Die Siedler bzw. deren Datenlogger nehmen alle drei Minuten Messwerte auf. Für spezielle Forschungen wie der Analyse des Elementaren Duschvorgangs oder der momentanen Performance der besten Solarkollektoren ist es sinnvoll, diese Daten in noch kürzeren Zeitintervallen zu messen.

Elementares Duschen

Wie oft in den Medien beschrieben liefert ein detailliertes Datenmonitoring des Energieverbrauchs einen perfekten ‚Fingerabdruck‘ des Hausbesitzer-Verhaltens. So exzessiv duscht nur ein Subversives Element (Details in diesem Posting).

Aber einen Überblick über die Leistungsfähigkeit der Anlage erhält man durch die Ermittlung von Kennzahlen für sinnvolle Perioden – wie Monate, Kalenderjahre oder Heizperioden.

So lernte Elkement die Datenkrake mittels automatisch angewandtem Excel-Autofilter auszuwerten. Diese Forschung förderte auch erstaunliche Eigenschaften der Datenkrake zu Tage – wie einen ca. 99%iger Performancegewinn wenn man sich dazu entschließt alle Formatierungen im Rohmessdatenblatt zu löschen.

Aber einige 100 Megabyte später wurde es langsam lästig, diese riesige Krake in ihrem Bau – neuerdings Cloud genannt – artgerecht zu halten.

So begann das Elkement eine Odyssee der Datenanayse und Aufzwirbelung der fraktalen Formelstruktur und folgte dabei seinem geheimen Motto: Das ganze Leben muss sich in einer simplen Textdatei beschreiben lassen. Für den Lebenszyklus der Krake konnte das jetzt realisiert werden: Die virtuelle Krake kann jederzeit neu zum Leben erweckt werden – aus den Originalmessdaten (CSV), die die Logger CMI oder BL-NET liefern. Ein Script – also ebenfalls eine Textdatei – baut daraus eine richtige Datenbank auf.

SQL scripts

Ein für uns ungelöstes Problem des populären Technologie-Journalismus: Wie stellt man Programmcode ansprechend dar? Wir entscheiden uns für den üblichen mysteriösen Matrix-Ansatz. „Das ist der genetische Code der Krake – diese kann damit jederzeit neu geklont werden!“.

Das liebgewonnene Bildchen-Erstellungs-Programm wird weiterhin verwendet – als ‚Frontend‘ für diese Lösung.

Wäre das ein abstraktes akademisches Projekt – dann wäre das einfach gewesen. Aber eine echte lebendige, organisch gewachsene Datenkrake folgt keiner Best-Practice-Datenstruktur. Sensoren messen nicht immer was man möchte, und leider haben wir nur bedingt Gewalt über die nicht immer fehlerfreie künstliche und natürliche Intelligenz sämtlicher beteiligter Lebensformen.

Ja – das ist ein Bug! Da muss eine neue Firmware eingespielt werden!

(Quelle wird aus Diskretionsgründen nicht genannt.)

So muss jedes Datententakel in liebevoller Handarbeit nachgebildet werden, und die Textdatei des Lebens enthält eine Geschichte bizarrer Anweisungen im Stil von:

Wenn Datum zwischen X und Y, dann ist jenes Tentakel doch etwas röter …. äh… ist die Soleeintrittstemperatur um Z°C zu korrigieren.

Wie auch immer: So wie die diversen Ripplinge letzendlich von Irgendwem gebändigt wurden, konnte auch as Elkement der Datenhydra alle hässlichen Köpfe abschlagen – so dass die verbleibende Datenkrake handzahm wurde und uns gute Dienste leistet.

Oder?

Standard Oil Octopus

Ein böser, fossil betriebener ‚Standard Oil Octopus‘. Eventuell sollten gerade wir die Krakenmetapher doch überdenken?

Das Internet der Dinge

Die Siedler betonen gerne, dass sie bodenständige Wissenshandwerker sind, die bezüglich visionären Phrasen eine gesunde Skepsis an den Tag legen.

Gewissen Trends können sie sich dennoch nicht verschließen.

Wer würde nicht wollen, dass der Kühlschrank automatisch Pizza nachbestellt oder PV-Module stolz ihren täglichen Ertrag twittern? All das fällt unter den Begriff Internet der Dinge. Diese Dinge sind oft auf abenteuerliche Weise – gewollt oder ungewollt – mit dem Internet verbunden.

Im Sinne einer realistischen Abschätzung von Sicherheitsrisiko zu Nutzen ist praktische Forschungsarbeit nötig. So führen die Siedler eine minuziöse Untersuchung sämtlicher netzwerkfähiger Dinge in ihrer Siedlerhütte durch. Welches Ding kommuniziert ungefragt mit dem Dem Internet? Und welche Siedlergeheimnisse werden dabei ausgeplaudert?

Entgegen den Klischées in Hacker-Filmen ist es gar nicht so einfach, den Netzwerkverkehr mitzuschnüffeln. Das war einmal, als unsere Netzwerkverkabelung noch mit dem Antennenkabel verwechselt werden konnte:

10base2 t-pieceWehmütig bereuen die Siedler auch, ihren Hub aus dem letzten Jahrtausend entsorgt zu haben. Wie beim Koaxialkabel würde jedes angeschlossene Ding alle von allen anderen Dingen versendeten Netzwerkpakete sehen können.

Heute sind auch im billigsten Internet-Router schon Switches eingebaut. Das Möchtegern-Hacker-Notebook kann dadurch nur noch jene Pakete lesen, die für seine Hardwareadresse bestimmt sind.

Davon lässt sich das Elkement nicht aufhalten – und es hat ein Ziel: Der breiten Öffentlichkeit, also auch dem typischen Windows-Benutzer, zu ermöglichen, die Kommunikation seiner Dinge mitzuverfolgen.

Die Lösung besteht darin, das Ding zu zwingen, mit Dem Internet nur über das Hacker-Notebook zu kommunizieren. Das Notebook wird zum Router; das Ding befindet sich also hinter einer Kaskade von zwei Routern: 1) dem Hacker-Notebook und 2) dem eigentlichen Internet-Router.

Dafür verwenden wir ein wenig bekanntes und wahrscheinlich in Expertenkreisen belächeltes Feature: Die Internetverbindungsfreigabe in Windows.

Ein Router hat mehr als eine Netzwerkkarte und verbindet mindestens zwei (adressmäßig unterschiedliche) Netzwerke.

Ein typisches Laptop hat diese beiden Netzwerkadapter!

  1. WLAN – zur Verbindung mit dem Internet-/WLAN-Router
  2. LAN – eine RJ45-Buchse für ein Ethernetkabel.

(2) wird nun verwendet, um das Ding anzuschließen, bzw. genauer gesagt, ein kleines privates Netzwerk aufzubauen, das nur das Ding enthält. Dafür wird ein ausgekreuztes Kabel verwendet.

Zusätzlich muss eine Sniffer-Software installiert werden, wie z.B. das frei verfügbare  Wireshark.

Ziel ist der folgende Aufbau – in der Darstellung werden der Standard-IP-Adressbereich der Verbindungsfreigabe verwendet (192.168.137.x) und 192.168.0.x als typisches internes Netz:

|     Ding    |       |      Laptop-Router      |      |Internet-Router
|     LAN     |-cross-|     LAN     |    WLAN   |-WLAN-|Internes LAN
|192.168.137.2|       |192.168.137.1|192.168.0.2|      |192.168.0.1

Konfiguration:

  • Eigenschaften des WLAN-Adapters suchen, in Windows 7 unter:
    Systemsteuerung
    –Netzwerk und Internet
    —-Netzwerkstatus und -aufgaben
    ——Adaptereinstellungen ändern
  • In den Eigenschaften des WLAN-Adapters auf Freigabe klicken und anhaken der Option: Anderen Benutzern im Netzwerk gestatten die Internetverbindung dieses Computers zu verwenden.
  • In einem Dropdown-Menü werden alle anderen Adapter außer dem zu teilenden angezeigt – hier wird die Lokale Internetverbindung als privates Netzwerk ausgewählt:

  • Der LAN-Anschluss des Dinges wird über das Crossover-Kabel mit der LAN-Buchse des Laptops verbunden.
  • Wenn das Gerät DHCP verwendet, erhält es automatisch eine IP-Adress aus dem Bereich 192.168.137.x. Wenn nicht, muss eine statische Adresse mit x ungleich 1 vergeben werden. Das Router-Notebook erhält die Adresse 192.168.137.1 und ist  DHCP-Server, DNS-Server, und Default Gateway.
  • Wireshark starten, klick auf Capture, Interfaces…, Auswahl des Adapters mit der Adresse 192.168.137.1 … und … Start!

Ein harmloses Praxisbeispiel – ein Blu-Ray-Player:

Das Ding erhält eine Adresse über DHCP – nur das letzte Paket (‚acknowledge‘) ist hier gezeigt – und versucht dann die MAC-(Hardware-)Adresse für den Router-Computer 192.168.137.1 zu finden – ein DELL-Laptop. Benötigt wird nämlich ein DNS-Server, um einen offenbar hart-kodierten Namen aufzulösen: liveupdate.blurayplayer.samsung.com.

Gut, dass die Kommunikation nicht verschlüsselt ist – sonst könnten wir nicht so einfach mithören.

Mit der Wireshark-Option Follow TCP stream sieht man noch besser, was jetzt passiert:

Der Player ruft die Seite liveupdate.jsp über HTTP auf, schickt die Typenbezeichnung, eine Versionsnummer und den Standort ‚EU‘. Samsung sieht diese Anfrage von der nicht wirklich anonymen IP-Adresse der Siedler in einem kleinen mitteleuropäischen Land kommend.

Samsung antwortet mit [NO UPDATE] und einem Cookie, das bereits vor 3,5 Jahren abgelaufen ist.

Und die Moral aus dieser Geschichte? Nicht, dass es überraschend wäre, dass Geräte versuchen, sich automatisch Updates von einem Server im Internet zu holen. Computer machen das seit ‚ewigen Zeiten‘ – allerdings mit dem ‚feinen‘ Unterschied, dass man hier das Updateverhalten als Besitzer 1) prinzipiell kontrollieren könnte und 2) auch das Mitverfolgen sehr viel einfacher wäre.

Unser Vorschlag für Was gibt es Neues: Das Ding der Woche an seinem Internetraffic zu erkennen!

Logging 2.0 – Wer bastelt mit?

Wochenlang hatten wir vergeblich versucht, in unserem Zwei-Personen-Imperium eine Best-Practices-konforme Projektorganisation hinzubekommen: mit Steering Committee, Projektmanager, Qualitätsmanager, Kick-Off-Meeting, regelmäßigen Conference Calls und dem Sudern[*] über das Alles in der Kaffeeküche.

[*] Info für Besucher aus DE/CH: Lamentieren.

Dann haben wir es doch mit unserem bewährten ‚Can-Do-Approach‘ angepackt – und wir haben das CAN-Bus-Datenlogging unserer LEO_2-Anlage einfach migriert.

Wie bereits berichtet, waren die Siedler treue Nutzer des Datenloggers BL-NET und hatten seine Benutzeroberfläche mit Retro-Appeal liebgewonnen:

BL-Net, Messwerteuebersicht

Übersicht über die aktuellen Messwerte am Datenlogger ‚BL-NET‘

Elkement, Chefparanoiker, war aber kein Fan der Freigabe über Portweiterleitung am eigenen Router. Deshalb konnten die Siedler bisher weder auf Ihren Forschungsreisen von extern auf Ihre Messdaten zugreifen noch anderen Siedlern darauf Zugriff geben.

Das alles geht jetzt – es fehlt nur noch das stylische Tablet!

Wer selbst mitbasteln will – das war die Migration:

Überblick – ‚Executive Summary‘

Das CMI wird so wie der BL-NET in das Netzwerk eingebunden. Beide Geräte werden parallel am CAN-Bus betrieben. In der Logging-Software WinSol wird das CMI als der Haupt-Logger eingestellt. Das Logging über den BL-NET wird als eigener ‚Kunde‘ konfiguriert und bleibt parallel zum CMI erhalten.

Vorher

BL-NET (rechts) ist über den CAN-Bus mit der Regelung UVR1611 (im Heizungsraum, nicht im Bild) und mit dem lokalen Computer-Netzwerk verbunden.

Das CMI (links) wird mit dem Netzwerk verbunden, aber noch nicht mit den CAN-Bus. Daher muss das optionale Netzteil zur Stromversorgung verwendet werden.

CMI und BL-NET

CMI (links) – mit LAN und dem Onlineportal verbunden, aber noch nicht mit dem CAN-Bus. BL-NET (rechts) ist der einzige Logger und terminiert den CAN-Bus.

CMI-Einstellungen

Nach dem ersten Start erhält das CMI eine IP-Adresse vom lokalen DHCP-Server (üblicherweise der Internet-Router) und kann dann über den Aufruf von http://cmi im Internet-Browser über das lokale Netzwerk weiter konfiguriert werden. Der Hinweis in der Bedienungsanleitung ‚zuerst LAN, dann CAN / Power einstecken‘ ist ernst zu nehmen, damit DHCP funktioniert!

Auch die letzte Ziffer der MAC-Adresse wird auf einen Nicht-Standard-Wert gesetzt, da BL-NET und CMI sonst die gleichen MAC-Adressen hätten.

Elkement ändert die Passwörter, dann wird das Logging analog zu den Einstellungen des BL-NET konfiguriert:

CMI, Loggingeinstellungen

Daten werden über den CAN-Bus abgeholt. Die beiden ‚Datensätze‘ werden durch die Reglerprogrammierung definiert und bestimmen, welche Daten in welcher ‚Spalte‘ der Messdatentabelle landen.

An der Logik des Reglers selbst (‚Funktionsdaten‘) wird nichts verändert.

Im CMI-Online-Portal der Technischen Alternative wird ein Benutzer registriert und diesem das eigene CMI durch Angabe von Schlüssel und Seriennummer zugewiesen.

CAN-Bus-Verkabelung

Aus Forschungszwecken soll es möglich sein, auch in Zukunft zwischen den beiden Loggern umschalten können. Sowohl CMI als auch BL-NET sollen parallel Messdaten von der Steuerung UVR1611 abholen können.

(Update 2014-10-20: Technische Alternative rät vom Parallelbetrieb mehrerer Logger ab – es kann zu Störungen kommen. Wie gesagt: Forschungskonfiguration!)

Eine echte Herausforderung für einen Vollbluttheoretiker / IT-Fuzzi wie Elkement: Das CAN-Bus-Kabel muss physisch um eine ‚Station‘ erweitert werden, was die Verwendung von richtigem Werkzeug (Schraubenzieher) für das Anklemmen eines Kabels notwendig macht!

Da die voneinander verschiedenen Standard-CAN-Bus-Adressen aller Geräte beibehalten wurden, gibt es keine Konflikte.

Das CMI wird am Ende des CAN-Busses betrieben – das entspricht der Standardeinstellung des Terminierungsjumpers am Gerät. Der BL-NET befindet sich nun in der Mitte, daher wird der Jumper für die Terminierung auf ‚offen‘ umgesetzt.

CMI und BL-NET gemeinsam am CAN-Bus-nachher

BL-Net (Mitte) bleibt mittels CAN-Bus-Kabel (grau, unteres Kabel am blauen Stecker) mit der Regelung verbunden. Ein zusätzlichees CAN-Kabel (weiß, im Vordergrund) wird an diesem Stecker angeklemmt und mit dem CMI verbunden.

In der Überblicksansicht des CMI sind nun alle CAN-Geräte glücklich vereint:

CAN-Bus: CMI und BL-Net

Übersicht über die Geräte am CAN-Bus – Anzeige am Webportal. CAN-IO wird für die Anbindung zusätzlicher Sensoren benötigt, UVR1611 ist die Regelung. Für das CMI wurde der Hostname geändert um Konflikte mit Kunden-CMIs auszuschließen.

Test des Parallelbetriebs

In der Logging-Software WinSol können eigene Ordner für ‚Kunden‘ erstellt werden – diese Funktion wird für die Umstellung genutzt:

  • Ausgangszustand: Der Hauptordner ‚Eigene Daten‘ wird für Logging mittels BL-NET verwendet. Die Daten werden nach dem Übertragen auf den PC vom Logger gelöscht.
  • CMI-Test: Ein neuer ‚Kunde‘ wird für die CMI-spezifischen Einstellungen und dessen Loggingdaten angelegt – die Daten werden sicherheitshalber nach dem Abholen vom CMI vorerst nicht gelöscht.
  • BL-NET-Test: Die aktuellen BL-NET-Daten werden vom Hauptordner in einen neuen Kundenordner kopiert und die Einstellungen ebenfalls auf ‚Daten nach dem Abholen auf dem BL-NET nicht löschen‘ geändert.

Ausführliche Tests dieser Konfiguration bestätigen: Beide Logger können offenbar parallel Daten abholen! 🙂

Dann wird die letzte Phase gezündet:

  • Das Hauptprofil (‚Eigene Daten‘) wird permanent auf die Verbindung zum CMI umgestellt.
  • Für dieses Profil und das BL-NET-Testprofil werden die Daten wieder nach dem Abholen gelöscht.

Online-Schema

Das Online-Schema für das CMI wird mittels Software TA-Designer erstellt. Die Grafik des Hydraulikschemas konnte vom BL-NET-Schema übernommen werden; die Variablen für die Messwerte wurden im TA-Designer auf der Basis der importierten Funktionsdaten neu zugeordnet.

Hier ist das Ergebnis:

CMI Onlineschema, punktwissen, LEO_2

Onlineschema der Siedler-Anlage, Aufruf über das Webportal.