CMe3100 Stream Plugin

Product overview

Application description

Within metering, there are many 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.

Solution overview

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.


Stream Plugin - Solution Overview

Considerations for redundancy

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.

Considerations for range and resolution

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.


Uploading a new license file

  1. Log in to the web interface.

  2. Go to System > Licenses.

  3. Select Choose file in the Upload new license file section.

  4. Locate the license file you want to upload.

  5. Select Upload

    The license is now visible in the Current license(s) window.

Activating/deactivating the license

  1. Log in to the web interface.

  2. Go to Dashboard > System panel.

  3. Activate or deactivate the plugin in the Service section.

    1. To activate, toggle Enabled to the right.

    2. To deactivate, toggle Enabled to the left.


Properties for Stream mode

Table 116. 





Filter on device type (HEX) from M-Bus standard.

1B (room sensor)


Filter on manufacturer DLMS description (manufacturer registered acronyme)

ELV (Elvaco)


Filter on which radio modes meter is using.














Baud rate between wireless receiver and CMe3100 USB-interface














URI to push data to


Time interval between each push report

*/15 * * * * (push report for each 15min)

*/15 * * * *


Enable o disable plugin




Enable auto configuration




Show only filtered meters in UI




Time interval between each autoconfiguration attempt

30 0 * * * (sync each night 00:30)


URI to fetch configuration from

Example cad file
Sync-Mode: server
Sync-Id: sm_elv
Sync-Config-0: receiving.server.url=|
Sync-Config-1: receiving.server.push.cron=*/5 * * * *|
Sync-Config-2: configuration.server.cron=15 0 * * *|
Sync-Config-3: filter.manufacturer=ELV,ABB|/currentpluginconfig/stream.cfg
Sync-Config-4: filter.device.type=1B,02|/currentpluginconfig/stream.cfg

Accessing the settings for Stream Plugin

  • Go to Stream > Services > Configuration.

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.

    • Push 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)


Managing configurations

The product feature for managing configurations and backups also include settings for Stream Plugin (see “Manage configurations” section of the Product’s user interface).

Saving a copy of the current configuration

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 file repository section now contains the newly created configuration file. This can then be used to update a device and/or revert erroneous configurations.

  1. Go to Configuration > Manage configurations.

  2. Choose Configuration as file type.

  3. Select Execute.

Importing a saved configuration

  1. Go to Configuration > Manage configurations.

  2. Select Choose File and choose the exported configuration file from the old device.

  3. Select Upload.

Reverting a configuration

  1. Go to Configuration > Manage configurations.

  2. Select the reload icon in the Action column of the configuration to revert to.

Managing backups

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.

Replacing a device

  1. Create a backup of the configuration from the device that should be replaced.

  2. Import the backed up configuration to the replacement device.


The system title of the replacement device will be new since it’s derived from the devices serial number. The HES might need to be updated accordingly.


Setting up a configuration server (http)

This section guides on 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 "OK" in the http body (the body must not be empty).

Product identification in HTTP Post

To identify the product, the HTTP header User-Agent is filled with the following information:

User-Agent=TC65i/<imei> Profile/IMP-NG Configuration/CLDC-1.1 Model/<model> Hardware/<hw> Firmware/<fw> Application/<sw> Serial/<serial>




15 digit product module IMEI number


Product model, i.e. CMe1000, CMe1100, CMe2000, CMe2100


Product hardware version, i.e R4A


Product module firmware version, i.e. 01.100


Product software version, i.e. 1.1.0


10 digit product serial number, i.e. 0006000000

Synchronization file (cad file)

The cad file contains the actual information to synchronize. See the following table for synchronization parameters. All cad files must have the extension .cad.




Synchronization mode, must be set to“server”

Syntax: Sync-Mode: server


Result server URL. Notifications will be sent to this server address. Can be left out.

Syntax: Sync-Notify-URL: <notify 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>


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>


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


Configuration key to set


Configuration key value


User specific identification for this synchronization

Result notifications

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.




Success Synchronization completed successfully.


Incompatible synchronizing mode The Sync-Mode was not set to “server”.


Error synchronizing files. <error> Generic synchronization error.

Responsibilities for receiving head-end system (HES)

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.

Receiving Stream mode reports

HTTP (Hypertext Transfer Protocol) is widely used all over the world. This may be the choice 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).

Stream mode report format

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



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.


The create date of a value

Value data count

The M-Bus telegram in which a value was found.


Meter values (M-Bus raw data)

Table 118. Example of Stream mode report format

(product serial number;device identification;date;value data count;telegram)

(00000161;05047157;YYYY-MM-DD hh:mm:ss;00; 080072640100619615011B000000000C787217006201FD711C0DFD3B616044961564010061011B7A970400202F2F02653607426534078201652C072265320712653607626516075265560702FB1A0E0242FB1A0E028201FB1A0E0222FB1A0E0212FB1A0E0262FB1A090252FB1A0F0202FD1B20C30DFD0F05322E302E310F

Wireless M-Bus to Wired M-Bus 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).

Wireless M-Bus telegrams contained in Wired M-Bus 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

Wireless M-Bus Telegram
Starting with L-Field, CRC-fields removed

Table 120. Wired Mbus telegram

Long header
Id, Man, Version, Device 

Example: 080072640100619615011B000000000C787217006201FD711C0DFD3B616044961564010061011B7A970400202F2F02653607426534078201652C072265320712653607626516075265560702FB1A0E0242FB1A0E028201FB1A0E0222FB1A0E0212FB1A0E0262FB1A090252FB1A0F0202FD1B20C30DFD0F05322E302E310F

Table 121. Example in csv

00000161;05047168;2009-12-17 00:00:00;00; 

Was this article helpful?

0 out of 0 found this helpful
Have more questions? Submit a request

Comments (0 comments)

Article is closed for comments.