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

Jenseits von Pannonien: Die Stunde des Wissenschaftsoffiziers

Wie schnell doch die Zeit vergeht! Ja, es war wirklich schon wieder über ein Jahr her, seit die Bewohner in die Siedlerhütte jenseits von Pannonien eingezogen waren und LEO_2 dort verlässlich für wohlige Wärme sorgte.

Jenseits von Pannonien - Kollektor

Seit über einem Jahr schon wärmte LEO_2 die Bewohner dieser Siedlerhütte jenseits von Pannonien…

Über den Fernwartungszugang hatte Irgendwer zwar immer wieder einen Blick auf den aktuellen Zustand des Wärmepumpensystems geworfen, aber abgesehen davon interessierte ihn inzwischen vielmehr die langfristige Performance der Anlage.

Das erforderte eine eingehende Analyse der laufend aufgezeichneten Monitoring-Daten, was ja prinzipiell keine unbekannte Aufgabe war. In diesem Fall hatte das aber den kleinen aber nicht unwesentlichen Haken, dass die manuelle Ablesung von Zählerständen aus der Entfernung nicht wirklich möglich war. Dadurch fehlten zwei entscheidende Messpunkte zur Bestimmung der Arbeitszahl, nämlich (1) die von der Wärmepumpe erzeugte Wärmeenergie (Ablesen des Wärmemengenzählers der Wärmepumpe) und (2) die von der Wärmepumpe benötigte elektrischen Energie (Ablesen des Stromzählers).

Wie konnte man aber trotzdem aus den automatisch erfassten Monitoring-Daten die Arbeitszahl der Wärmepumpe ermitteln? – Das war eindeutig ein Fall für das El(k)ement, das mit List und Heldenmut auch schon die scheinbar unbezwingbare hauseigene Datenkrake niedergerungen hatte.

JVP-Wärmepumpen-Temperaturen

Die Sole-Eintrittstemperatur und die Wärmepumpen-Vorlauftemperatur wurden jenseits von Pannonien in einem Intervall von ca. 1 Minute permanent aufgezeichnet. Aufgrund einer technischen Panne stehen für den Zeitraum zwischen Mitte August und Mitte Oktober 2015 leider keine Monitoring Daten zur Verfügung.

Nachdem sich das El(k)ement versichert hatte, dass die Messpunkte ‚Wärmepumpen-Vorlauftemperatur‚ und ‚Sole-Eintrittstemperatur‚ in den Monitoring Daten vorhanden waren, verschwand es siegessicher hinter seinem Bildschirm. Dann hörte Irgendwer nur noch das Klappern der Tastatur, gemischt mit einem unverständlichen Programmier-Kauderwelsch und schließlich ein triumphierendes Ha!. – Das untrügliche Zeichen, dass der Wissenschaftsoffizier wieder eines seiner berühmt-berüchtigten ‚Excel-Tools‘ vollendet hatte …

‚Schau her! Ganz einfach …‘

wurde Irgendwem erklärt,

‚Durch einen Polynom-Fit der technischen Daten der Wärmepumpe aus dem Handbuch habe ich die Wärmeleistung, die elektrische Leistungsaufnahme und die Leistungszahl der Wärmepumpe als Funktion der Sole-Eintrittstemperatur und der Wärmepumpen-Vorlauftemperatur ermittelt …‘

Die weiteren Details, die sich Irgendwer geduldig und anerkennend anhörte, sollen dem Leser an dieser Stelle erspart bleiben …

Technische Daten Wärmepumpe

Im Handbuch der Sole-Wasser Wärmepumpe fand das El(k)ement diese technischen Daten in Abhängigkeit von der Sole-Eintrittstemperatur: Die elektrische Leistungsaufnahme (P.EL), die Heizleistung (P.HZ) und die Leistungszahl (LZ). Die Farben kennzeichnen unterschiedliche Wärmepumpen-Vorlauftemperaturen.

