TRB143 and Carlo Gavazzi mbus elctric meter

OscarB · December 5, 2023, 10:23am

Hello,
I’m attempting to read a Carlo Gavazzi EM111 meter through m-bus with a TRB143.

Setup works fine, and first request always responds with all values (3 frames), but subsequent requests only return 3 values, all of which are not relevant. Resetting FCB will always result in a long response with 3 frames.

The Gavazzi meter supports programming through the first request to set which values to return but I cannot make this work either (VIF/VIFE). Its not clear if this could be programmed through one of the three string fields, but I have not been able to make it work through trial/error. See https://gavazzi.se/app/uploads/2020/11/em111_em112_m1_cp.pdf

Any pointers would be much appreciated.

Zwen · December 5, 2023, 10:58am

I think its the same problem like in this topic: FCB toggle test problems - Teltonika Networks - Teltonika Community

OscarB · December 8, 2023, 12:02pm

This might be a bug, if I connect to the TRB through console I can use mbus-serial-request-data to get a proper response from the Gavazzi meter. When I use the normal mbus readout or the mbus test the response only contains 3 data records (except for the very first). Not shure if the standard function is based on libmbus but I guess so since these tools are installed.

mbus-serial-request-data response
init_slaves: debug: sending init frame #1
[2023-12-07 15:27:22Z] SEND (005): 10 40 FD 3D 16
init_slaves: debug: sending init frame #2
[2023-12-07 15:27:23Z] SEND (005): 10 40 FD 3D 16
[2023-12-07 15:27:23Z] SEND (005): 10 5B 01 5C 16
mbus_serial_recv_frame: Attempt to read 1 bytes [len = 0]
mbus_serial_recv_frame: Got 1 byte [remaining 1, len 0]
mbus_serial_recv_frame: Attempt to read 2 bytes [len = 1]
mbus_serial_recv_frame: Got 2 byte [remaining 2, len 1]
mbus_serial_recv_frame: Attempt to read 80 bytes [len = 3]
mbus_serial_recv_frame: Got 80 byte [remaining 80, len 3]
[2023-12-07 15:27:23Z] RECV (083): 68 4D 4D 68 08 01 72 35 93 05 50 36 1C C4 02 52 00 00 00 04 05 09 00 00 00 04 FB 82 75 00 00 00 00 04 2A 52 00 00 00 04 FB 97 72 8F FF FF FF 04 FB B7 72 8B 00 00 00 04 FD 59 3B 00 00 00 04 FD 48 1F 09 00 00 02 FD BA 73 4D 02 02 FB 2E F3 01 1F 90 16
mbus_frame_print: Dumping M-Bus frame [type 4, 83 bytes]: 68 4D 4D 68 08 01 72 35 93 05 50 36 1C C4 02 52 00 00 00 04 05 09 00 00 00 04 FB 82 75 00 00 00 00 04 2A 52 00 00 00 04 FB 97 72 8F FF FF FF 04 FB B7 72 8B 00 00 00 04 FD 59 3B 00 00 00 04 FD 48 1F 09 00 00 02 FD BA 73 4D 02 02 FB 2E F3 01 1F 90 16

MBusData>
SlaveInformation>
Id>50059335
Manufacturer>GAV
Version>196
ProductName>
Medium>Electricity
AccessNumber>82
Status>00
Signature>0000
/SlaveInformation>
DataRecord id=“0”>
Function>Instantaneous value
StorageNumber>0
Unit>Energy (100 Wh)
Value>9
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“1”>
Function>Instantaneous value
StorageNumber>0
Unit>Unrecognized VIF extension: 0x82
Value>0
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“2”>
Function>Instantaneous value
StorageNumber>0
Unit>Power (1e-1 W)
Value>82
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“3”>
Function>Instantaneous value
StorageNumber>0
Unit>Error flags
Value>-113
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“4”>
Function>Instantaneous value
StorageNumber>0
Unit>Unrecognized VIF extension: 0xb7
Value>139
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“5”>
Function>Instantaneous value
StorageNumber>0
Unit>m A
Value>59
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“6”>
Function>Instantaneous value
StorageNumber>0
Unit>1e-1 V
Value>2335
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“7”>
Function>Instantaneous value
StorageNumber>0
Unit>Unrecognized VIF extension: 0xba
Value>589
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“8”>
Function>Instantaneous value
StorageNumber>0
Unit>Unrecognized VIF extension: 0x2e
Value>499
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
DataRecord id=“9”>
Function>More records follow
Value>
Timestamp>2023-12-07T15:27:23Z
/DataRecord>
/MBusData>

