Skip to main content

M-Bus to LoRaWAN

Integration manual for the ACRIOS Systems converters ACR-CV-1xxL-M-D and ACR-CV-1xxL-M-EAC.

Introduction​

This is the documentation for the ACRIOS Systems M-Bus to LoRaWAN concentrator. The documentation refers to the default Lua script and covers possible configuration options.

Typical Use-Case​

Efficient monitoring and management of heat meters and other M-Bus devices plays a key role in optimization of energy and resource consumption. The integration of the M-Bus to NB-IoT converter presents a solution that allows for quick deployment and seamless connectivity, real-time insights and efficient control.

Key benefits of our devices:

  • Time and Cost Savings: The quick installation process eliminates extensive configuration and wiring efforts, reducing installation time and associated costs.
  • Seamless Integration: The plug-and-play nature of the solution simplifies the integration of heat meters into the district heating network, minimizing disruption to residents.
  • Reliable Communication: The external antenna ensures reliable signal propagation, maintaining consistent communication even in complex urban environments.
  • Real-Time Insights: The solution provides real-time heat consumption data, enabling accurate billing and informed decision-making for energy optimization.

What Is M-Bus?​

M-Bus (Meter-Bus) is a European standard (EN 13757-2 physical and link layer, EN 13757-3 application layer) for the remote reading of water meter, gas or electricity meters. M-Bus is also usable for other types of consumption meters. The M-Bus interface is made for communication on two wires, which is very cost-efficient. There is also a radio variant of M-Bus (Wireless M-Bus), specified in EN 13757-4.

Data on the M-Bus is transferred in telegrams which consist of one or more frames, there must not be any pauses within telegrams, not even after stop bits. M-Bus uses four different telegram formats with following structures:

Single CharacterShort FrameControl FrameLong Frame
E5hStart 10hStart 68hStart 68h
C FieldL Field = 3L Field
A FieldL Field = 3L Field
Check SumStart 68hStart 68h
Stop 16hC FieldC Field
A FieldA Field
CI FieldCI Field
Check SumUser Data (0-252 Byte)
Stop 16hCheck Sum
Stop 16h
warning

When communicating with more meters on the same M-Bus line, it is crucial to provide each slave unit with individual address (A Field). Meter can be addressed by its primary address or by its secondary address.

Primary Addressing:

AddressFunction
0Factory default address.
1-250Addresses that can be assigned to slaves. (Primary addresses)
251-252Reserved for future use.
253Indicates that addressing is performed at the network layer instead. (Secondary addressing procedure)
254Broadcast, meters reply with their addresses. (This causes collision, used for test purposes only.)
255Broadcast, meters do not reply.

The secondary address consists of 4 parts:

  • 4 bytes is the device ID (serial number)
  • 2 bytes is the manufacturer’s identifier
  • 1 byte is the device version
  • 1 byte is the device media

The benefit of secondary addressing is that there is no need to reconfigure meter’s primary addresses and the installation can be navigated only by modifying the converters’ addressing mechanism.

warning

Keep in mind that older M-Bus meters lack secondary addressing because early standards and hardware did not support it. Secondary addressing became widely supported post-2010 as the M-Bus standard evolved and systems scaled in complexity - thus it is safe to assume all models from 2015 and later are compatible. If you encounter issues with older meters, you may need to consider retrofitting or upgrading your network to accommodate modern addressing methods.

Feel free to contact us for possible solutions.

Converter Integration​

Functions​

  • Configurable payload length (default size: 48B)
  • Configurable acknowledged messages with 3 retransmission. If no ACK ⇒ retransmission.
  • Configurable reading period (default interval: 2h 30min)
  • Configurable initial M-bus delay (default length: 2,000 ms)
  • Configurable M-Bus parameters
  • Configurable port
  • Configurable VIF DIF filtering

Out of the Box Behavior​

After connecting the meter to the converter, the device sends a broadcast query by default to address 254 and received data are forwarded to the LoRaWAN network in its original format.

info

If the meter is not responding, the payload “NO DATA RECEIVED” in its HEX format "4E 4F 20 44 41 54 41 20 52 45 43 45 49 56 45 44" is received in the transmission.

To avoid sending longer payloads than allowed by the network depending on the current Spreading Factor, the converter splits the received data by default into the 51B blocks, where the first byte identifies the specific payload and the second byte identifies the total number of payloads. The rest contains the transmitted data.

