Introduction

IoTSyS serves as a middleware integration platform for the Internet of Things. It offers a communication stack for embedded devices utilizing IPv6, Web services, and oBIX to offer compatible interfaces for smart objects. The main goal of the IoTSyS middleware is to offer a gateway solution for current sensor and actuator systems used in modern home and building automation systems (such as KNX, BACnet, ZigBee, and Wireless M-Bus). This stack can be installed directly on embedded 6LoWPAN devices and also deals with security, discovery, and scalability challenges.

This connector enhances IoTSyS through the utilization of the M-Bus (Meter Bus) standard. Hence, modifications have been made to the Wireless M-Bus API to simplify communication with the meters. A M-Bus connector was developed for IoTSyS to utilize this API. A piggyback board called M-Bus-Master was developed for Raspberry Pi to use as a target platform for IoTSyS.

M-Bus Protocol Overview

The M-Bus standard is defined in EN 13757-2 (physical and link layer) and EN 13757-3 (application layer). A detailed description is available at the official M-Bus homepage {1}.

The M-Bus was created to address the demand for a network system that allows for remote reading of utility meters, such as tracking gas or water usage in households. This bus meets the specific needs of devices powered from a distance or with batteries, such as household utility meters. During questioning, the meters transfer their gathered data to a central controller, like a portable computer, that is periodically connected to collect information from all utility meters in a building.
{1}

Physical Layer

The M-Bus functions in a hierarchical manner, where a master controls communication. The M-Bus is made up of the master, multiple slaves (end-equipment meters), and a two-wire connection cable. The slaves are linked together in parallel to the transmission medium.

A two-wire cable was utilized in conjunction with serial data transfer to create a cost-effective extensive bus network. To enable remote powering of the slaves, the bits on the bus are shown in the following manner:

Voltage level shifts are utilized to transfer bits from a master to a slave. A digital signal of “1” signifies a voltage of +36V at the bus driver’s output. Conversely, a signal of “0” results in a voltage of +24V at the output of the bus driver. Modulating the slave’s current consumption encodes bits sent from slave to master. A constant current of up to 1.5mA represents a logical “1,” while an increase in the current drain of 11-20mA by the slave represents a logical “0” (Space). The signal state known as “mark” can provide power to the interface, as well as potentially to the meter or sensor.

Data Link Layer

The physical layer requires specific requirements from the data link layer. In addition to half-duplex asynchronous serial communication at speeds from 300 to 9600 Baud, these specifications involve ensuring every eleventh bit is a logical 1 and utilizing a Master-Slave setup due to the inability of slaves to communicate among themselves. The data link layer protocol follows the IEC 870-5 international standard, outlining transmission protocols for telecontrol equipment and systems. The M-Bus protocol mentioned above is based on the standard but does not utilize all the IEC functions.

Transmission Parameters

This procedure employs asynchronous serial data transmission, utilizing start and stop bits for synchronization of each character. No breaks should occur in a telegram, even following a stop bit. Because a 1 (Mark) corresponds to quiescence on the line, the start bit should be a Space and the stop bit should be a Mark. The even parity bit is placed between the eight data bits to guarantee that every eleventh bit is a Mark. The data bits are sent in increasing order, meaning the least significant bit (LSB) is the initial bit on the line. The communication occurs in half-duplex with a minimum data rate of 300 Baud.

Telegram Format

Within the M-Bus specification, there exist three distinct telegram formats that can be identified by specific start characters. The telegram formats for the M-Bus will be described in the table provided below.

Single Character	Short Frame	Control Frame	Long Frame
E5h	Start 10h	Start 68h	Start 68h
	C Field	L Field	L Field
	A Field	L Field	L Field
	Check Sum	Start 68h	Start 68h
	Stop 16 h	C Field	C Field
		A Field	A Field
		CI Field	CI Field
		Check Sum	User Data (0-252 Byte)
		Stop16h	Check Sum
			Stop16h

Single Character: This format consists of a single character, which the E5h (decimal 229), and serves to acknowledge receipt of transmissions.

Short Frame: This frame with a fixed length begins with the start character 10h, and besides the C and A fields includes the checksum (this is made up from the two last mentioned characters), and the stop character 16h.

Long Frame: With the long frame, after the start character 68h, the length field (L field) is first transmitted twice, followed by the start character once again. After this, there follow the function field (C field), the address field (A field) and the control information field (CI field). The L field gives the quantity of the user data inputs plus 3 (for C,A,CI). After the user data inputs, the check sum is transmitted, which is built up over the same area as the length field, and in conclusion the stop character 16h is transmitted.

Control Frame: The control sentence conforms to the long sentence without user data, with an L field from the contents of 3. The check sum is calculated at this point from the fields C, A and CI.

Meaning of the Fields

C Field: The following table shows the function codes used in the calling and the replying directions:

Name	Hex Value	Telegram	Description
SND_NKE	40	Short Frame	Initialization of Slave
SND_UD	53/73	Long/Control Frame	Send User Data to Slave
REQ_UD2	5B/7B	Short Frame	Request for Class 2 Data
REQ_UD1	5A/7A	Short Frame	Request for Class1 Data
RSP_UD	08/18/28/38	Long/Control Frame	Data Transfer from Slave to Master after Request

A Field: The address (A) field is used to address a slave in the calling direction and to identify the sender of information in the receiving direction. The addresses 1 to 250 can be allocated to the individual slaves, up to a maximum of 250. The address 0 is reserved for unconfigured slaves and the addresses 254 and 255 are used for broadcasts.

CI Field: The control information (CI) field is already a part of the Application Layer, and is described in more detail in section Application Layer. It is used to distinguish between the formats of the long and the control frames. The control information allows the implementation of a variety of actions in the master or the slaves.

Check Sum: The Check Sum is used to recognize transmission and synchronization faults. The Check Sum is calculated from the arithmetical sum of the data mentioned above without taking carry digits into account.

Communication Process

The Data Link Layer uses the two kinds of transmission services Send/Confirm (SND/CON) and Request/Respond (REQ/RSP).

Send/Confirm Procedures:

SND_NKE → Single control character This procedure is used to start up after the interruption or beginning of communication. The slave responds to a correctly received SND_NKE with an acknowledgment using of a single character (E5h).

SND_UD → Single control character With this procedure the master sends user data to the slave. The slave can either confirm the correct receipt of data with a single character acknowledge (E5h), or by omitting a confirmation signal that it did not receive the telegram correctly.

Request/Respond Procedures:

REQ_UD2 → RSP_UD The master requests data from the slave according to Class 2. The slave can either transfer its data with RSP_UD, or give no response indicating that the REQ_UD2 telegram has not been received correctly or that the address contained in the REQ_UD2 telegram does not match.

Application Layer

The standardized application protocol for data exchange with heat meters is specified in the standard EN1434-3. This standard can also be used for other types of consumer utility meters, such as those for gas and water. On the contrary, EN1434-3 specifically addresses the data format in responses, while the typical data format from the master to the slave will be discussed in this document.

The CI field represents how data is transferred between the master and slave in a specific mode. There are two options for transferring requested data from a slave to a master: fixed data structure and variable data structure.

The setup of slave devices is determined in this layer as well, but will not be discussed here, as M-Bus meters are exclusively accessed with IoTSyS.

Fixed Data Structure

Two distinct data structures are employed when sending a long frame in the opposite direction. The data structure that is fixed in length can only transmit two counter states of a predetermined length, which are encoded in binary or BCD. On the other hand, the variable data structure enables the conveying of additional counter states in different codes and additional valuable information about the data. The size of the transmitted counter states can vary as well with this data structure. In contrast to the fixed layout, the variable layout can also function in the calling direction. For these reasons, the use of a fixed data structure is not advised for upcoming projects.

The frame of the fixed data structure is shown in the following table:

Identification No.	Access No.	Status	Medium/Unit	Counter 1	Counter 2
4 Byte	1 Byte	1 Byte	2 Byte	4 Byte	4 Byte

Variable Data Structure

The frame of the variable data structure is shown in the table below:

Fixed Data Header	Variable Data Blocks (Records)	MDH	Mfg.specific data
12 Byte	variable number	1 Byte	variable number

Fixed Data Header:

The first twelve bytes of the user data consist of a block with a fixed length and structure :

Ident. Nr.	Manufr.	Version	Medium	Access No.	Status	Signature
4 Byte	2 Byte	1 Byte	1 Byte	1 Byte	1 Byte	2 Byte

Variable Data Blocks:

Each data record contains one value with its description as shown in the table below, a data record, which consists of a data record header (DRH) and the actual data. The DRH in turn consists of the DIB (data information block) to describe the length, type and coding of the data, and the VIB (value information block) to give the value of the unit and the multiplier.

| DIF | DIFE | VIF | VIFE | Data | |:—-|:—–|:—-|:—–|:—–| | 1 Byte | 0-10 (1 Byte each) | 1 Byte 0-10 | (1 Byte each) | 0-N Byte |

The DIB contains at least one byte (DIF, data information field), and can be extended by a maximum of ten DIFE’s (data information field extensions). After a DIF or DIFE without a set extension bit there follows the VIB (value information block). This consists at least of the VIF (value information field) and can be expanded with a maximum of 10 extensions (VIFE). The VIF and also the VIFE’s show with a set MSB that a VIFE will follow. In the value information field VIF the other seven bits give the unit and the multiplier of the transmitted value. The meaning of the multiplier can be look up in the M-Bus standard {1}.

Manufacturer Specific Data Block:

The manufacturer specific data block consists of the manufacturer data header (MDH) and manufacturer specific data. This can’t be encoded because it depends on the manufacturer how this part of frame structure looks like.

Example: Slave Read Out

Master sends a request (REQ_UD2) for reading data of slave with address 1: 10 7B 01 7C 16

Encoded request send from master to slave with address 1: 10 Start: Short frame 7B C-Feld: REQ_UD2: 01FV 1011 = 4B/5B/6B/7B: Request for Class 2 Data 01 A-Feld : primary address = 1 7C Checksum 16 Stop

Received data from slave with address 1: 68 6A 6A 68 08 01 72 43 53 93 07 65 32 10 04 CA 00 00 00 0C 05 14 00 00 00 0C 13 13 20 00 00 0B 22 01 24 03 04 6D 12 0B D3 12 32 6C 00 00 0C 78 43 53 93 07 06 FD 0C F2 03 01 00 F6 01 0D FD 0B 05 31 32 4D 46 57 01 FD 0E 00 4C 05 14 00 00 00 4C 13 13 20 00 00 42 6C BF 1C 0F 37 FD 17 00 00 00 00 00 00 00 00 02 7A 25 00 02 78 25 00 3A 16

Encoded data from slave with address 1: 68 Start : STart of telegram, Long or control frame 6A L-Feld : Length of user data plus 3
6A L-Feld : Length of user data plus 3 68 Start : 2. Start 08 C-Feld : RSP_UD 01 A-Feld : primary address = 1 Begin user data: 72 CI-Feld : variable data structure, Mode 1 Fixed data block: 43 53 93 07 Identification#= 07935343 65 32 Manufacturer = 3265h equals LSE 10 04 Version = 10 Medium = Heat CA 00 Access number = CA Status = 00h 00 00 Signatur = 00 00h 1.Datenrecord: 0C DIF: 8 digit BCD 05 VIF: E0000nnn = Energy 10^(nnn-3) Wh = 0.001Wh to 10000Wh: 10^(5-3) Wh = 100 Wh 14 00 00 00 date = 14 * 100 Wh = 1.4 kWh 2.Datenrecord: 0C DIF: 8 digit BCD 13 VIF: E0010nnn = Volume 10(nnn-6) m3 = 0.001l to 10000l: 10^(3-6) m3 = 10^-3 m3 = 1l 13 20 00 00 date = 2013 * 1l = 2013 l 3.Datenrecord: 0B DIF: 6 digit BCD 22 VIF: E010 00nn On Time: nn = 00 seconds, 01 minutes, 10 hours, 11 days 01 24 03 date = 032401 hours 4.Datenrecord: 04 DIF: 32 Bit Integer 6D VIF: E110110n: Time Point n = 0 date = data type G, n = 1 time & date = data type F 12 0B D3 12 date: Type F = Compound CP32: Date and Time: 5.Datenrecord: 32 DIF: 16 Bit Integer, fehlerbehaftet 6C VIF: E110110n Time Point n = 0 = data type G 00 00 date: Type F = Compound CP32: Date and Time: 6.Datenrecord: 0C DIF: 8 digit BCD 78 VIF: E110110n Time Point n = 0 = data type G 43 53 93 07 date: E111 1000 Fabrication No 07935343 7.Datenrecord: 06 DIF: 48 Bit Integer FD VIF: 1111 1101 Extension of VIF-codes true VIF is given in the first VIFE and is coded using table 8.4.4 a) 0C VIFE: E000 1100 Model / Version F2 03 01 00 F6 01 date: Model / Version 01F6000103F2h = 2156073649138 8.Datenrecord: 0D DIF: variable Länge FD VIF: 1111 1101 Extension of VIF-codes true VIF is given in the first VIFE and is coded using table 8.4.4 a) 0B VIFE: E000 1011 Parameter set identification 05 LVAR: ASCII string with LVAR characters, Länge 5 31 32 4D 46 57 date: 57 46 4D 32 31 = WFM21 9.Datenrecord: 01 DIF: 8 bit Integer FD VIF: 1111 1101 Extension of VIF-codes true VIF is given in the first VIFE and is coded using table 8.4.4 a) 0E VIFE: E000 1110 Firmware version # 00 date: 0 10.Datenrecord: 4C DIF: 8 digit BCD, LSB of storage number 1 05 VIF: E0000nnn = Energy 10^(nnn-3) Wh = 0.001Wh to 10000Wh: 10^(5-3) Wh = 100 Wh 14 00 00 00 date = 14 * 100 Wh = 1.4 kWh 11.Datenrecord: 4C DIF: 8 digit BCD, LSB of storage number 1 13 VIF: E0010nnn = Volume 10(nnn-6) m3 = 0.001l to 10000l: 10^(3-6) m3 = 10^-3 m3 = 1l 13 20 00 00 date = 2013 * 1l = 2013 l 12.Datenrecord: 42 DIF: 16 Bit Integer, LSB of storage number 1 6C VIF: E110110n Time Point n = 0 = data type G BF 1C date: Type F = Compound CP32: Date and Time: 13.Datenrecord: 0F DIF: special function 37 FD 17 00 00 00 00 00 00 00 00 02 7A 25 00 02 78 25 00 manufacturer specific data 3A Checksum 16 Stop

