Im ersten Teil haben wir einen grundlegenden Einstieg in das Thema Scripting gegeben und erklärt, wie wir spezielle Anforderungen an den Datenversand, welche im Standardumfang der Firmware nicht umsetzbar sind, mittels BASH- und XSLT-Skripten lösen können. Das Ganze haben wir an einem kurzen Beispiel gezeigt.
Dieses Thema möchten wir in diesem Beitrag weiter vertiefen und an einem konkreten Anwendungsfall zeigen.
Folgende Anforderung an den Datenversand haben wir in einem Entwicklungsprojekt mit dem Kunden lösen können:
Ein MUC.easyplus erfasst die Verbräuche verschiedener Liegenschaften und soll diese Daten als CSV-Datei per FTPS an den Betreiber des Energiemanagements und den Energieversorger übermitteln.
Beide Parteien betreiben jeweils einen eigenen FTP-Server. Beide nutzen unterschiedliche Zähler und wollen Datenhoheit behalten. Daher müssen je nach Betreiber die Daten auf den jeweiligen FTP-Server übertragen werden. Die Daten des einen Betreibers dürfen aus Datenschutzgründen nicht durch den anderen eingesehen werden.
Die Übertragung einer CSV-Datei per FTPS an zwei Server ist im Standard umsetzbar. Allerdings übermitteln wir standardmäßig die Daten aller Zähler an alle konfigurierten Gegenstellen.
Somit musste eine Lösung her, wie wir es dem Kunden komfortabel ermöglichen können, diese Zuordnung der Zähler vorzunehmen.
Das soll die folgende Skizze nochmal verdeutlichen und visualisieren:
Wir haben das folgendermaßen lösen können:
Der Kunde kann über die Gerätewebseite in der Zählerliste dem Zähler eine festdefinierte Bezeichnung zuweisen. Zähler, die zum Server 1 geschickt werden sollen, müssen das user label „/1“ erhalten. Zähler, die zum Server 2 geschickt werden sollen, müssen das user label „/2“ erhalten. Zähler ohne Zuweisung werden an beide Server geschickt. Das könnte man auf bis zu 10 Report-Instanzen erweitern. Auf der Gerätewebseite sieht das dann so aus.
So weit so gut. Doch wie werden nun die Zählerdaten mithilfe dieser Angabe verarbeitet und an den richtigen Server geschickt?
Hierzu erklären wir den Ablauf beim Datenversand und die Filterung im XSLT-Script.
Zum Zeitpunkt des Datenversands wird ein Datenbankaufruf ausgeführt und dessen Zählerdaten dem XSLT-Prozessor mit dem XSLT-Script übergeben. Um nun die Zähler entsprechend der Reportinstanz und des eingetragenen User labels zu filtern, muss die Information, ob Reportinstanz 1 oder 2, ebenfalls übergeben werden. Im Bash-Script wird dem XSLT die Information der Reportinstanz übergeben. Wir haben den Aufruf aus Gründen der Übersichtlichkeit etwas vereinfacht.
<Datenbankaufruf> | xsltproc –stringparam srv 1 /mnt/app/report/report.xsl – | <Datenversand per FTPS>
Filterung im XSLT:
Die eigentliche Filterung geschieht beim Erstellen der Datei durch das XSLT selbst. Über den Parameter „srv“ lassen sich die Zählerdaten entsprechend der Reportinstanz filtern.
<xsl:param name=“srv“ select=“““ />
- Dieser Parameter übernimmt den oben gelb markierten Wert der Variable srv
- Somit ist der Wert zur Verarbeitung im XSLT verfügbar.
Anschließend folgt die eigentliche Filterung.
Zum Verständnis erklären wir jede Zeile.
<xsl:template match=“/root/meter“>
<xsl:if test=“not(active) or active != 0″>
- Es wird überprüft, ob Zähler vorhanden und aktiv sind.
<xsl:variable name=“srv_filter“ select=“substring-after(user,’/‘)“ />
- Es wird eine Variable „srv_filter“ definiert.
- Die Zahl nach dem Slash aus dem User label wird ausgewählt.
<xsl:if test=“$srv_filter = “ or $srv_filter = $srv“>
- Diese Zeile prüft, ob die Variable „srv_filter“ leer ist (Kein User label vergeben).
- Oder ob „srv_filter“ gleich der Zahl aus dem Parameter srv (–stringparam srv 1) ist.
- Wird also dem XSLT der Parameter srv 1 übergeben, matcht das Template nur, wenn das User label leer ist oder eine „/1“ eingetragen ist.
- Wird dem XSLT der Parameter srv 2 übergeben, matcht das Template nur, wenn das User label leer ist oder eine „/2“ eingetragen ist.
<xsl:apply-templates select=“value[not(active) or active != 0]“/>
- Alle aktiven Zählerwerte werden hinzugefügt
Diese Abfolge wird für alle Zähler durchgeführt. Anschließend werden die gefilterten Zählerdaten an den entsprechenden FTP-Server übertragen.
Dies war nur eines von vielen Beispielen, wie wir kundenspezifische Anforderungen an den Datenversand realisieren können. Da die erwähnten Scripte zum Zeitpunkt des Datenversands ausgeführt werden, ist hierfür keine Anpassung der Firmware des Gerätes notwendig. Das erspart uns einiges an Entwicklungsaufwand und lässt uns flexibel auf Kundenwünsche reagieren.
Wir haben gemeinsam mit anderen Kunden diese Form der Filterung erneut verwendet und angepasst. Hierbei sollten zum Beispiel die Daten an Server 1 per MQTT gesendet werden.
Haben Sie eine besondere Herausforderung, weitere Fragen oder möchten mehr Informationen zum Thema Scripting oder unseren Produkten? Dann rufen Sie uns gern unter +49 3677 7613066 an oder schreiben Sie uns eine E-Mail an sales@solvimus.de. Unser Vertrieb berät Sie gern!