For example if the whole payload is 240 bytes long, 5 separate LoRaWAN messages are going to be sent:

01 05 XX XX XX…

02 05 XX XX XX…

03 05 XX XX XX…

04 05 XX XX XX…

05 05 XX XX XX…

Read-Out Example Using Engelmann SensoStar U​

From M-Bus meter

00 : 68 B3 B3 68 08 00 72 98 53 85 30 C5 14 00 0A 8D
10 : 10 00 00 04 78 E6 D0 D6 01 04 06 00 00 00 00 04
20 : 13 00 00 00 00 04 2B 00 00 00 00 14 2B 00 00 00
30 : 00 04 3B 00 00 00 00 14 3B 00 00 00 00 02 5B 18
40 : 00 02 5F 18 00 02 61 C9 FF 02 23 B9 00 04 6D 08
50 : 2A FC 28 44 06 00 00 00 00 44 13 00 00 00 00 42
60 : 6C 00 00 01 FD 17 10 03 FD 0C 05 00 00 84 20 06
70 : 00 00 00 00 C4 20 06 00 00 00 00 84 30 06 00 00
80 : 00 00 C4 30 06 00 00 00 00 84 40 13 00 00 00 00
90 : C4 40 13 00 00 00 00 84 80 40 13 00 00 00 00 C4
A0 : 80 40 13 00 00 00 00 84 C0 40 13 00 00 00 00 C4
B0 : C0 40 13 00 00 00 00 95 16

Engelmann SensoStar U with M-Bus module

Device used: Engelmann SensoStar U with M-Bus module

Packet 1 out of 4

00 : 01 04 68 B3 B3 68 08 00 72 98 53 85 30 C5 14 00

10 : 0A 8D 10 00 00 04 78 E6 D0 D6 01 04 06 00 00 00

20 : 00 04 13 00 00 00 00 04 2B 00 00 00 00 14 2B 00

30 : 00 00

Sending Packet 2 out of 4

00 : 02 04 00 04 3B 00 00 00 00 14 3B 00 00 00 00 02

10 : 5B 18 00 02 5F 18 00 02 61 C9 FF 02 23 B9 00 04

20 : 6D 08 2A FC 28 44 06 00 00 00 00 44 13 00 00 00

30 : 00 42

Sending Packet 3 out of 4

00 : 03 04 6C 00 00 01 FD 17 10 03 FD 0C 05 00 00 84

10 : 20 06 00 00 00 00 C4 20 06 00 00 00 00 84 30 06

20 : 00 00 00 00 C4 30 06 00 00 00 00 84 40 13 00 00

30 : 00 00

Sending Packet 4 out of 4

00 : 04 04 C4 40 13 00 00 00 00 84 80 40 13 00 00 00

10 : 00 C4 80 40 13 00 00 00 00 84 C0 40 13 00 00 00

20 : 00 C4 C0 40 13 00 00 00 00 95 16

M-Bus Payload Parsing​

The payload itself is in a form of typical M-Bus frame, including the header. Any M-Bus parser can be used but we recommend using one of the parsers below. Please always check for a possible licensing model.

Here is an example using docker to run libmbus service.

Hardware Used​

  1. ACR-CV-1xxL-M-D - M-Bus to LoRaWAN converter, battery powered
  2. ACR-CV-1xxL-M-EAC - M-Bus to LoRaWAN converter, externally powered

The converter allows connection to any meter or other device equipped with an M-Bus communication.

Hardware Limitations​

  • The hardware allows you to connect up to 5UL. 1UL equals to 1.5mA. Please note that 1UL is not always a representation of 1 meter because some meters may require 2UL or even more. This information can be found in the documentation of the M-Bus meter itself.
  • Do not connect 2 M-Bus masters at once.
info

This is a battery consumption for a device with no VIF/DIF filters, single meter unit, default preheat time of 2 seconds and using a single D-cell battery (double D-cell is also possible, doubling the capacity).

Reading and Sending IntervalEstimated Battery Lifetime
15 min1.7 years
30 min3.9 years
60 min5.2 years

The longer initial delay on the M-Bus line means higher power consumption. This should not affect externally powered version but battery operated versions may suffer from increased power consumption.