Was Irgendwen aber letztlich vollständig von den theoretischen Berechnungen überzeugte, war die überraschend gute Übereinstimmung mit den praktischen Messungen, die das El(k)ement kurzerhand schon an den eigenen Messdaten verifiziert hatte.

Und so konnte Irgendwer schließlich zufrieden auf die Performance-Daten von LEO_2 (‚Jenseits von Pannonien‘) blicken:

JVP-Leistungsdaten-LEO_2

Theoretisch berechnete Leistungsdaten aus tatsächlich gemessenen Temperaturen (Sole-Eintrittstemperatur, Wärmepumpen-Vorlauftemperatur).  Aufgrund der Lücke in den Messdaten-Aufzeichnungen fehlt der September 2015 vollständig. Die Werte für August und Oktober wurden beruhend auf den teilweise vorhandenen Daten ermittelt.

Siedler-Sonnenenergie: Zwischenstand

Einige Monate sind ins Land gegangen, seitdem die Siedler ihr Solarkraftwerk in Betrieb genommen hatten, ihre Zählerlandschaft erweitert und die Messdaten in ihre persönlichen Datenkrake integriert.

Wie sehen ‚die Zahlen‘ aus?

Besondere Tage und Effekte

Der Mai begann vielversprechend: Der absolute tägliche High Score seit der Inbetriebnahme wurde bereits am 11. Mai erzielt. Dagegen war die geringste gemessene Ausbeute an einem verregneten Septembertag eher jämmerlich:

PV: Tage mit max. und min. Ausbeute, Mai-Sept 2015

Der beste Tag: 11.Mai mit einer Ausbeute von fast 33 kWh. Der schlechteste Tag: 25.September bis nicht einmal 1 kWh. AC = Wechselspannung, Output-Leistung. DC = Gleichspannungs-Leistung der beiden Strings – 10 Module Richtung SO, 8 Module Richtung SW, 4,77 kWp insgesamt.

Die höchsten Leistungsspitzen wurden an sonnigen, aber nicht zu heißen, Tagen mit durchziehenden Quellwolken beobachtet – im Datenlogging (Intervall 5 Minuten) finden sich an drei Tagen einige wenige Spitzen mit 4,3 kW:

PV: AC-Leistung 2015-06-21

Typische Leistungsspitzen nahe an der Nennleistung des Wechselrichters (4,5 kW), abwechselnd mit Einbrüchen beim Durchzug von Wolken (Datenlogging Fronius Symo).

Noch weitere Details – und das ‚dramatische Ausmaß‘ dieser Spitzen – wird deutlich, wenn das Logging-Intervall auf 1-2 Sekunden erniedrigt wird:

PV: Leistung, Logging-Intervall 1-2 Sekunden

Leistung beim Durchzug von Wolken. Die Daten wurden einige Stunden lang mit einem Script direkt von der Website des Wechselrichters abgegriffen.

Die besonders hohe Leistung nach dem Durchzug von Wolken wird durch zwei Effekte verursacht:

  • Die ‚Fokussierung‘ von Strahlung (Reflexion oder Brechung) am Rand der Wolken – damit gelangt auf das ‚Loch‘ zwischen den Wolken mehr Strahlung (Details dazu siehe z.B. hier)
  • die zwischenzeitliche Abkühlung der Module, die zu einer Erhöhung des Wirkungsgrades führt.

Ohne Temperatursensor in der Nähe der Module lässt sich nicht sagen, welcher Effekt überwiegt. Generell können die Siedler aber den negativen Effekt sehr hoher Temperaturen qualitativ nachweisen:

Als Referenzwert dient die gemessene Tagessumme der Globalstrahlung auf eine senkrechte nach SO ausgerichtete Fläche. Wir suchen zwei fast perfekte Tage mit gleicher gemessener Referenzstrahlung, mit wenigen Tagen dazwischen (daher geringem Unterschied im Sonnenstand) und sehr unterschiedlichen Temperaturen. Am Tag mit der höheren Lufttemperatur ist die Energieausbeute deutlich geringer:

PV: Vergleich von PV-Ausbeute, Globalstrahlung und Lufttemperaturen.

Vergleich der täglichen PV-Energie-Ernte mit der Globalstrahlung pro m2 auf eine senkrechte nach SO ausgerichtete Fläche und der mittleren und maximalen Lufttemperatur. Mit grün gepunkteten Linien markiert: 1.August und 12.August mit gleichen Globalstrahlungswerten, aber sehr unterschiedlichen Temperaturen und PV-Ernten.

Am 1. August war der Ertrag trotz einigen Wölkchen höher als am 12. August, dem Rekordhitzetag dieses pannonischen Sommers:

PV: Vergleich heißer und kühlerer Tag im August.

An diesen beiden Tage wurde am Kollektor die gleiche Globalstrahlungssumme gemessen. Die Unterschiede in der PV-Leistung können in erster Linie durch die sehr unterschiedlichen Lufttemperaturen erklärt werden. (Logging Symo-Wechselrichter, kombiniert mit Daten UVR1611 / CMI).

Statistik

Zur Beurteilung wie gut die Anlage zum Eigenverbrauch ‚passt‘ kann man den direkt in der Siedlerhütte verbrauchten PV-Strom entweder mit dem eigenen Gesamtverbrauch vergleichen oder der gesamten täglichen PV-Ausbeute:

PV: Direktverbrauch, Netzbezug, Netzeinspeisung monatlich.