Normal output from TRB
{
“MBusData”: {
“SlaveInformation”: {
“Id”: “50059335”,
“Manufacturer”: “GAV”,
“Version”: “196”,
“ProductName”: “”,
“Medium”: “Electricity”,
“AccessNumber”: “104”,
“Status”: “00”,
“Signature”: “0000”
},
“DataRecord”: [
{
“id”: “0”,
“Function”: “Instantaneous value”,
“StorageNumber”: “0”,
“Tariff”: “0”,
“Device”: “2”,
“Unit”: “Energy (100 Wh)”,
“Value”: “0”,
“Timestamp”: “2023-12-07T15:46:02Z”
},
{
“id”: “1”,
“Function”: “Instantaneous value”,
“StorageNumber”: “0”,
“Tariff”: “0”,
“Device”: “2”,
“Unit”: “Unrecognized VIF extension: 0x82”,
“Value”: “0”,
“Timestamp”: “2023-12-07T15:46:02Z”
},
{
“id”: “2”,
“Function”: “Manufacturer specific”,
“Value”: “”,
“Timestamp”: “2023-12-07T15:46:02Z”
}
]
}
}

/edit, xml formatting didn’t sit well with block quotes

OscarB · December 8, 2023, 1:42pm

After some more testing, running mbus-serial-request-data-multi-reply returns exactly the same as the normal TRB response. So I guess that is the function that is used. Adding a switch to the interface to use standard request instead of multi would be a good thing.

root@TRB143:~# mbus-serial-request-data-multi-reply -d -b 2400 /dev/ttyHS0 1
init_slaves: debug: sending init frame #1
[2023-12-07 17:25:03Z] SEND (005): 10 40 FD 3D 16
init_slaves: debug: sending init frame #2
[2023-12-07 17:25:03Z] SEND (005): 10 40 FD 3D 16
[2023-12-07 17:25:03Z] SEND (005): 10 7B 01 7C 16
mbus_serial_recv_frame: Attempt to read 1 bytes [len = 0]
mbus_serial_recv_frame: Got 1 byte [remaining 1, len 0]
mbus_serial_recv_frame: Attempt to read 2 bytes [len = 1]
mbus_serial_recv_frame: Got 2 byte [remaining 2, len 1]
mbus_serial_recv_frame: Attempt to read 37 bytes [len = 3]
mbus_serial_recv_frame: Got 37 byte [remaining 37, len 3]
[2023-12-07 17:25:03Z] RECV (040): 68 22 22 68 08 01 72 35 93 05 50 36 1C C4 02 D0 00 00 00 84 80 40 05 00 00 00 00 84 80 40 FB 82 75 00 00 00 00 0F 0E 16
mbus_frame_print: Dumping M-Bus frame [type 4, 40 bytes]: 68 22 22 68 08 01 72 35 93 05 50 36 1C C4 02 D0 00 00 00 84 80 40 05 00 00 00 00 84 80 40 FB 82 75 00 00 00 00 0F 0E 16

<?xml version="1.0" encoding="ISO-8859-1"?>

<SlaveInformation>
    <Id>50059335</Id>
    <Manufacturer>GAV</Manufacturer>
    <Version>196</Version>
    <ProductName></ProductName>
    <Medium>Electricity</Medium>
    <AccessNumber>208</AccessNumber>
    <Status>00</Status>
    <Signature>0000</Signature>
</SlaveInformation>

<DataRecord id="0">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Tariff>0</Tariff>
    <Device>2</Device>
    <Unit>Energy (100 Wh)</Unit>
    <Value>0</Value>
    <Timestamp>2023-12-07T17:25:03Z</Timestamp>
</DataRecord>

<DataRecord id="1">
    <Function>Instantaneous value</Function>
    <StorageNumber>0</StorageNumber>
    <Tariff>0</Tariff>
    <Device>2</Device>
    <Unit>Unrecognized VIF extension: 0x82</Unit>
    <Value>0</Value>
    <Timestamp>2023-12-07T17:25:03Z</Timestamp>
</DataRecord>

<DataRecord id="2">
    <Function>Manufacturer specific</Function>
    <Value></Value>
    <Timestamp>2023-12-07T17:25:03Z</Timestamp>
</DataRecord>

OscarB · December 13, 2023, 1:59pm

Bump. This should, at least in theory, be a quick fix.

system · December 20, 2023, 10:24am

This topic was automatically closed after 15 days. New replies are no longer allowed.