In case of a longer M-Bus connection (approximately 380 meters between the meter and converter), a termination resistor (5.5 kohm) is required. This applies only to new generation (NG) of M-Bus converter (the device that allows up to 16 UL), low amount of UL and long connection (for example 380m).

Application Limitations​

  • M-Bus communication has to address individual meters separately when more than one device is connected, either via primary or secondary addressing.
  • LoRaWAN communication requires shortening of payload. Single M-Bus frame can be up to 240 bytes long and you can transfer only up to 222 bytes while using SF7 or SF8. This can be achieved either by filtering VIF DIF values on the hardware level or by splitting an entire telegram into multiple smaller ones.

Device Configuration Using Lua​

Lua scripting language is used to configure our devices. It is an effective tool for dynamic device customization, easy to use but also fit for advanced users, who would like to fully configure their devices.

The default script for M-Bus to LoRaWAN converter can be found on the following link:

https://sw.acrios.com/acrios/acr-cv-lua/-/blob/master/ACR_CV_101L_M_X_lorawanMbus.lua

Configuration of Basic M-Bus Parameters​

Many key parameters of the device can be customized here, such as:

  • Wake-up interval
  • Transmit port
  • Payload size
  • Acknowledged message mechanism
  • And others, please see below:
note

Two dash symbols in Lua allows to comment a code.

--This is a note.
---- CONFIGURATION ----
------- LoRaWAN -------
ack = 0                -- 1 for acknowledged, 0 for non-acknowledged
port = 100             -- transmit port
receiveTimeout = 10000 -- the maximum execution time in milliseconds
payload_size = 48      -- payload size (total message size is 48B payload + 2B header). Maximum payload size with SF12 / DR0 is 51B
------- M-BUS ---------
baudrate = 2400 	-- baudrate: up to 921600 baud
parity = 2		    -- communication parity: 0 for none, 1 for odd and 2 for even parity
stopBits = 1		-- number of stop bits: 1 or 2
dataBits = 8		-- number of data bits: 7 or 8
initialDelay = 2000     -- delay before sending request - some devices require 3000 (Engelmann SensoStar), impacts battery life!
------ Timing ---------
-- device wakeup interval
periodHours = 2
periodMinutes = 30
-- CONFIGURATION END --

Primary Addressing of a Single Meter​

The code needed to configure single meter readout can be found on the line #61 of the default script. By default, the address to which the connected device should answer is address 254.

If the device is not answering, you might want to check the “initialDelay” parameter under the configuration and set it to a higher value. The initialDelay is a time for which the M-Bus is being powered on but with no activity. Some meters require this time to be at least two seconds long but the times may vary (up to six seconds). From our experience the Engelmann devices requires three seconds and the Schneider Electric devices iEM requires up to six seconds.

Example of M-Bus Query - Address 254

  b=pack.pack('<b5', 0x10, 0x7B, 0xFE, (0x7B+0xFE)%256, 0x16)

	status,_,_,_,_,raw = api.mbusTransaction(b,3000,1)

  -- CREATE MBUS QUERY --
    -- MBUS Query is being assembled as described in MBUS protocol documentation. In the example below broadcast adddress 254 (=0xFE) is used.
    -- Documentation https://m-bus.com/documentation-wired/05-data-link-layer
    -- Request for Class 2 Data - REQ_UD2
    -- b=pack.pack('<b5', 0x10, 0x5B, 0xFE, 0x59, 0x16)
    -- 0x10 - Start byte
    -- 0x5B or 0x7B - C-Field - Request for Class 2 Data
      -- 0xFE - Address field
    -- 0x59 - CRC - calculated by (0x7B+0xFE)%256
    -- 0x16 - Stop byte
info

Address 254 is used as an universal broadcast address to which any meter answers. It is effective in such cases, when reading from a single connected meter, because there is no need to deal with primary addressing.

Example of M-Bus Query - Address 1

  b=pack.pack('<b5', 0x10, 0x7B, 0x01, (0x7B+0x01)%256, 0x16)

	status,_,_,_,_,raw = api.mbusTransaction(b,3000,1)