Monatsübersichten. Der Mai ist nicht vollständig, da die Anlage mit Zähler erst am 5.5. in Betrieb genommen wurde. Eigenverbrauchsdaten wurden bis Mitte Juni täglich manuell vom ’smarten‘ Zähler des Netzbetreibers abgelesen (Siemens AMIS TD-3511 und ab dann aus dem Logging des eigenen, zusätzlichen (wirklich) smarten Zählers ermittelt (B-Control EM210, Intervall 15 Minuten).

In der Sprache der PV-Kennzahlen: Die Siedler konnten Juni-August 60% ihres Bedarfs ‚direkt von der Sonne‘ decken (Autarkiequote) bei einer Eigenverbrauchsquote von ca. 25%; im September sinkt die Autarkiequote und steigt der Eigenverbrauch:

PV: Autarkiequote vs. Eigenverbrauchsquote

Autarkiequote: PV-Direktbezug zu Siedlerhüttenverbrauch. Eigenverbrauchsquote: PV-Direktbezug zu PV-Ernte.

Dieses Bild wird sich in der Heizsaison schlagartig ändern. Am ‚jämmerlichsten‘ Tag, dem 25. Sept., konnte z.B. eine Eigenverbrauchsquote von 100% erreicht werden, da die Solarausbeute gering war und sich der Herzschlag von LEO_2 an diesem Tag mit dem ersten Heiz-Lebenszeichen bemerkbar gemacht hatte:

PV: September 2015, tägliche Energiebilanz

Wie man aus dieser Darstellung erahnen kann, bieten die Energieverbrauchsdaten auch einen Fingerabdruck des nicht allzu aufsehenerregenden Lebens der Siedler. ‚Aus Sicherheitsgründen‘ werden diese Messdaten daher immer erst nachträglich veröffentlicht. (Na ja, im Voraus wäre es ohne Zeitmaschine ohnehin nicht möglich…)

Im Juli beispielsweise konnten die Siedler während einer dreitägigen Forschungsreise ihrem minimalen täglichen Stromverbrauch ermitteln:

PV: Juli 2015, tägliche Energiebilanz

Die Siedlerhütte hatte tatsächlich täglich 4 kWh benötigt, um sich mit sich selbst zu beschäftigen. Die genaue Analyse und Reduktion dieser Grundlast ist Thema eines neuen Forschungsprojektes und zukünftiger Geschichten.

Die Kunst des Zählens

Es gibt drei Sorten von Menschen:
Die, die zählen können und die anderen.

–Quelle: Das Internet.

Zählen als Kunst und als Handwerk darf wahrlich nicht gering geschätzt werden. Das letzte Technologie-Auswahl-Projekt der Siedler zeigte dies wieder deutlich. In diesem Posting geht es um mehr oder weniger Intelligente Messgeräte zur Erfassung der elektrischen Energieströme zu und von der Siedlerhütte.

Derzeit kennen die Siedler die momentane Ausbeute ihres Kraftwerks genau, aber nicht ihren eigenen Verbrauch. Entsprechend dem ursprünglichem Anforderungskatalog im Projekt Sonne und Wölkchen loggt der Siedler-Wechselrichter alle 5 Minuten Messdaten (auf einen USB-Stick). Die Diagramme in den letzten Postings basieren auf diesen Daten.

Die sprichwörtliche Wankelmütigkeit der erneuerbaren Energie lässt sich veranschaulichen, wenn man in noch kürzeren Zeitabständen die aktuelle Leistung direkt von der Website des Wechselrichter abgreift (Danke, Powershell!) oder eine der anderen offenen Schnittstellen des Wechselrichters verwendet.

PV-Leistung, teilweise Wolken

Leistung nach Messung des Wechselrichters, beim Durchzug von Wolken. Durch die zwischenzeitliche Kühlung der Module fallen die Spitzen besonders hoch aus (4,77 kWp, verteilt auf SO- und SW-Dach)

Aber auch der Stromverbrauch der Siedler ist wankelmütig. Insgeheim hatten sie gehofft, dass ihr neuer elektronischer Zweirichtungszähler (Siemens AMIS TD 3511) die 15-minütigen Messwerte schon in die Smarte Pannonische Cloud speichern würde. Aber: Der Zähler ist Borg, und nur schlau, wenn er an sein Kollektiv angeschlossen ist. Allerdings existiert die entsprechende Infrastruktur (PLC-Datenverbindungen, Datenkonzentratoren in Trafostationen) in Pannonien noch nicht.

Siemens-amis-td-3511-smart-meter

Links der neue Siemens-Zähler (TD-3511); im oberen linken Eck die IR-Schnittstelle.

Nach Jahren des Selbstablesens und Auf-der-Website-Abschickens des Zählerstandes von alten Ferraris-Zählers wurden die Siedler mit dem neuen Zähler wieder zurückgeworfen in eine Ära des Es-kommt-jährlich-irgendwer-ablesen. Dieser Irgendwer (nicht zu verwechseln mit Irgendwem, dem Chefingenieur!) kommt aber mit Hightec-Equipment – einem Infrarot-Lesekopf. Der bedauernswerte neue Zähler ist auch nur eine Zwischenlösung und wird vom Netzbetreiber in einigen Jahren durch einen wirklichen schlauen ersetzt werden.

Womit wir schon mitten in unserer spannenden Forschungsreise durch die Welt der möglichen technischen Lösungen sind, derweil wir noch täglich am Abend manuell die Messwerte vom Display des Zählers ablesen.

Die Anforderungen:

  • Mitloggen des Eigenverbrauchs, mindestens im Abstand von 15 Minuten, entsprechend dem offiziellen Messintervall. Output sollte eine simple CSV-Datei sein, die sich dann auf die bewährte Weise in die Datenkrake der Siedler importieren lässt.
  • Wenn möglich: Erfassung von Daten für die drei Phasen – auch wenn das die Schieflastigkeit der über Jahrzehnte gewachsenen Elektro-Infrastruktur der Siedlerhütte schonungslos demonstrieren wird.
  • Idealerweise mit Option zum ‚Mitschauen‘ in kürzeren Abständen, z.B. um eine Spannungsspitze beim Einschalten eines Gerätes zu verfolgen.
  • Speichern der Daten in einem energiesparenden Logger, also ohne Notwendigkeit, einen ‚Datenerfassungs-PC‘ laufen zu haben.
  • Zugriff über ein auch für Computer-Fuzzis interpretierbares Protokoll – auch wenn es sehr interessant wäre, sich in weitere Protokolle einzuarbeiten.
  • Idealerweise auch über WLAN, also Minimierung der zusätzlich nötigen Verkabelung.
  • Wenn Funkprotokoll, dann möglichst so, dass man dieses nicht 24/7 aktiviviert haben muss, um den Energieverbrauch des Zählers zu optimieren.

Folgende Lösungen hatten die Siedler ins Auge gefasst:

M-Bus-Modul des offiziellen Smart Meters: Der Siemens-AMIS-Zähler (TD-3511) verfügt über die Option, ein Modul für die Datenerfassung über M-Bus anzuschließen. Dieses Modul wurde früher den Kunden im Herkunftsland der Siedler angeboten (Edit 2019: Links / Infos nicht mehr verfügbar). Die Siedler-Steuerung könnte prinzipiell mittels Buskonverter M-Bus auf CAN-Bus umsetzen. Diese Lösung scheitert an zwei Dingen:

IR-Schnittstelle des Zählers: Diese Schnittstelle (IEC 62056-21) wird für Service-Zwecke verwendet, kann aber auch die vom Großen Regulator gewünschte unidirektionale Kundenschnittstelle darstellen. Jener eben erwähnte innovative Netzbetreiber aus der Siedler-Heimat nutzt die IR-Datenausgabe als Kundenschnittstelle und bietet seinen Siedlern hier ein ‚Paket‘ an (Edit 2017: Link zum Paket ging nicht mehr, ersetzt durch archivierte Version).

Siedler aus einem anderen Bundesland müssten die Einzelkomponenten kaufen – Loxone Miniserver Go oder klassischer Loxone Miniserver plus Loxone Air Base Extension, und das Zählerinterface Air. Zur Inbetriebname ist der individuelle Zähler-/Kundenschlüssel nötig; diesen würden die Siedler von Ihrem Pannonischen Netzbetreiber erhalten. Dann müsste noch ein Logging-Baustein konfiguriert werden und der Miniserver wird zum Datenlogger.

  • Vorteil und Versuchung: Endlich wieder in eine neue Steuerungswelt einarbeiten – Spielzeug-Alarm!
  • Nachteil: Eben dieses.

Elektronik-Bastlerei: Genau für den Zähler TD-3511 bietet volkszaehler.org auch eine Anleitung zur Datenkommunikation und zum Selber-Löten der entsprechenden Bauteile. Vor- und Nachteile wie gerade beschrieben, nur krasser (dafür viel billiger).

Das fremdkontrollierte Smart Meter zum Wechselrichter. Jeder Wechselrichterhersteller hat mittlerweile nicht nur eine Cloud, sondern googleartige künstliche Intelligenz (inkl. Konsultation eines Internet-Wetterorakels) und natürlich diverse Apps. Um diese schönen animierten Bildchen vom Energietransport zwischen Wechselrichter, Batterie und Hausnetz anzeigen zu können, muss die App auch die lokalen Eigenverbrauchsdaten kennen. Das wird durch den Einbau eines Smart Meters des Wechselrichterherstellers gelöst, der mit dem Wechselrichter kommuniziert (Z.B.: SMA Smart Meter, Fronius Smart Meter).

  • Vorteil: Logging Zähler integriert mit Logging PV-Erzeugung – im Fall der Siedler am gleichen Logging-USB-Stick, also nur ein CSV-Import, bzw. Nutzung der gleichen sonstigen Schnittstelle am Wechselrichter (wie Modbus TCP)
  • Nachteile: (1) Warum muss die Cloud den Siedler-Eigenverbrauch kennen, der einen Fingerabdruck ihres aufregenden Lebens liefert? (2) Noch ein Kabel vom Wechselrichter zum Zählerkasten, da der Zähler ja unmittelbar hinter dem ‚offiziellen‘ montiert wird.

Glücklicherweise ist es nicht so schwierig herauszufinden, welches OEM-Gerät hinter den ‚re-brand-eten‘ Zählern steckt und so stoßen die Siedler auf diese Variante:

Ein eigenes Smart Meter mit Loggerfunktion misst – unabhängig vom Logger des Wechselrichters – direkt hinter dem dummen schlauen Siemenszähler die eingepeiste und gelieferte Energie auf den drei Phasen und speichert sie lokal in einem Logfile. Diese Datei kann über LAN oder WLAN abgeholt werden.

In der Endauswahl waren folgende Typen – alles Zweirichtungs-Drehstromzähler mit Logging und TCP/IP-Schnittstelle:

  • EM210 von TQ-Systems / B-Control: Daten im Logfile alle Minuten, Echtzeit-‚Mitschauen‘ in höherer Auflösung über eine Website, WLAN und LAN. Allerdings kein Echtzeit-Logging über Protokolle wie Modbus TCP.
  • EM300 von TQ-Systems / B-Control: Gleiches Gerät wie der EM210, aber Echtzeitlogging in konfigurierbaren und viel kleineren Abständen – über Modbus RTU, Modbus TCP. Der Webserver wird nur zur Konfiguration verwendet. Es wäre interesant, Tools wie dieses zu verwenden, aber: Damit muss beim Loggen immer ein PC mitlaufen.
  • EMU Professional mit TCP/IP-Modul: Ähnlicher Funktionsunmfang wie der EM210, aber ohne WLAN (und mit einem Firmenlogo, das die Siedler unmittelbar anspricht). Pluspunkt: die ausführliche Doku der Schnittstelle.

Nach einem langen Auswahlprozess wurde es dann der EM210. Die Siedler sind zuversichtlich, ggf. das fehlende hochaufgelöste Echtzeitlogging über die bewährte Methode ‚Live-Logging-HTTP-Parsen‘ lösen zu können. Trotz aller Begeisterung für hochauslösendes Logging sollte nicht vergessen werden, dass auch der abrechnungsrelevante Zähler einen Lastgang mit 15-Minuten-Werten speichert.

Hier ist er jetzt – mit einem entzückenden Produktnamen!! – und wartet auf seine Installation.

herzstueck-em210_______________________

Der übliche Disclaimer: Die Siedler betreiben keinen Handel mit Elektronik. Die Nennung von Produkt- und Herstellernamen stellt keine Werbung dar und soll aussschließlich anderen Siedlern Recherche-Arbeit ersparen – hier gibt es keine ’sponsored posts‘. Wir recherchieren sorgfältig, sind aber auch nur menschliche Lebensformen: Fehler nicht ausgeschlossen.

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?

BL-NET

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 tatsächlich gleich 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 konnte 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)

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

