This application note will guide you in process of adding the new WMBus slave device when you know the device address. The first step will be focused on the format of the WMBUS slave address, then the confirmation via scan function will be done and in the last step, the converter will be set up for remote readings of one Qundis Q caloric 5.5.
This application note is based on a Wireless M-Bus NB-IoT converter ACR-CV-101N-W-D together with Qundis caloric 5.5 - Link to the datasheet. Another accessory you may need is a configuration cable “ACR-CONFIG” and a serial line monitor running on your laptop.
Qundis Q caloric is an electronic device for recording the share of heat output by radiators.The Q caloric 5.5 is the successor model to the tried-and-trusted Q caloric 5. In addition to improved energy management, the Q caloric 5.5 can be operated in different wireless modes. In terms of measuring technology, the Q caloric 5.5 is 100% compatible to the Q caloric 5. Installation instructions can be taken over from the Q caloric 5 without changes being necessary. - Source
In our case, the Qundis Q caloric 5.5 is configured as walk-by & OMC in C-mode. You can see the setup of your device on the built-in screen. For this particular setup, the FC-4.2 code appears.
As shown in the picture above, the device address is “92198717” and we will search for this number in the scan function of the ACR-CV Wireless M-bus converter.
Application note setup - Q caloric 5.5 + ACR-CV-101N-W-D Wireless MBus converter
NOTE :Some Q caloric 5.5 units can be configured in a way, that they transmit WMBus frame only the first 45 days of the year. Those frames can be read only the first 45 days of the year! Please, make sure you have your Qundis configured properly to send WMBus frames once every X minutes.
This step is not necessary and serves only to provide us with proof of communication on the side of the WMBUS slave. Since some calorimeters can be configured in a way, that transmits only in a specific time period, this step can be useful to determine whether the device transmits or not.
Connect the ACR-CV converter via ACR-CONFIG cable and run the Acrios GUI on your computer. What you want to do, is to change the default LUA script to the one with the scan function enabled. Closer information can be found HERE.
Run the serial line monitor with a device connected to the PC and search for ID of your Qundis Q caloric 5.5. In our case, it is 92198717. The answer will look similar to the one below:
05:13:01:
BOOTLOADER v1.3
............................
starting...
[00]
05:13:05: SYS: date / time - 2016/01/01 / 00:00:02
SYS: build date / time - Oct 20 2020 / 10:01:43
05:13:07: SYS: configuration mode entered
05:13:11: SYS: configuration mode exited
LUA: starting lua script version 1
LUA: Starting onStartup() script
~>Starting up WMBUS scan and save script!
WMBUS: Setting power to 10 dBm
LUA: purge WMBUS filter
~>--- SCAN 60 ---
05:13:26: WMBUS: RSSI = -80 dBm
~>Adding 19854733 number 0
~>RAW DATA:
00 : 4C 44 B4 09 33 47 85 19 15 07 7A 2D 08 00 00 0C
10 : 13 05 66 09 00 04 6D 0A 2F 48 2A 0F 97 0A 18 25
20 : 24 18 10 04 07 00 00 00 00 00 00 00 00 00 00 00
30 : 00 00 00 00 09 00 00 85 08 00 24 0B 00 CF 0D 00
40 : 56 19 00 00 00 00 00 00 00 00 00 00 00
05:13:34: WMBUS: RSSI = -20 dBm
~>Adding 92198717 number 1
~>RAW DATA:
00 : 31 44 93 44 17 87 19 92 34 08 7A D1 18 00 20 0B
10 : 6E 07 00 00 4B 6E 00 00 00 42 6C 7F 2C CB 08 6E
20 : 07 00 00 C2 08 6C 9F 2A 32 6C 69 2B 04 6D 15 0E
30 : 82 2B
05:13:48: WMBUS: RSSI = -68 dBm
~>Adding 443320 number 2
~>RAW DATA:
00 : 6E 44 01 06 20 33 44 00 05 07 7A 3C 00 60 85 3B
10 : 30 AD 1D 08 B6 0B 5D E1 B6 1F EC F6 9B A4 D0 12
20 : C3 6C 0F C9 09 C4 6B 5A 0B E8 E8 5C 82 AA DA 66
30 : 7A 79 6D 95 72 4A 00 98 C7 04 A4 60 67 59 2E E4
40 : 91 09 E5 CC 47 27 24 A5 AF 5C 42 EA 19 42 D8 9E
50 : 31 93 3B 8E AE DF A9 9F 24 08 9E 76 66 C2 4B AA
60 : 7C 16 69 1F C2 6A 23 2A B7 A5 7A 03 58 E1 BA
We can see that our device ID was scanned as the second one and the “ID 1” was assigned.
From now on, the device is already assigned to lot 2 as “ID 1”. If we change the LUA script back to the default one and install the converter to the designated place, we will get the information about the dev ID - 19854733, 92198717 (the one we want) and 443320.
The way the default scanning LUA script works is, that once it finds any unique device address it will add it as the address that will be read repeatedly. To avoid this, we can scan for the IDs, confirm that our Qundis Q cal 5.5 is communicating, and then upload the default LUA script with our device address specified once more. This way, we will get readings only from the devices we want to have readings from.
This step allows you to import a list of device addresses that need to be read.
Connect the ACR-CV converter via ACR-CONFIG cable and run the Acrios GUI on your computer. If you have the default script already on the device, open the “Interactive console” and click on the “Debug ON”. If you don't have the default script on your device, load one from HERE.
Interactive console with debug mode on
By sending a chunk of code, the new device address can be written into the memory of ACR-CV converter.
The Wireless M-Bus address must be written in HEX format, in little-endian, and split by bytes.
You can do it either manually or use some of the tools available. For example, you can use our own JavaScript HERE.
IMPORTANT - Q Caloric 5.5 has device addresses already written on them in HEX! Do NOT convert the device address into HEX format. Our JavaScript is not suitable for this application, but it may be very helpful with other devices. For Qundis, only write down bytes in little-endian.
In the interactive console, you can send a chunk of code (the right window). Send the address you got above as:
filter = ""
filter = filter .. string.char(0x17, 0x87, 0x19, 0x92)
filterLength = #filter/4
api.wmbusFilter("populate", filter)
You will get the answer:
~> filter = "" filter = filter .. string.char(0x17, 0x87, 0x19, 0x92)
filterLength = #filter/4
api.wmbusFilter("populate", filter)
LUA: populate WMBUS filter
LUA: WMBUS FILTER 01: ID 92198717
This means, that the new filter was set and your device address got the ID.
In case you need to write more device addresses, you can use the same example and only copy “filter = filter .. string.char(0x17, 0x87, 0x19, 0x92)” for each address you need to add.
Close the configuration GUI and open the serial line monitor to check, if everything was done successfully. What we will be searching for is the WMBUS filter and check, whether our address was added or not. Then we want to check the communication itself and if the device was read correctly.
Let's connect the configuration cable, open the serial line monitor and see whether the setup was done successfully or not. The serial line monitor will allow us to see the status at each step.
00: [00]
BOOTLOADER v1.3
....
01: ........................
starting...
[00]
03: SYS: date / time - 2020/11/02 / 16:28:16
SYS: build date / time - Oct 20 2020 / 10:01:43
06: SYS: configuration mode entered
10: SYS: configuration mode exited
LUA: starting lua script version 1
LUA: Starting onStartup() script
~>Starting up WMBUS to NBIOT script, V1.3
11: NBIOT: New MCGDEFCONT - 'nb.m2mc'
NBIOT: New PLMNID - 23003
LUA: fetch WMBUS filter
LUA: WMBUS FILTER 01: ID 92198717
WMBUS: Setting power to 10 dBm
LUA: destroyed all lua objects, exiting
14: NBIOT: Initializing the module...
NBIOT: Received AT response, module is up!
NBIOT: Received SIM card is present and ready!
NBIOT: MCGDEFCONT set to - 'nb.m2mc'
NBIOT: PLMNID set to - '23003'
22: NBIOT: Registered to roaming network
24: NBIOT: Got time from network
NBIOT: Setting time date...
NBIOT: Connected to IP network!
NBIOT: Time is 15:28:38+04
NBIOT: module setup done successfully!
SYS: --- New request ---
SYS: Battery Voltage: 3639 mV
LUA: starting lua script version 1
LUA: Starting onWake() script
~>Filter length: 1
01:08: WMBUS: RSSI = -25 dBm
~>Received valid wMBUS frame...
~>Upload data from node 1 to NBIOT. (1/1)
00 : 01 49 44 93 44 17 87 19 92 34 08 78 0D FF 5F 35
10 : 00 82 E3 18 00 EE 00 07 B0 6E 69 2B 07 00 00 00
20 : 7F 2C 00 00 00 00 9F 2A 07 00 00 00 00 00 00 00
30 : 00 00 00 00 07 00 00 00 00 00 00 00 00 00 00 00
40 : 00 00 00 00 2F 04 6D 2A 10 82 2B
NBIOT: wake the module up!
01:10: NBIOT: wake the module up!
01:21: NBIOT: No return data
~>Received data from all meters, sleeping.......
SYS: date / time - 2020/11/02 / 16:29:34
SYS: wake up at day / time - 02 / 16:34:34
LUA: destroyed all lua objects, exiting
SYS: entering sleep mode
[00]
As seen above, the WMBUS converter has booted up, opened the RX window, and once it got the data from our meters (in our case from only 1 meter), it sent the data over NB-IoT and went back to sleep. The period of how often the WMBUS converter will wake up and how long the RX window stays open can be defined by the user.
The message on the receiving server side is:
Nov 02 16:42:47 challenger python[31631]: 2020-11-02 16:42:47 diff = 05:59 : received message from: ('46.234.125.38', 33121) in hex: 010A000C190149449344178719923408780DFF5F350082E51800600107B06E692B070000007F2C000000009F2A070000000000000000000000070000000000000000000000000000002F046D3710822B
where “010A000C19” (0 - 5b) is overhead from our NB provider and “17871992” is the address of the device in little-endian (11 - 14b).
The format of the message is given by the Qundis itself and you may need to refer to their datasheet to translate measured data correctly.