-- CREATE MBUS QUERY --
    -- MBUS Query is being assembled as described in MBUS protocol documentation. In the example below broadcast adddress 254 (=0xFE) is used.
    -- Documentation https://m-bus.com/documentation-wired/05-data-link-layer
    -- Request for Class 2 Data - REQ_UD2
    -- b=pack.pack('<b5', 0x10, 0x5B, 0xFE, 0x59, 0x16)
    -- 0x10 - Start byte
    -- 0x5B or 0x7B - C-Field - Request for Class 2 Data
      -- 0x01 - Address field
    -- 0x59 - CRC - calculated by (0x7B+0x01)%256
    -- 0x16 - Stop byte

Primary Addressing of Multiple Meters​

The device allows you to connect to up to 5UL. 1UL equals to 1.5mA. Please note that 1UL is not always a representation of 1 meter as some meters might require 2UL and in some cases even more. This information should be stated on the documentation of the M-Bus meter itself.

Example of M-Bus Query - Primary Address 1 & 2

-- CREATE MBUS QUERY --

    b1=pack.pack('<b5', 0x10, 0x7B, 0x01, (0x7B+0x01)%256, 0x16)
    b2=pack.pack('<b5', 0x10, 0x7B, 0x02, (0x7B+0x02)%256, 0x16)    --- New line (this one) has to be added

    status,_,_,_,_,raw1 = api.mbusTransaction(b1,3000,1)
    status,_,_,_,_,raw2 = api.mbusTransaction(b2,3000,1)            --- New line (this one) has to be added

    raw = raw1 .. raw2

Read out of Two Meters & Both Answer​

This is a readout of the two connected devices on addresses 0x00 and 0x0B. The data from both of the devices is contained in a single readout and it is possible to filter them by searching for a valid M-Bus frame starting with “68” and ending with “16”.

From M-Bus Meter:

00 : 68 56 56 68 08 0B 72 14 05 00 15 77 04 14 03 37
10 : 30 00 00 0C 78 14 05 00 15 0D 7C 08 44 49 20 2E
20 : 74 73 75 63 0A 37 30 34 33 30 30 42 42 35 31 04
30 : 6D 27 0A FD 28 02 7C 09 65 6D 69 74 20 2E 74 61
40 : 62 F2 08 04 13 CE 00 00 00 04 93 7F 00 00 00 00
50 : 44 13 CE 00 00 00 0F 10 02 1F 87 16 68 B3 B3 68
60 : 08 00 72 98 53 85 30 C5 14 00 0A C5 10 00 00 04
70 : 78 E6 D0 D6 01 04 06 00 00 00 00 04 13 00 00 00
80 : 00 04 2B 00 00 00 00 14 2B 00 00 00 00 04 3B 00
90 : 00 00 00 14 3B 00 00 00 00 02 5B 17 00 02 5F 17
A0 : 00 02 61 0C 00 02 23 BA 00 04 6D 32 28 FD 28 44
B0 : 06 00 00 00 00 44 13 00 00 00 00 42 6C 00 00 01
C0 : FD 17 10 03 FD 0C 05 00 00 84 20 06 00 00 00 00
D0 : C4 20 06 00 00 00 00 84 30 06 00 00 00 00 C4 30
E0 : 06 00 00 00 00 84 40 13 00 00 00 00 C4 40 13 00
F0 : 00 00 00 84 80 40 13 00 00 00 00 C4 80 40 13 00
00 : 00 00 00 84 C0 40 13 00 00 00 00 C4 C0 40 13 00
10 : 00 00 00 39 16

Engelmann SensoStar U &amp; Itron M-Bus Cyble v2.0

Devices used: Engelmann SensoStar U & Itron M-Bus Cyble v2.0

Sending Packet 1 out of 6

00 : 01 06 68 56 56 68 08 0B 72 14 05 00 15 77 04 14

10 : 03 37 30 00 00 0C 78 14 05 00 15 0D 7C 08 44 49

20 : 20 2E 74 73 75 63 0A 37 30 34 33 30 30 42 42 35

30 : 31 04

Sending Packet 2 out of 6

00 : 02 06 6D 27 0A FD 28 02 7C 09 65 6D 69 74 20 2E

10 : 74 61 62 F2 08 04 13 CE 00 00 00 04 93 7F 00 00

20 : 00 00 44 13 CE 00 00 00 0F 10 02 1F 87 16 68 B3

30 : B3 68

Sending Packet 3 out of 6

00 : 03 06 08 00 72 98 53 85 30 C5 14 00 0A C5 10 00