‚Error!‘ oder: Die Wahrheit ist irgendwo da draußen.

Unser Posting Logging 2.0 – Wer bastelt mit? motiviert andere Siedler zum Basteln – wirft aber auch neue Fragen auf.

Beispielsweise:

„Beim Zugriff auf den BL-NET kommt ein Error…“

Zu Forschungszwecken betreiben die Siedler zwei Datenlogger für einen UVR1611-Regler an einem CAN-Bus – C.M.I. und BL-NET. Die glückliche Gerätefamilie – powered by Technische Alternative – sieht momentan so aus:

CAN-Bus: UVR1611, CMI, BL-NET, CAN-IO, CAN-EZ

Wie können potentielle Fehler systematisch ausgeschlossen werden?

CAN-Bus:

  • Alle Geräte müssen unterschiedliche Knotennummern haben…
  • … und an einem linearen, beidseitig terminierten CAN-Bus hängen. Für wenige Knoten und kurzen Leitungen kann das u.U. etwas liberaler gehandhabt werden – siehe diese Informationen der Technischen Alternative zur werksseitigen Versuchen. (PDF – Manual UVR1611 – S-108). Die Siedler können aufgrund ihrer eigenen tüftlerseitigen Versuche bestätigen, dass sich ein mitten im linearen Bus terminierter UVR1611 nicht negativ auswirkt. Der UVR ist per Default mit einer Steckbrücke auf der Rückseite des Reglers terminiert.
  • Test: CAN-LED am CMI grün?

