CMe3100 Stream Plugin
Within metering, there are numerous applications for both Wired M-Bus and Wireless M-Bus. The Stream Plugin is specifically designed to give an efficient solution for metering in large Wireless M-Bus systems where the receiving point is not concerned with the origin of the meter but to create an overall sufficient coverage of an area.
The Stream Plugin is one of the add-ons available for the CMe3100 and is pre-installed from the factory. The Stream Plugin extends the CMe3100 core services with support for Stream over TCP/IP, providing a powerful and versatile suite of tools for Head-end System (HES) integration as well as the possibility to read and monitor any WM-Bus meter.
In a metering system using Stream mode, multiple Stream mode products (receivers) are placed in suitable locations to create coverage for the designated geographical area. All receivers can be used to collect any meter within range. The key benefits with this approach are:
-
Decreased effort for up-front project planning. No radio planning is needed with regards to which meters that should be collected by which receiver.
-
Decreased maintenance effort. No reconfiguration of receiving devices is needed for additions, removal, or replacement of meters.
-
Increased robustness. A system can be designed with redundancy, so any meter is received by multiple receivers. This makes the system robust towards varying radio conditions over time, as for example new buildings or other changes in the area may affect radio performance for specific meters.
To limit up-stream data from received meters that is not of interested (e.g., not part of the system), the Stream Plugin uses filter settings.
To be able to read the last sent telegram from a Wireless M-Bus meter the CMeX50 is forwarding the telegram to the CMe3100 via the USB-interface. The CMe3100 does all logic, filtering and pushing meter data to HES, in a time scheduled interval. After each push of meter data, memory is cleaned, so the CMe3100 will only send the latest values collected between each Push Report interval. If a meter is sending more frequently than scheduled push interval, the CMe3100 will only push the last received meter telegram.
When planning for coverage and redundancy, it is highly advised to assure that every meter has a redundancy factor of at least 2. This means that every meter is within the effective range of at least two receivers. The effective range should be interpreted as meeting the requirements of >X% reception of meter values for the selected resolution. Designing the system this way makes it robust for changes in radio conditions and relaxes the requirement of reception for an individual meter.
It is important to understand that the effective range of the reception area is also a function of resolution. In practice this means that, if it is required to have >98% reception of meter values every 15 minutes, the effective range will be less than if the requirement is >98% reception of meter values every 24 hours. This is not a property of the solution but inherent from how Wireless M-Bus radio works. I.e., the likelihood of properly receiving a distant meter is increasing over time and thus a lower required resolution increases the effective range.
The installation of the plugin is done by uploading a license file and activating the license.
-
Log in to the web interface.
-
Go to System>Licenses.
-
Select Choose file in the Upload new licenses section.
-
Locate the license file you want to upload.
-
Select Upload.
-
Select Save.
The license is now visible in the Current license (s) window.
-
Select System> Reboot device to finalize the installation of the plugin.
Note
Important! Reboot the CMe3100 in order to start using the BACnet plugin.
Table 116.
Parameter |
Description |
Example |
|
---|---|---|---|
filter.device.type |
Filter on device type (HEX) from M-Bus standard. |
1B (room sensor) |
|
filter.manufacturer |
Filter on manufacturer DLMS description (manufacturer registered acronyme) |
ELV (Elvaco) |
|
radio.mode |
Filter on which radio modes meter is using. |
T1_C1A_C1B |
S1 T1 T1_C1A T1_C1B T1_C1A_C1B C1A C1B C1A_C1B C1A_WIDE C1B_WIDE C1A_C1B_WIDE |
usb.baud.rate |
Baud rate between wireless receiver and CMe3100 USB-interface |
115200 |
3600 4800 7200 9600 14400 19200 28800 38400 57600 76800 115200 |
receiving.server.url |
URI to push data to |
http://evo.elvaco.se |
|
receiving.server.push.cron |
Time interval between each Push Report |
*/15 * * * * (Push Report for each 15min) |
*/15 * * * * |
service.enabled |
Enable o disable plugin |
true |
true/false |
sync.enabled |
Enable auto configuration |
true |
true/false |
show.only.filtered |
Show only filtered meters in UI |
true |
true/false |
configuration.server.cron |
Time interval between each autoconfiguration attempt |
30 0 * * * (sync each night 00:30) |
|
configuration.server.url |
URI to fetch configuration from |
http://middleware.elvaco.se |
Sync-Mode: server Sync-Id: sm_elv Sync-Config-0: receiving.server.url=http://evo.elvaco.se/sp/| /currentpluginconfig/stream.cfg Sync-Config-1: receiving.server.push.cron=*/5 * * * *| /currentpluginconfig/stream.cfg Sync-Config-2: configuration.server.cron=15 0 * * *| /currentpluginconfig/stream.cfg Sync-Config-3: filter.manufacturer=ELV,ABB|/currentpluginconfig/stream.cfg Sync-Config-4: filter.device.type=1B,02|/currentpluginconfig/stream.cfg
The default selected tab in the settings for Stream Plugin is the Overview page which shows general information about the Stream Plugin.
Available pages are:
-
Settings
General Stream configuration for the Plugin.
-
Receiving server address
Address of the server receiving Push Reports from Stream plug-in.
-
Psuh Schedule
Schedule for the Push Report to receiving server.
-
Filter on manufacturer
Filter on manufacturer DLMS short name, e.g., ELV.
-
Filter on device type
Filter on device type. This filter is using the M-Bus standard medium description (13757-3 2004), e.g., 07 is water.
-
Allow list
Filter on device identities, list the device identities that should be accepted, the device identities that are not listed will not be accepted.
-
-
Analyzer
Analysis of incoming data from CMeX50 with Stream Mode software.
The analyzer tool shows which devices that has been received based on set filters, which can improve analysis of where to place receivers geographically depending on which device you want to receive data from. Meter ID, number of received telegrams, signal strength, manufacturer and meter type is shown.
There is an option to display only allow-listed devices in the analyzer tool. If this option is selected but no devices are whitelisted in settings tab, this filter will not be applied, and all received devices will be listed. There are also options for export the analyzer statistics into CSV format and reset the analyzer statistics.
The analyzer resets every 24 hours or if the user manually resets the function in the user interface.
-
Help
Descriptions of the Stream Plugin, linking to this document.
-
End-user license agreement (EULA)
The product's feature for managing configurations and backups also include settings for Stream Plugin (see Manage configurations section of the product’s user interface).
The configuration contains all properties that can be edited in the Product. These can be used to duplicate configuration to several devices since they do not contain any device specific settings.
The backup contains configuration as well as a copy of the Products databases and operation system settings.
This backup contains device specific settings and is therefore not suitable for replicating configuration to another device, it should only be used to restore a device’s settings after a physical replacement.
This section describes how to connect to a product configuration server (http protocol). The synchronization starts with CMe product requesting a synchronization file. The synchronization file contains parameters to synchronize files and configuration keys to set in the product. When the synchronization of files and configuration are complete (or incomplete), the product will send a result to a specified result server. The result server can be specified in the cad file.
If using a web service that generates the cad file or if a result server is used, the server must respond with HTTP Response Code = 200 and OKin the http body (the body must not be empty).
To identify the product, the HTTP header User-Agent is filled with the following information:
User-Agenet=TC65i/<imei> Profile/IMP-NG Configuration/CLDC-1.1 Model/<model> Hardware/<hw> Firmware/<fw> Application/<sw> Serial/<serial>
Parameter |
Description |
---|---|
<imei> |
15 digit product module IMEI number |
<model> |
Product model, i.e. CMe1000, CMe1100, CMe2000, CMe2100 |
<hw> |
Product hardware version, i.e R4A |
<fw> |
Product module firmware version, i.e. 01.100 |
<sw> |
Product software version, i.e. 1.1.0 |
<serial> |
10 digit product serial number, i.e. 0006000000 |
The cad file contains the actual information to synchronize. See the following table for synchronization parameters. All cad files must have the extension .cad.
Parameter |
Description |
---|---|
Sync-Mode |
Synchronization mode, must be set to server Syntax: Sync-Mode: server |
Sync-Notify-URL |
Result server URL. Notifications will be sent to this server address. Can be left out. Syntax: Sync-Notify-URL: <notify url> |
Sync-File-[0..n]-URL |
Files to synchronize. The index must start at 0 and be continuous. Can be left out. Syntax: Sync-File-[0..n]-URL: <remoteur>,<local file> |
Sync-Config-[0..n] |
Configuration keys and values to synchronize. The index must start at 0 and be continuous. Can be left out. Syntax: Sync- Config-[0..n]:<key>=<value> |
Sync-Id |
Identification which will be parsed into the result notification. Can be left out. Syntax: Sync-Id: <id> |
<notify url> |
URL where to post notifications |
<remote file> |
URL where to get remote file |
<local file> |
Local path and filename where to put downloaded file |
<key> |
Configuration key to set |
<value> |
Configuration key value |
<id> |
User specific identification for this synchronization |
If the parameter Sync-Notify-Url is set in the cad file, the product will post result information to given URL. The post is a standard HTTP post with a body containing the result information. See possible results in the following table.
Result |
Description |
---|---|
900 |
Success Synchronization completed successfully. |
920 |
Incompatible synchronizing mode The Sync-Mode was not set to server. |
921 |
Error synchronizing files. <error> Generic synchronization error. |
While Stream mode units provide an effective collection service, the receiving system needs to take care of the following:
-
Handle redundancy
As multiple meters can be received by multiple receives, the HES needs to handle duplicates and the fact that meter values from the same meter can be received from multiple receivers.
-
Decoding, key management, and decryption (if encrypted meters are used)
The metering data from Stream mode is send as raw M-Bus. This means that if meters are transmitting encrypted data this needs to be decrypted with associated proper key management before the M-Bus meter data can be decoded.
HTTP (Hypertext Transfer Protocol) is widely used all over the world. This may be the protocol to use when the integration platform has an external web server available. The product is using HTTP POST to send data to the server.
The product follows the standard for an HTTP server. It is important to have matching authentication settings in the product and receiving server.
The product must be configured where to send the HTTP reports, which can be set using command qset http, see CMe Series User's Manual. Username, password, port and URL can also be set using the command qset http. HTTPS can be used for securing the connection, which is accomplished by entering https instead of http in the URL of the web server.
The reports sent from the product to the web server are created on the fly, thereby the content length of the post is unknown when the HTTP headers are sent. Thus, the receiving web server must handle chunked transfer encoding (this is normally not an issue when using Microsoft IIS or Apache web server, where chunked transfer encoding is handled automatically).
The Stream mode report format is taken from the standard M-Bus EN13757. The following table is describing the report format properties:
Table 117. Properties of the stream mode report format
Name |
Description |
---|---|
Product serial-number |
The product serial number which has read and stored the value of a meter. |
Device identification |
The M-Bus slave secondary identification which a value belongs to. |
Date |
The create date of a value |
Value data count |
The M-Bus telegram in which a value was found. |
Telegram |
Meter values (M-Bus raw data) |
Table 118. Example of Stream mode report format
(product serial number;device identification;date;value data count;telegram) |
|||
---|---|---|---|
|
This section describes how data is mapped from the received wireless M-Bus telegram to the wired M-Bus telegram. The wired secondary address is taken from the M-Field and A-Field from the wireless M-Bus telegram. The wired A-Field is automatically assigned upon installation. The short header information received in the wireless M-Bus telegram is not used on the wired M-Bus interface.
The DIF/VIF container description is identified by the following DIF/VIF data:
0x0D 0xFD 0x3B 0xnn |
Where 0xnn is the length of the complete wireless M-Bus telegram (length of the container). |
The wireless M-Bus telegram should be placed in an M-Bus container if one or more of the following criteria are met:
C- and CI-Field are unknown to the product
Table 119. Wireless M-Bus telegram
|
Table 120. Wired M-Bus telegram
|
|
|
|
|
|
|
Example 1. Example
Filename=0016002896_valuereport_20190924185507_9102.csv Content encoding: System.Text.UTF8Encoding Content type: application/octet-stream Content length: 27741 Body: 0016002896;18400910;2019-09-24 18:52:42;00;0800721009401897A60016190000A004130E000000066D2C385278290044130E000000426C5F2C047F0700060C027F852A0E79100940180000 0016002896;61000134;2019-09-24 18:51:35;00;080072340100619615011B8B0400202F2F0265EE084265DD08820165F1082265D6081265EE086265B20852656A0902FB1AC30142FB1AC3018201FB1A8D0122FB1AC30112FB1AC30162FB1A660152FB1AC30102FD1B60430DFD0F05302E302E310F
Example 2. Example in CSV
00000161;05047168;2009-12-17 00:00:00;00; 080072640100619615011B000000000C787217006201FD711C0DFD3B61604496156401006 1011B7A970400202F2F02653607426534078201652C072265320712653607626516075265 560702FB1A0E0242FB1A0E028201FB1A0E0222FB1A0E0212FB1A0E0262FB1A090252FB1A0 F0202FD1B20C30DFD0F05322E302E310F
Comments (0 comments)