10 : 00 04 78 E6 D0 D6 01 04 06 00 00 00 00 04 13 00

20 : 00 00 00 04 2B 00 00 00 00 14 2B 00 00 00 00 04

30 : 3B 00

Sending Packet 4 out of 6

00 : 04 06 00 00 00 14 3B 00 00 00 00 02 5B 17 00 02

10 : 5F 17 00 02 61 0C 00 02 23 BA 00 04 6D 32 28 FD

20 : 28 44 06 00 00 00 00 44 13 00 00 00 00 42 6C 00

30 : 00 01

Sending Packet 5 out of 6

00 : 05 06 FD 17 10 03 FD 0C 05 00 00 84 20 06 00 00

10 : 00 00 C4 20 06 00 00 00 00 84 30 06 00 00 00 00

20 : C4 30 06 00 00 00 00 84 40 13 00 00 00 00 C4 40

30 : 13 00

Sending Packet 6 out of 6

00 : 06 06 00 00 00 84 80 40 13 00 00 00 00 C4 80 40

10 : 13 00 00 00 00 84 C0 40 13 00 00 00 00 C4 C0 40

20 : 13 00 00 00 00 39 16

Read out of Two Meters & Only One Answers​

This is a readout of the 2 connected devices on addresses 0x00 and 0x0B, but only the data from a single communicating device has been forwarded. It is possible to identify the device by its header within the M-Bus protocol.

From M-Bus Meter:


00 : 68 56 56 68 08 0B 72 14 05 00 15 77 04 14 03 38
10 : 30 00 00 0C 78 14 05 00 15 0D 7C 08 44 49 20 2E
20 : 74 73 75 63 0A 37 30 34 33 30 30 42 42 35 31 04
30 : 6D 30 0A FD 28 02 7C 09 65 6D 69 74 20 2E 74 61
40 : 62 F2 08 04 13 CE 00 00 00 04 93 7F 00 00 00 00
50 : 44 13 CE 00 00 00 0F 10 02 1F 91 16
Itron M-Bus Cyble v2.0
Device used: Itron M-Bus Cyble v2.0

Sending Packet 1 out of 2

00 : 01 02 68 56 56 68 08 0B 72 14 05 00 15 77 04 14

10 : 03 38 30 00 00 0C 78 14 05 00 15 0D 7C 08 44 49

20 : 20 2E 74 73 75 63 0A 37 30 34 33 30 30 42 42 35

30 : 31 04

Sending Packet 2 out of 2

00 : 02 02 6D 30 0A FD 28 02 7C 09 65 6D 69 74 20 2E

10 : 74 61 62 F2 08 04 13 CE 00 00 00 04 93 7F 00 00

20 : 00 00 44 13 CE 00 00 00 0F 10 02 1F 91 16

Read out of Two Meters & None Answers​

This is a readout of the two connected devices on addresses 0x00 and 0x0B. If there is no answer, you are going to receive only following message: “NO DATA RECEIVED”.

From M-Bus Meter:

00 : 01 01 4E 4F 20 44 41 54 41 20 52 45 43 45 49 56
10 : 45 44

4E 4F 20 44 41 54 41 20 52 45 43 45 49 56 45 44 HEX = NO DATA RECEIVED ASCII

Filtering on the Hardware Level​

To avoid sending multiple messages on the LoRaWAN network with each reading, it is possible to filter data on the hardware level. Please note that each of the individual devices may require specific filter definition (depending on the manufacturer).

To do so, the device can shorten the payload by giving it the required VIF and DIF values of the data that needs to be forwarded to the network server. The format of the M-Bus frame will stay unchanged and it is still possible to use any M-Bus parser, but the final payload will be shorter.

The VIF DIF filtering can be applied by uncommenting (removing double dash) the section below:

-- UNCOMMENT BELOW IN CASE OF USING VIF DIF FILTERING
    --api.mbusVifDifFilter("populate",pack.pack("b21",  0x05,         -- 0x05 - number of DIF VIF values
                                       -- 0x03, 0x84, 0x40, 0x06,     -- Energy counter reading - kWh
                                       -- 0x03, 0x84, 0x40, 0x16,     -- Volume counter reading - m3
                                       -- 0x03, 0x85, 0x04, 0x2b,     -- Power [W]
                                       -- 0x03, 0x85, 0x40, 0x3b,     -- Flow [l / h]
                                       -- 0x03, 0x05, 0x83, 0x33))    -- Temperature difference [K]
    -- When applying VIF DIF filter do not forget to uncomment the line 42
    -- Example is taken from device Calec ST 3