M-Bus Java API

The M-Bus Java Api is shown as class diagram in the picture below:

Class diagramm: https://jschober88-mbus.googlecode.com/hg/iotsys-mbus/doc/MBus.png’ />

The class MBusConnector is used to create a new instance of the class ComPortReader, which handles the serial communication with the M-Bus master. To initialize the ComPortReader correctly there are a some useful methods in the class MBusConnector: * connect(): Creates a new instance of ComPortReader and open a serial connection. * disconnect(): Closes the serial connection. * setInterval(): Sets the periodic reading interval of the meters. * setAdress(): Sets the address of the meter. * refresh(): Forces a start of the read out procedure of a meter.

If the ComPortReader receives a new telegram, it is added to a TelgramManager. The class Telegram represents the data structure of a M-Bus long frame. Therefore, Telegram is split into TelegramHeader (representing the fields start, L, C, A, CI, check sum and stop) and the and TelegramBody (representing the user data).

The TelegramBody can be split furthermore as seen in section Data Link Layer into the TelegramBody header representing the fixed data header and the TelegramBodyPayload representing the variable data blocks, which can be again differentiated in the following fields: * DIFTelegramField * DIFETelegramField * VIFTelegramField * VIFETelegramField

The information of all data fields is encoded using the tables of the appendix of the M-Bus documentation {1}. For debugging the class Telegram and all the related classes have a method debugOutput() to print the encoded data to the console.

Connection and Device Configuration

For the connection you need to specify the serial port of the Raspberry Pi (see UART configuration). Further, the serial number and the address of the meter and polling interval need to be specified.

“` MBus Smart Meter Linux true /dev/ttyS80 at.ac.tuwien.auto.iotsys.gateway.obix.objects.iot.sensors.impl.mbus.SmartMeterImplMBus 01 60 07935343 smartmeter true 1000

MBus Smart Meter Windows false COM17 at.ac.tuwien.auto.iotsys.gateway.obix.objects.iot.sensors.impl.mbus.SmartMeterImplMBus 60 01 07935343 smartmeter true 1000 “`

M-Bus-Master for Raspberry Pi

A design for a basic M-Bus-Master with the capacity for up to 3 slaves {2} was implemented to establish a master for the M-Bus. This design needed to be expanded as the Raspberry Pi lacks an RS232 port, which is essential for the M-Bus-Master. This teacher is located to the right in the image shown. The M-Bus-Master functions with a power voltage of plus or minus 15V. The output voltages provided by the Raspberry Pi are limited to only 3.3V and 5V. Therefore, a DC/DC converter IH0515S {3} from XP POWER company was utilized to change the 5V Raspberry Pi output to +15V and -15V, with a maximum output current of 66mA for each. The Mini M-Bus-Master can support up to 3 slaves as each slave consumes 12mA to 20mA, ensuring adequate output currents.

The Raspberry Pi GPIO (TXD GPIO14 and RXD GPIO15) voltage levels are 3.3V and therefore, a MAX3232 has to be used to operate correctly with the M-Bus-Master input and output, which uses the RS232 voltage levels of +/-12V.

https://jschober88-mbus.googlecode.com/hg/iotsys-mbus/doc/MBus-Master_Circuit_BW.png’ />

https://jschober88-mbus.googlecode.com/hg/iotsys-mbus/doc/MBus-Master_Board.png’ />

Raspberry Pi

UART

In order to use the dedicated UART pins on the Raspberry Pi, first they have to be removed from their default application which is debugging. To do this edit “/boot/cmdline.txt” and “/etc/inittab” {4}. This files should be backuped to make it possible to return to the default configuration: cp /boot/cmdline.txt /boot/cmdline.bak cp /etc/inittab /etc/inittab.bak

Remove “console=ttyAMA0,115200” and “kgdboc=ttyAMA0,115200” configuration parameters from the “/boot/cmdline.txt” configuration file using nano editor. nano /boot/cmdline.txt

Comment the last line on the “/etc/inittab” file. Put a ‘#’ before “T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100. nano /etc/inittab

Now the RXD (GPIO15) and TXD (GPIO14) pins are available for general UART use.

To use the Raspberry Pi UART interface with the Java RXTX library one more step is required. A symbolic link the serial port (UART) has to be created: sudo ln -s /dev/ttyAMA0 /dev/ttyS80

For more detail: MBusConnector