Ethernet:

  • CMI und BL-NET müssen unterschiedliche IP-Adressen und unterschiedliche MAC-Adressen haben. Mit der neuesten Firmware des CMI wird automatisch eine MAC-Adresse generiert,  die unterschiedlich zur Standard-MAC-Adresse des BL-NET ist. Mit den ersten Versionen war die MAC-Adresse per Default gleich, aber man konnte (musste) sie über die Ethernet-Einstellungen es CMI ändern.
  • Test: Ping zum BL-NET OK, telnet auf Port 80 und 40000 OK?

Im Siedlernetz loggen CMI und BL-NET parallel und erfolgreich nun seit Monaten alle Daten mit. Im Sinne der bekannten Seriosität dieses Blogs ist aber ein Disclaimer angebracht – eine Garantie, dass das überhaupt funktioniert, gibt es nicht. Hier ein Zitat aus den Herstellerinformationen (vor einiger Zeit auch im Logging-2.0-Artikel ergänzt):

„Ein gleichzeitiges Datenlogging mit C.M.I. und BL-Net bzw. D-LOGG ist nicht möglich und führt zu Störungen beim Loggen…“

Und jetzt endlich zum beobachteten Fehler:

Beim Anklicken des BL-NET-Symbols in der CAN-Netz-Übersicht in der CMI-Verwaltung erscheint in der Tat ein Fehler:

BL-NET: Error bei Klick in der CMI-Verwaltung

Mit diesem Fehler hätten die Siedler gerechnet – wobei es schöner wäre, wenn der BL-NET gar nicht klickbar wäre, so wie das CMI-Symbol. Für alle anderen Geräte erscheint beim Klick auf das Symbol das gerätetypische Menü, z.B. für den UVR eine dem Reglermenü nachgebildete Oberfläche:

CMI: Zugriff auf Menü UVR1611

Die etwas weniger coole Weboberfläche des BL-NET bietet prinzipiell die gleichen Möglichkeiten: Auch hier kann jedes andere CAN-Gerät angeklickt werden …

BL-NET: Zugriff auf UVR

… über den Punkt Menüseite laden:

BL-NET: Menüseite UVR geladen

Der BL-NET selbst hat aber kein eigenes Menü in der Art bzw. keine Schnittstelle, über die seine Verwaltung an das CMI ‚weitergeleitet‘ werden könnte. Aber ein Punkt reizt die risikofreudigen Siedler noch … aus Prinzip und weil ein Artikel mit dem Titel „I bricked my BL-NET!“ auch spannend wäre: Ist es eventuell möglich, die Firmware des BL-NET durch Drag&Drop von der SD-Karte des CMI upzudaten (als Alternative zum Memory Manager)? Gesagt, getan: Schritt 1: Ziehen der FRM-Datei Version 2.19 auf die Karte:

BL-NET: Firmware auf SD-Karte des CMI

Schritt 2 … wäre dann, diese Datei auf den BL-NET zu ziehen. Aber wie realistisch war die Annahme, dass die ‚Speicherstellen‘ dann automatisch erkannt würden? Die FRM-Datei wird in der Liste von Funktionsdaten und Firmware-Dateien auf der Karte nicht erkannt.

Aber dafür gibt es extra Geek-Punkte für die Technische Alternative. In der Übersicht über alle Dateien unter ‚Status‘ sind die soeben erzeugten X-Files sichtbar:

BL-NET-Firmware = X-Files für das CMI

 Die Wahrheit ist irgendwo da draußen!

Alien Xing 4889601316

Sonne und Wölkchen