Each filter consists of the:

  • 1st byte indicating length of the filter
  • DIF value(s)
  • VIF value(s)

Configuration Example​

This example is taken from the heat meter Engelmann SensoStar U. The goal is to filter following values:

  • Energy
  • Volume counter reading
  • Power
  • Volume flow
  • Temperature difference

Filtering for these values allows the transmission size to be under 51B so only one LoRaWAN message is required.

To do so, we need to configure the VIF DIF filter:

  1. To enable the filtering, uncomment the line #48:

from --api.mbusVifDifFilter("activate", 0) to api.mbusVifDifFilter("activate", 0)

  1. To enable desired functions, uncomment the lines #121 to #126, as seen in example below:
 api.mbusVifDifFilter("populate",pack.pack("b21",  0x05,                      -- 0x05 - number of DIF VIF values
                                                            0x03, 0x84, 0x40, 0x06,     -- Energy counter reading - kWh
                                                            0x03, 0x84, 0x40, 0x16,     -- Volume counter reading - m3
                                                            0x03, 0x85, 0x04, 0x2b,     -- Power [W]
                                                            0x03, 0x85, 0x40, 0x3b,     -- Flow [l / h]
                                                            0x03, 0x05, 0x83, 0x33))    -- Temperature difference [K]
  1. Change the filter to correspond with a VIF DIF values used by the meter, as seen in example below:
api.mbusVifDifFilter("populate",pack.pack("b16",  0x05,                      -- 0x05 - number of DIF VIF values
                                                            0x02, 0x04, 0x06,     -- Energy - Wh
                                                            0x02, 0x04, 0x13,     -- Volume counter reading - m3
                                                            0x02, 0x14, 0x2b,     -- Power [W]
                                                            0x02, 0x4, 0x3b,      -- Volume flow [m3 / h]
                                                            0x02, 0x02, 0x61))    -- Temperature difference [K]
note

Make sure the first byte within the VIF DIF filter is indicating the correct length of the filter, as seen in this example - 0x02, 0x04, 0x13,…

  1. Make sure to check the “b..” value. This specifies the number of bytes within the function and it has to correspond with the number of following bytes.
