In the first part we provided a fundamental approach to Scripting and explained how scripts using BASH and XSLT enable particular requirements on data transmission not implemented in the standard firmware. An example served to illustrate this.
We delve deeper into this topic and a specific use case is addressed.
We achieved an implementation of the following requirements on the data transmission in a project with a customer:
A MUC.easyplus is to record the consumption of diverse properties and to transmit these data as CSV files via FTPS to the operator of the energy management and the energy provider.
Both parties run their own FTP server. Both use own meters and insist on preserving data sovereignty. Therefore, the data have to be transmitted to the respective FTP server, specific to the respective operator. As dictated by data protection reasons, the data of one operator must be concealed from the other one.
The transmission of a CSV file via FTPS to two servers is implemented in the standard. However, by default the data of all meters are transmitted to all configured destinations. Thus arose the need for a simple solution to assign the meters to the operator.
The following figure is a graphic illustration:
We implemented this as follows:
The website offers the customer the option to assign a well-defined label to the meter in the meter list. Meters with data to be transmitted to server 1 are given the user label “/1”. Meters with data to be transmitted to server 2 are given the user label “/2”. Data of meters without a specific label are transmitted to both servers. This can be extended to up to 10 report instances. This is a screenshot from the web page.
So far so good. But how are the meter data processed and transmitted to the intended destination server, respecting these conditions? We explain the data transmission and the filtering in a XSLT script.
At the instant of the data transmission, a call is made to the database and its meter data handed over to the XSLT processor via the XSLT script. Filtering the meters according to the report instance and the defined user label requires also the declaration of adhesion to the report instance 1 or 2. The Bash script provides the report instance to the XSLT. We simplified the call a bit for ease of inspection.
<Call to the database> | xsltproc –stringparam srv 1 /mnt/app/report/report.xsl – | <Data transmission via FTPS>
Filtering in XSLT:
Strictly, the filtering is done when creating the file by the XSLT itself. Meter data can be filtered according to the report instance via the parameter “srv”.
<xsl:param name=”srv” select=””” />
- This parameter accepts the value of the variable srv, highlighted yellow above.
- Thus, the value is available for processing in XSLT.
Thereafter, the filtering occurs.
To deepen knowledge, we explain every line of code.
<xsl:template match=”/root/meter”>
<xsl:if test=”not(active) or active != 0″>
- This is a verification whether meters are available and active.
<xsl:variable name=”srv_filter” select=”substring-after(user,’/’)” />
- A variable “srv_filter” is defined.
- The number after the slash in the user label is selected.
<xsl:if test=”$srv_filter = ” or $srv_filter = $srv”>
- This line checks if the variable “srv_filter” is void (no user label assigned).
- Or whether “srv_filter” is equal to the number from the parameter srv (–stringparam srv 1).
- Handing the parameter srv 1 to the XSLT generates a match to the template only if the user label is void or equivalent to “/1”.
- Handing the parameter srv 2 to the XSLT generates a match to the template only if the user label is void or equivalent to “/2”.
<xsl:apply-templates select=”value[not(active) or active != 0]”/>
- All active meter values are added.
This sequence is carried out for all meters. In the sequel, the filtered meter data are transmitted to the respective FTP server.
This is but one of many examples how we achieved the implementation of customer-specific requirements on the data transmission. No modification of the firmware on the device is needed as the scripts are executed at the instant of data transmission. This saves a considerable effort in development and allows us to respond flexibly on customer requirements.
We adapted this form of filtering also for other customers. In these use cases the data had, for example, to be transmitted to server 1 by MQTT.
Do you have special demands, further questions or would like to have more information on scripting or our products? Give us a ring under +49 3677 7613066 or drop us aline via e-mail to sales@solvimus.de. Our sales team is glad to assist you!
