Issues reading Landis+Gyr E360 meter

Hi,

I am trying to setup the DSMR binding using a FTDI P1 cable, and a Landis+Gyr E360 meter. I can read the output of the meter fine using a serial terminal, but the binding is throwing the errors below.

2022-03-23 15:27:38.317 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character ')' in state: DATA_OBIS_ID. This P1 telegram is marked as failed
2022-03-23 15:27:39.920 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character '&' in state: DATA_OBIS_ID. This P1 telegram is marked as failed
2022-03-23 15:27:40.975 [DEBUG] [internal.device.DSMRTelegramListener] - Telegram received with error state 'CRC_ERROR': Cosem Object(type:P1_VERSION_OUTPUT, c
osemValues:{=50}),Cosem Object(type:P1_TIMESTAMP, cosemValues:{=2022-03-23T15:27:49.000+0100}),Cosem Object(type:EMETER_EQUIPMENT_IDENTIFIER, cosemValues:{=E00
67005820157521}),Cosem Object(type:EMETER_DELIVERY_TARIFF1, cosemValues:{=754.914 kWh}),Cosem Object(type:EMETER_DELIVERY_TARIFF2, cosemValues:{=693.725 kWh}),
Cosem Object(type:EMETER_PRODUCTION_TARIFF2, cosemValues:{=0 kWh}),Cosem Object(type:EMETER_TARIFF_INDICATOR, cosemValues:{=0002}),Cosem Object(type:EMETER_ACT
UAL_DELIVERY, cosemValues:{=0.289 kW}),Cosem Object(type:EMETER_ACTUAL_PRODUCTION, cosemValues:{=0 kW}),Cosem Object(type:EMETER_POWER_FAILURES, cosemValues:{=
7}),Cosem Object(type:EMETER_LONG_POWER_FAILURES, cosemValues:{=5}),Cosem Object(type:EMETER_VOLTAGE_SAGS_L1, cosemValues:{=8}),Cosem Object(type:EMETER_VOLTAG
E_SAGS_L2, cosemValues:{=8}),Cosem Object(type:EMETER_VOLTAGE_SAGS_L3, cosemValues:{=12}),Cosem Object(type:EMETER_VOLTAGE_SWELLS_L1, cosemValues:{=0}),Cosem O
bject(type:EMETER_VOLTAGE_SWELLS_L2, cosemValues:{=0}),Cosem Object(type:EMETER_VOLTAGE_SWELLS_L3, cosemValues:{=0}),Cosem Object(type:P1_TEXT_STRING, cosemVal
ues:{=}),Cosem Object(type:EMETER_INSTANT_VOLTAGE_L1, cosemValues:{=242.8 V}),Cosem Object(type:EMETER_INSTANT_VOLTAGE_L2, cosemValues:{=242.5 V}),Cosem Object
(type:EMETER_INSTANT_VOLTAGE_L3, cosemValues:{=243.3 V}),Cosem Object(type:EMETER_INSTANT_CURRENT_L1, cosemValues:{=0 A}),Cosem Object(type:EMETER_INSTANT_CURR
ENT_L2, cosemValues:{=0 A}),Cosem Object(type:EMETER_INSTANT_CURRENT_L3, cosemValues:{=1 A}),Cosem Object(type:EMETER_INSTANT_POWER_DELIVERY_L1, cosemValues:{=
0.164 kW}),Cosem Object(type:EMETER_INSTANT_POWER_DELIVERY_L2, cosemValues:{=0 kW}),Cosem Object(type:EMETER_INSTANT_POWER_DELIVERY_L3, cosemValues:{=0.124 kW}
),Cosem Object(type:EMETER_INSTANT_POWER_PRODUCTION_L1, cosemValues:{=0 kW}),Cosem Object(type:EMETER_INSTANT_POWER_PRODUCTION_L2, cosemValues:{=0 kW}),Cosem O
bject(type:EMETER_INSTANT_POWER_PRODUCTION_L3, cosemValues:{=0 kW})
2022-03-23 15:27:40.981 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character '^b' in state: DATA_OBIS_VALUE_END. This P1 telegram is marked as
 failed
2022-03-23 15:27:42.002 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character '^h' in state: CRLF. This P1 telegram is marked as failed
2022-03-23 15:27:42.017 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character ',' in state: DATA_OBIS_ID. This P1 telegram is marked as failed
2022-03-23 15:27:43.080 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character '^p' in state: DATA_OBIS_ID. This P1 telegram is marked as failed
2022-03-23 15:27:44.155 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 0-3:0.2.8)
2022-03-23 15:27:44.165 [DEBUG] [l.device.p1telegram.P1TelegramParser] - Unexpected character '&' in state: DATA_OBIS_ID. This P1 telegram is marked as failed

I am running openHAB 3.2.0-1, installed via aot on a Odroid XU4, running armbian.

The frames from the meter are as follows:

1-3:0.2.8(50)
0-0:1.0.0(220323195346W)
0)0:96.1.1(4530303637303035383230313537353231)
1-0:1.8.1(000754.914*kWh)
1-0:1.8.2(000695.054*kWh)
1-0:2.8.1(000000.000*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0002)
1-081.7.0(00.273*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00007)
0-0:96.7.9(00005)
1-0:99.97.0(4)(0-0:96.7.19)(000101000000W)(0000000#22*s)(000101000000W)(0000417814*s)(000101000000W)(0000000201*s)(211122171729W)(0000005318*s)
1-0:32.32.0(00008)
1-0:52.32.0(00008)
0000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0()
1-0:32.7.0(243.4*V)
1-0:52.7.0(243.7*V)
1-0:72.7.0(244.9*V)
1-0:31.7.0(000*A)
1-0:51.7.0(000*A)
1-0:71.7.0(001*A)
1-0:21.7.0(00.113*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.160*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.000*kW)
!DB11
/XMX5LGF0010458201575

1-3:0.2.8(50)
0-0:1.0.0(220323195347W)
0-0:96.1.1(4530303637303035383230313537353231)
1-0:1.8.1(000754.914*kWh)
1-0:1.8.000695.254*kh)
1-0:2.8.1(000000.000*kWh)
1-0:2.8.(000000.000*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.272*kW)
1-0:2.7.0(00.000*jW)
0-0:96.7.21(00007)
0-0:96.7.9(00005)
1-0:99.97.0(4)(0-0:96.7.19)(000101000000W)(000000032"*s)(000101000000W)(0000417814*s)(000101000000W)(0000000201*s)(211122171729W)(0000005318*s)
1-0:32.32.0(00008)
1,0:52.32.0(00008)
1-0:72.32.0(00012)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96&13.0()
1-0:32.7.0(243.3*V)
1-0:52.7.0(243.6*V)
2.7.0(245.0*V)
1-0:31.7.0(000*A)
1-0:51.7.0(000*A)
1-0:71.7.0(001*A)
1-0:21.7.0(00.112*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.160*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.000*kW)
B2BA
/XMX5LGF0010458201575

I hope someone can help me figure out whats going on.

If you look carefully at the output you can see the data is corrupted. This meter seems to be known to have difficulties to get the readings. See also this thread: DSMR bridge stuck at UNKNOW ser2net

1 Like

Thank you.
I am not very familiar with how the frames should look, so I was unable to spot it.

Following the other thread onto the Domotics forum, it seems I have some soldering to do if I want to make it work :slight_smile:

I gave the modification a shot, and it now seems to work fine with the E360 meter.

What I’ve done is:

  • Add a 390 ohm resistor between RXD (Data, pin 5) and VCC (Data-request, pin 2)
  • Add a 1nF ceramic capacitor between RXD (Data, pin 5) and GND (pin 3)

This all still fit neatly in the original case.

The frames now look healthy (as far as I can tell), and the binding does not complain anymore.

1-3:0.2.8(50)
0-0:1.0.0(220325094719W)
0-0:96.1.1(4530303637303035383230313537353231)
1-0:1.8.1(000758.875*kWh)
1-0:1.8.2(000700.340*kWh)
1-0:2.8.1(000000.000*kWh)
1-0:2.8.2(000000.000*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(00.266*kW)
1-0:2.7.0(00.000*kW)
0-0:96.7.21(00007)
0-0:96.7.9(00005)
1-0:99.97.0(4)(0-0:96.7.19)(000101000000W)(0000000322*s)(000101000000W)(0000417814*s)(000101000000W)(0000000201*s)(211122171729W)(0000005318*s)
1-0:32.32.0(00008)
1-0:52.32.0(00008)
1-0:72.32.0(00012)
1-0:32.36.0(00000)
1-0:52.36.0(00000)
1-0:72.36.0(00000)
0-0:96.13.0()
1-0:32.7.0(242.7*V)
1-0:52.7.0(242.2*V)
1-0:72.7.0(244.3*V)
1-0:31.7.0(000*A)
1-0:51.7.0(000*A)
1-0:71.7.0(001*A)
1-0:21.7.0(00.114*kW)
1-0:41.7.0(00.000*kW)
1-0:61.7.0(00.152*kW)
1-0:22.7.0(00.000*kW)
1-0:42.7.0(00.000*kW)
1-0:62.7.0(00.000*kW)
!B23B
/XMX5LGF0010458201575

Thanks for the hint where to start looking, and I hope this might help someone else in the process :slight_smile:

2 Likes

Great you got it working.

Regarding the corrupted data. To see what this means (or for anyone who finds this topic) here are some examples to recognized corrupted data. If data is corrupted it is either missing or data replaced by other characters. If you look at the original 2 frames posted you can see:

In the first frame it shows correctly:

0-0:96.13.0()

And in the second frame the . is misplaced by &

0-0:96&13.0()

Another example of missing data.
Here is the correct data in the first frame:

1-0:72.7.0(244.9*V)

In the second frame it misses the first part: 1-0:7

2.7.0(245.0*V)