api.mbusVifDifFilter("populate",pack.pack(**"b16"**, ...

Documentation of this specific function can be found here: https://archive.wiki.acrios.com/en/app_notes/an012

Payload Example​

From M-Bus Meter:

68 2B 2B 68 08 00 72 98 53 85 30 C5 14 00 0A D1 10 00 00 04 06 00 00 00 00 04 13 00 00 00 00 14 2B 00 00 00 00 04 3B 00 00 00 00 02 61 14 00 F4 16

Parsed Data:

ID: 30855398
MAN:EFE
MED:COOL_OUTLET
GEN:0

Identification
Product name Engelmann SensoStar 2
Serial number EFE0030855398
Medium Cool outlet
Generation 0

Values
29.08.2023 09:04 Heating energy 0 Wh
29.08.2023 09:04 Volume 0 m³
29.08.2023 09:04 Power Max 0 W
29.08.2023 09:04 Volume flow 0 m³/h
29.08.2023 09:04 Temperature diff 0,2 °K
interesting

It is possible to get a list of VIF DIF values by using Alexander Miller parser available at https://www.miller-alex.de/Mbus. Turn Expert mode on to enable this functionality.

HEADER

ID: 30855398 MAN:EFE MED:COOL_OUTLET GEN:0 ACC:141 STA:16 SIG:0

RECORDS

DIF:04h (Int32) VIF:78h Data:E6D0D601h FAB number 30855398

DIF:04h (Int32) VIF:06h Data:00000000h Energy 0 Wh

DIF:04h (Int32) VIF:13h Data:00000000h Volume 0 m³

DIF:04h (Int32) VIF:2Bh Data:00000000h Power 0 W

DIF:14h (Int32) VIF:2Bh Data:00000000h Power 0 W Max

DIF:04h (Int32) VIF:3Bh Data:00000000h Volume flow 0 m³/h

DIF:14h (Int32) VIF:3Bh Data:00000000h Volume flow 0 m³/h Max

DIF:02h (Int16) VIF:5Bh Data:1800h Flow temperature 24 °C

DIF:02h (Int16) VIF:5Fh Data:1800h Return temperature 24 °C

DIF:02h (Int16) VIF:61h Data:C9FFh Temperature diff -0.55 °K

DIF:02h (Int16) VIF:23h Data:B900h On time 185000 day

DIF:04h (Int32) VIF:6Dh Data:082AFC28h  28.08.2023 10:08

DIF:44h (Int32) VIF:06h Data:00000000h Energy 0 Wh Storage:1

DIF:44h (Int32) VIF:13h Data:00000000h Volume 0 m³ Storage:1

DIF:42h (Int16) VIF:6Ch Data:0000h  --- Storage:1

DIF:01h (Byte) VIF:FDh VIFE:17h Data:10h Error flags 16

DIF:03h (Int24) VIF:FDh VIFE:0Ch Data:050000h Model 5

DIF:84h (Int32) DIFE:20h VIF:06h Data:00000000h Energy 0 Wh Tariff:2

DIF:C4h (Int32) DIFE:20h VIF:06h Data:00000000h Energy 0 Wh Storage:1 Tariff:2

DIF:84h (Int32) DIFE:30h VIF:06h Data:00000000h Energy 0 Wh Tariff:3

DIF:C4h (Int32) DIFE:30h VIF:06h Data:00000000h Energy 0 Wh Storage:1 Tariff:3

Troubleshooting & FAQ​

Device is not connecting to the Network Server

  • Make sure that the inserted keys are correct, that the device configured in OTAA and check whether the AppEUI is required. If AppEUI is required, please use the same “0” - 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00.

Device is sending unknown payload

  • Please check if the payload is 4E 4F 20 44 41 54 41 20 52 45 43 45 49 56 45 44 - this translates to “NO DATA RECEIVED” in ASCII.

Device is still sending NO DATA RECEIVED

  • Please check if the M-Bus baudrate and parity configuration is correct and if the electrical connection is done properly. You can also try to change parameter “initialDelay” to a larger value as some meters require up to 6 seconds = 6000 ms. Make sure that no more than one device is connected without any prior changes to configuration.

Device is not connecting to the GUI

  • Make sure to use the Chromium based browser, we strongly recommend to use Google Chrome (other Chromium based browsers still may cause unexpected issues). Also make sure that the serial line is not opened in any other serial line monitor.

Device has connected, Lua script was uploaded but it is not possible to connect anymore

  • Make sure the battery has been disconnected for a longer period of time to discharge the capacitor or alternatively short the battery pins on the PCB. Connect two metal pins in the battery connector on the PCB with something conductive (tip of screw driver, paper clip, tip of a pen…). The device can connect only when in bootloader or when it is sleeping. If the device is in the application Lua script and currently running, it will not connect.

Where do I configure the Lua script?

  • Please, make sure to use a Chromium based browser, we strongly recommend to use Google Chrome.

Where can I see a data or serial line log?

  • You can check any serial line monitor such as PuTTy or Termite. Please make sure the serial line monitor configuration is - baud rate: 115 200, data bits: 8, stop bits: 1, parity: none.

I am getting a one-byte answer. What does it mean?

  • The 1-byte answer usually means there is a collision on the M-Bus line. This usually occurs when more than one M-Bus meter is connected and the M-Bus converter is sending a broadcast query on address 254. The exception might be a “0xE5” which is a confirmation from the meter according to M-Bus standard.

I applied VIF DIF filter but I am getting last error traceback in the serial line - what could be wrong?

  • Please check the function api.mbusVifDifFilter and that the specified number of bytes corresponds with actual number of bytes within the function. The byte counter includes the first byte representing number of VIF DIF values.

I want to apply VIF DIF filter but the documentation does not say anything about M-Bus frames. What should I do?

I want to have a possibility to remotely configure hardware and the Lua script. How can I do it?

  • You can either take a look at our documentation that is available at wiki.acrios.com and modify the Lua script by yourself or you can contact our support at support@acrios.com. We are gladly going to point you in the right direction.


Was anything unclear, missing or hard to understand? Please, contact us at support@acrios.com.
Further information can be found on wiki.acrios.com.