Um dem Image als Rastlose Siedler gerecht zu werden, sind eben diese ständig auf der Suche nach neuen Herausforderungen.

Als Inspiration kam das Blog des Solarzwergs gerade recht: Ein innovativer urbaner Siedler im einsamen Kampf gegen gnadenlose Bürokraten. Das wollten die Pannonischen Siedler auch.

Leider wurden sie bis jetzt enttäuscht, vielleicht auch weil sie sich für die Errichtung eines Solargiganten (vulgo: 5kWp-Photovoltaikanlage) interessieren: Die für die Genehmigung einer netzparallelen Erzeugungsanlage bzw. eines geringfügigen Bauvorhabens zuständigen Amtsstuben erweisen sich überraschenderweise als sehr kundenorientiert.

Nur ein kleines Wölkchen des Zweifels zieht auf – auch Cloud genannt: Die Siedler sind ja bekanntermaßen Logging-Freaks und haben gerne volle Kontrolle über ihre Datenkrake. Eine Recherche verschiedener Smart Energy Management Solutions zeigt, dass das nicht alle Hersteller von Photovoltaik-Wechselrichtern so sehen.

In einschlägigen subversiven Kreisen (vulgo: PV-Freak-Foren) vernimmt man so manche Horrorgeschichte. Batterien wurden durch ein Remote-Firmwareupdate (…. hier gehen uns die Metaphern aus…) lahmgelegt und der dunkle Herrscher über das so genannte Portal musste wochenlang bekniet werden, die zuletzt funktionierende Firmware wieder einzuspielen.

Das 'Portal' ...

Mit gesundem Misstrauen hält Irgendwer Respektabstand zu diesem Portal …

Skeptisch stimmt die Siedler auch, dass das allwissende Portal ihre kompletten Messdaten kennen soll. Das El(k)ement kann sich nur mühsam zurückhalten, die propagierten Lösungen zu testen die irgendwas mit einer Himbeere zu tun haben müssen: Fieserweise könnte man ja versuchen, die für das dunkle Portal bestimmten Daten abzufangen…

Natürlich sind die Siedler verwöhnt von ihren vorhandenen Logging-Spielzeugen und der als selbstverständlich vorausgesetzten Funktion, uneingeschränkt auf die eigenen Daten zuzugreifen, die primär auf einem lokalen Datenträger abgespeichert werden.

Daneben sollten durch den Solargiganten auch folgende Anforderungen erfüllt werden:

  • Die verwinkelte Dachlandschaft der Siedlerhütte soll möglichst optimal zur Energiegewinnung genutzt werden.
  • Die Ernüchterung darüber, dass man zwar einen Solarstrom-Generator besitzt, aber bei Netzausfall dann trotzdem keine elektrische Energie zur Verfügung hat, soll den Siedlern erspart bleiben. Der Chefingenieur würde sich freuen, wenn man dafür keinen Schaltschrank braucht, der Scotty’s Maschinenraum in den Schatten stellt.
  • Trotz hoher Technikaffinität und der Freude über viele Kästchen mit Kabelanschlüssen und bunten Lichtern soll die Anzahl eben jener minimiert werden. Die Siedler hätten ansonsten einen knallgelben Inselwechselrichter (mit SD-Karte zur lokalen Datenablage!) und seinen roten Freund, den Netzwechselrichter, schon fast ins Herz geschlossen gehabt.
  • Auch die Ästhetik darf nicht zu kurz kommen und die Photovoltaik-Module sollen in dezentem Schwarz auch zum Kollektor passen.

Würde nicht konkrete Hoffnung bestehen, dass die Sonne dieses Wölkchen des Zweifels durchbrechen wird, würde es dieses Posting wahrscheinlich nicht geben.

Platz für ein unsichtbares Solarkraftwerk

Selbst wenn es hier ein Solarkraftwerk geben sollte – es wird anderen Siedlern verborgen bleiben.

Fortsetzung folgt…

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.