DSMR binding for Austrian Smart Meters

Martin_Fischer · January 17, 2020, 9:17am

hi,

I have a Siemens IM350 smart meter which has a DSMR P1 V3.0 RJ12-Interface.
The power provider gave me the encryption code.
I connected the RJ12-Interface via an USB-to-TTL serial adapter to the Raspbery Pi 4b.

I can see the encrypted data via /dev/ttyUSB0 so I installed an actual OH2 and the DSMR-binding altough I am from Austria.
For my understanding I cannot use the IEC 62056-21 meter binding and I also cannot use the SmartMeter Binding because the data is encrypted, right?

I configured the DSMR binding with a smartyBridge and a DSMR V3 electric meter (also tried a DSMR V5 electric meter) and entered the serial port and the encryption key but all the things went offline/unknown.

Has anybody successfully configured this binding with a Siemens IM350 power meter or does someone know how to do this?

Regards,
Martin

hilbrand · January 22, 2020, 11:01am

It seems each country has it’s own specification, all based on using a similar format related to IEC 62056, DLMS/COSEM. But the specific implementation is not standardized in general. In the Netherlands it has been specified in the DSMR standard, which is implemented in the DSMR binding. In Belgium and Luxembourg they adapted the DSMR standard. Belgium added some more codes, and Luxembourg added an encryption layer on it. In any other country if it not complies with the DSMR standard I doubt the DSMR binding can be used. The DSMR binding can detect if the encrypted Luxembourg standard is used. So if the discovery did not detect your meter (assuming it gets data from the meter) than it means it uses a different encryption and possible also a different specification.

So I think at this moment it’s not possible to read your meter with either binding and someone would need to add support for this. If the specifications are very similar to the DSMR standard it could be added to the DSMR binding, and otherwise it should be added to the smartmeter binding. But I could not find a lot of information about what the actually specification is (but this might also because it’s not or very limited available in English).

Martin_Fischer · April 13, 2020, 9:28pm

I didn`t find a lot of information about this reader too. I only have a manual with 3 pages from the energy provider and in this manual following is mentioned:

the smart reader corresponds to the standard DSMR P1 V3.0
it uses the IDIS CII (Consumer Information Interface) protocol to transfer the information
it transfers the information every second
max. baud rate 115200bps
the reader works as server (SAP 001) and the device of the customer as client (SAP 103)
HDLC format is used for the information
the informations are transfered without OBIS and attributes, only the values are transfered
the information is encrypted (not authenticated)

this is the output when I issue the command “cat /dev/ttyUSB0” in the Linux shell:

�$%-^H��T��,٦H�-5`vƊŠLs(�y�a
��aB�!b:
&e0�(o �$��r�~Ę��ʲb>����C��c�ƅ¾��O7qX/T�Q1щ�p��)2b �$��r�~Ę�$x�ʲb>��L����A�G�cfqrG�F!�œ➲4�eE<�-A��@ �$��rd~Ę𒼲�d��L��*��)�)XR��
ʰ�DG�� 98F�G� <XQM�h�9b"�t1!ž

I$�NB��d�"��z�3rnv

Is it better to add support of this device to the DSMR binding or to the smartmeter binding?
What do you think? Who should I ask?

hilbrand · April 15, 2020, 8:55am

If it’s based on the DSMR standard it can be added to the DSMR binding. It does seem to use encryption. The DSMR binding can be adapted to handle this, this can be implemented similary as is done for the Luxembourg meter, which also uses encryption. You also mentioned it transfers without OBIS and attributes. If that is true it would make it much more difficult. However, I suspect this refers to the communication between the meter and the energy provider and not the reading of the p1 port.

To be able to add support it is needed to know how to decrypt the message. Without that information it’s not possible to implement anything. So you need to find out that information. Best way to proceed than is to create a github with all information and than I can work on adding the support to the DSMR binding. Assuming it is based on the DSMR standard. If not someone else probably needs to build something.

Martin_Fischer · April 16, 2020, 7:05am

I am not a software developer, so I am not familiar with github or how to find out how to decrypt the message. How did you find out how to decrypt the Luxembourg meter? Did you ask the manufacturer? I already searched in the internet and maybe I found an interesting article (it deals with Siemens IM350 SmartMeter; exactly what I have):
https://www.gurux.fi/node/15268
Is this something it would help you?
How can I help?

hilbrand · April 16, 2020, 3:59pm

The luxembourg meter standard description is available on the internet and there are some other implementations that could be used as reference for the openHAB implementation. Without more information about the Austria specification it’s very hard to make an implementation.

Elle · November 4, 2020, 4:13am

hi,

this are the informations i got from an austrian electricity company:
Protocol: DLMS
Output type: push
Output interval: 1 second
Security: Cosem Suite 0; High Level Security (HLS); AES 128
Authentication: No
Encryption: YES

Description OBIS Unit
Counter number 0.0.96.1.1
Time 1-0:0.9.1
Date 1-0:0.9.2
Current counter reading P+ 1-0:1.8.0 Wh
Current counter reading P- 1-0:2.8.0 Wh
Current counter reading Q+ 1-0:3.8.0 varh
Current counter reading Q- 1-0:4.8.0 varh
Current instantaneous power P+ 1-0:1.7.0 W
Current instantaneous power P- 1-0:2.7.0 W
Customer information text 0-0:96.13.0
Customer information code 0-0:96.13.1

is it possible to adapt the binding with this information?

br

stefan

Horst_Fickel · April 27, 2021, 11:30am

In general it should work nearly out of the box, the major difference is that in austria the aad key is not static but also per device, so we get AAD and GCM per device

tknaller · August 26, 2021, 5:59pm

Hi,

I got a Sagemcom T-210-d-r in Austria.

Information from my power provider:

Encryption Key (Hex-String 32 Characters)
Authentication Key (Hex-String 32 Characters)
Protocol: DSMR-P1 5.0.2 (AES-128-GCM encrypted)
Baud-Rate: 115.200, Data-Bits: 8, Stop-Bits: 1, Parity: none
Refresh Interval: 10 Seconds

So i was suspecting the Smarty Meter Bridge should work - but I unfortunately always receive this error:

javax.crypto.AEADBadTagException: Input too short - need tag

I already tried swaping the ADD-String in SmartyDecrypter.java from the static Luxembourg one to either of the keys I received (and using the other one in the binding configuration) - but no luck, same error.

1000 Bytes in hex from my tty-Device:

 9a db 08 53 41 47 35 00 02 f6 5c 82 01 f2 30 00 00 c5 96 a3 b5 c4 b3 c6 8e ac 06 09 c8 9a f8 9e 6f 12 c5 ae aa f3 41 9f 09 31 a5 ad cd ad c2 cc 8c 39 b1 3d 38 8e 92 d8 13 0e b8 bd a8 08 85 23 d1 13 07 c5 6a d8 98 07 3c 38 72 4f ae b0 16 96 ac 4e 22 58 11 6e 19 e5 d2 99 af 4c 5a 60 7a d1 d9 4a 6c 12 11 70 bf b0 29 b5 47 25 69 46 9c 12 01 87 32 c5 9e 17 47 bd 96 98 71 18 cc 76 3b ee
 89 70 95 cb 31 44 84 f0 72 f2 6c f6 89 60 56 f9 a5 9c ee 1f 80 20 13 60 25 9b f2 c9 cd 6f d2 a8 58 f3 43 30 60 f8 bd d9 ea 01 f5 c6 30 d4 06 01 3f 87 fc 7f e7 9a 45 ca ee 40 b1 ca ab b3 ce 40 eb 7c 7b b0 ea 2c d6 0f 4b 94 ef 79 49 49 b0 00 3b 06 f0 d6 02 c9 5a 3a bd 41 05 87 76 8b 14 56 ff d8 40 d2 62 ba 9f ae bf 4e 95 42 02 4b d3 5b 3f 06 ef 39 e2 a9 45 15 d6 bd 33 d8 6e 45 06 7c
 1c 99 d6 e1 e9 4f 9f 9d ff 78 a1 30 2c e5 4b 04 11 8b a0 1d bc 6b 38 d7 5d 6a 78 99 2a 58 45 b6 9c 39 1d 56 23 a5 ad e4 64 7e 73 ea 69 49 2c 41 1d d7 4c 21 80 c7 b8 0f 4e de b1 10 51 50 f9 5e 2d 27 8f bc 02 56 0c b2 4a 1c 5a 69 75 22 b9 c2 fe 71 69 72 7b c1 15 6d a2 10 05 b7 89 79 bc 32 5d 62 55 2c 90 99 36 ae 34 bb 0c 5c 1e 5d 6b 32 63 9d 1d 65 cb 1a fb 61 8b a6 79 8b b7 8c 9e 5a
 2d e1 c9 a7 68 48 11 17 27 9c f6 36 59 14 8f 0b 2d 94 eb 14 d2 eb ac a2 b0 f2 01 03 f9 ed fa 17 ee b8 de 5f e7 5a 9c 4f 93 4b f1 ad 2a de 94 33 d9 9c 6d e8 29 71 a0 8d 43 19 f5 e8 70 95 65 a4 d9 90 90 38 a0 72 4a 6c 4d 01 33 ee e1 e6 59 a4 39 fc 72 92 1e 2a b8 ff 88 73 7c 48 42 e5 96 c7 30 87 8c 85 7f be 1b 47 d3 dd bb 98 34 0e ee 58 ca 5b c6 74 4f 6b 6d c1 9c ca 5b d0 cd 7b af b9
 db 08 53 41 47 35 00 02 f6 5c 82 01 f2 30 00 00 c5 97 60 61 2f ee f3 d4 e1 7b 99 29 75 db 54 43 ff 67 72 4a 06 81 cf e6 f4 03 58 2c f6 5c 49 f9 8f a1 f4 d6 fe 31 02 28 ff 5a a1 4c 84 61 6e b5 98 7e c2 a3 06 d3 93 40 bf 2d 7e 0b 32 48 54 e1 83 3e 5b de 26 28 b3 98 ec fc 22 27 39 78 52 6f 4b 7c 5a 64 cf 7f 62 68 e8 91 cb a5 23 2e 22 fe f1 99 40 9a 91 52 0b 59 3e 8a ac 29 5f c3 91 95
 a9 96 0d 7b 93 c1 68 e7 1b 1b d5 9b 82 21 55 4b 31 3b f5 df e0 f8 01 08 5e 16 46 04 bf fe 9a 4e 9a 74 64 34 24 1f 5e ee cd 45 36 f2 6e 85 3a a2 09 5f f0 98 1f ef 0f c0 5d 5c c4 c7 e7 5a bb 56 64 d6 2d af 67 af 19 76 a9 4c 01 ca 2b 2c 5f e6 33 e6 50 24 1d 15 a0 f3 bf be c7 21 64 29 f3 97 53 50 02 1d 46 cf f3 55 bb 89 7a 9f 8e 26 b4 52 05 d2 58 48 56 b8 ef ed 23 2f c4 a0 0d 46 02 0c
 a7 2e 90 6e da 7f c3 2c 94 30 cd 60 bf 28 97 04 41 b3 be 49 7b f9 e8 17 38 33 02 60 22 af 64 9b fb e7 31 f7 60 b5 17 a1 f8 30 cd 15 9a 03 62 4e 8e f0 3e 95 37 18 45 0a ae 3d 54 b6 48 1d 85 d7 69 a0 ad 4f 98 12 a4 f5 70 7c 5d f4 62 83 4e 4f 5d 36 7d 53 00 b2 3f bc 7f 12 34 94 11 cb 7f 5e 0e af db 55 34 03 dd 4d 76 b3 99 89 d4 e9 3c fc 2a 24 11 12 f4 bd 51 69 6d 0c cc b0 81 74 b8 03
 57 c3 23 15 b1 b0 5c a5 d8 ec 9a d4 ac f3 92 ef 10 86 e8 7b 03 27 7e bf b7 67 75 2c b4 f1 b7 36 94 42 15 2f 2e 01 61 50 16 d5 62 8d 34 63 01 3f c2 cf 4f 4f 15 88 70 77 4f 25 5b 84 b9 f8 2b 32 df 0a 38 74 ef ee 16 a7 79 cb 47 17 7b a3 c4 eb 9a 61 b7 6c cc 07 92 cd 28 c7 85 4f 46 cd 6f 62 eb ad 70 49 5c 0a f7 4b

(created using this command: od -A n -N KB -t x1 -w128 /dev/ttyDSMR > /tmp/filename.txt)

I will gladly provide the encryption key and authentication key to anyone who is willing to try themselves on these packets

tknaller · August 30, 2021, 8:33pm

I circumvented the java AES issues by using a modified version of smarty_dsmr_proxy: GitHub - tknaller/smarty_dsmr_proxy

which runs as it’s own docker container:
Dockerfile:

FROM python:3
RUN pip install pyserial && pip install cryptography && pip3 install pycryptodomex
RUN apt-get update && apt-get install -y socat
RUN git clone https://github.com/tknaller/smarty_dsmr_proxy.git /smarty_dsmr_proxy
COPY ./run.sh /run.sh
CMD sh /run.sh

run.sh:

#!/bin/sh
socat -d -d pty,raw,echo=0 TCP-LISTEN:2001,reuseaddr &
python3 /smarty_dsmr_proxy/decrypt.py ENCRYPTION KEY --serial-input-port=/dev/ttyDSMR --serial-output-port=/dev/pts/1

→ Docker-compose exposes port 2001:

------------ snip -------

  dsmrproxy:
    build: ./smarty_dsmr_proxy
    container_name: dsmrproxy
    restart: always
    tty: true
    ports:
      - 2001:2001
    devices:
      - /dev/ttyDSMR
---------- snip -------

note:

my USB to Serial-P1 is mounted as /dev/ttyDSMR via UDEV rules)
my openhab uses network_mode: host

openhab in docker-compose has a custom command: /customstart.sh

#!/bin/bash -x
apt-get update
apt-get install -y socat
socat -d -d pty,link=/dev/ttyDSMR,raw,user=openhab,group=dialout,mode=777 tcp:127.0.0.1:2001 &
gosu openhab tini -s ./start.sh $@

now /dev/ttyDSMR inside the docker container (don’t forget about EXTRA_JAVA_OPTS: "-Duser.timezone=Europe/Vienna -Dgnu.io.rxtx.SerialPorts=/dev/ttyDSMR") receives the stuff unencrypted but now my problem is:

2021-08-30 22:24:16.264 [TRACE] [l.device.p1telegram.P1TelegramParser] - Raw data: /EST5\253740976_A
1-3:0.2.8(50)
0-0:1.0.0(210830222406S)
1-0:1.8.0(000276683*Wh)
1-0:1.8.1(000197551*Wh)
1-0:1.8.2(000079132*Wh)
1-0:1.7.0(000001560*W)
1-0:2.8.0(000004998*Wh)
1-0:2.8.1(000001350*Wh)
1-0:2.8.2(000003648*Wh)
1-0:2.7.0(000000000*W)
1-0:3.8.0(000005672*varh)
1-0:3.8.1(000001954*varh)
1-0:3.8.2(000003718*varh)
1-0:3.7.0(000000000*var)
1-0:4.8.0(000217237*varh)
1-0:4.8.1(000144753*varh)
1-0:4.8.2(000072484*varh)
1-0:4.7.0(000000480*var)
!7F45
, Parser state entering parseData: WAIT_FOR_START
2021-08-30 22:24:16.269 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-3:0.2.8, obisId: 1-3:0.2.8, values: (50)
2021-08-30 22:24:16.270 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 1-3:0.2.8 in the fixed lookup table
2021-08-30 22:24:16.272 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: P1_VERSION_OUTPUT
2021-08-30 22:24:16.273 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (50)
2021-08-30 22:24:16.275 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.277 [TRACE] [l.device.p1telegram.P1TelegramParser] - Adding Cosem Object(type:P1_VERSION_OUTPUT, cosemValues:{=50}) to list of Cosem Objects
2021-08-30 22:24:16.278 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 0-0:1.0.0, obisId: 0-0:1.0.0, values: (210830222406S)
2021-08-30 22:24:16.279 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 0-0:1.0.0 in the fixed lookup table
2021-08-30 22:24:16.280 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: P1_TIMESTAMP
2021-08-30 22:24:16.281 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (210830222406S)
2021-08-30 22:24:16.282 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.283 [TRACE] [dsmr.internal.device.cosem.CosemDate] - Trying pattern: (\d{12})([S,W]?)
2021-08-30 22:24:16.284 [TRACE] [dsmr.internal.device.cosem.CosemDate] - 210830222406S matches pattern: (\d{12})([S,W]?)
2021-08-30 22:24:16.285 [TRACE] [l.device.p1telegram.P1TelegramParser] - Adding Cosem Object(type:P1_TIMESTAMP, cosemValues:{=2021-08-30T22:24:06.000+0200}) to list of Cosem Objects
2021-08-30 22:24:16.286 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:1.8.0, obisId: 1-0:1.8.0, values: (000276683*Wh)
2021-08-30 22:24:16.287 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_DELIVERY_TARIFF0
2021-08-30 22:24:16.288 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000276683*Wh)
2021-08-30 22:24:16.289 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.290 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_DELIVERY_TARIFF0, values: (000276683*Wh)
java.text.ParseException: Failed to parse value '000276683*Wh' as unit kWh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.307 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:1.8.0)
2021-08-30 22:24:16.308 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:1.8.1, obisId: 1-0:1.8.1, values: (000197551*Wh)
2021-08-30 22:24:16.309 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_DELIVERY_TARIFF1
2021-08-30 22:24:16.309 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000197551*Wh)
2021-08-30 22:24:16.310 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.311 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_DELIVERY_TARIFF1, values: (000197551*Wh)
java.text.ParseException: Failed to parse value '000197551*Wh' as unit kWh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.312 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:1.8.1)
2021-08-30 22:24:16.313 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:1.8.2, obisId: 1-0:1.8.2, values: (000079132*Wh)
2021-08-30 22:24:16.314 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_DELIVERY_TARIFF2
2021-08-30 22:24:16.314 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000079132*Wh)
2021-08-30 22:24:16.315 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.316 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_DELIVERY_TARIFF2, values: (000079132*Wh)
java.text.ParseException: Failed to parse value '000079132*Wh' as unit kWh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.317 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:1.8.2)
2021-08-30 22:24:16.318 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:1.7.0, obisId: 1-0:1.7.0, values: (000001560*W)
2021-08-30 22:24:16.319 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 1-0:1.7.0 in the fixed lookup table
2021-08-30 22:24:16.319 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_ACTUAL_DELIVERY
2021-08-30 22:24:16.319 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000001560*W)
2021-08-30 22:24:16.320 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.321 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_ACTUAL_DELIVERY, values: (000001560*W)
java.text.ParseException: Failed to parse value '000001560*W' as unit kW
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:112) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.322 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:2.8.0, obisId: 1-0:2.8.0, values: (000004998*Wh)
2021-08-30 22:24:16.323 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_PRODUCTION_TARIFF0
2021-08-30 22:24:16.323 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000004998*Wh)
2021-08-30 22:24:16.324 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.325 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_PRODUCTION_TARIFF0, values: (000004998*Wh)
java.text.ParseException: Failed to parse value '000004998*Wh' as unit kWh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.326 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:2.8.0)
2021-08-30 22:24:16.327 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:2.8.1, obisId: 1-0:2.8.1, values: (000001350*Wh)
2021-08-30 22:24:16.328 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_PRODUCTION_TARIFF1
2021-08-30 22:24:16.328 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000001350*Wh)
2021-08-30 22:24:16.329 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.329 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_PRODUCTION_TARIFF1, values: (000001350*Wh)
java.text.ParseException: Failed to parse value '000001350*Wh' as unit kWh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.331 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:2.8.1)
2021-08-30 22:24:16.331 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:2.8.2, obisId: 1-0:2.8.2, values: (000003648*Wh)
2021-08-30 22:24:16.332 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_PRODUCTION_TARIFF2
2021-08-30 22:24:16.332 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000003648*Wh)
2021-08-30 22:24:16.332 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.333 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_PRODUCTION_TARIFF2, values: (000003648*Wh)
java.text.ParseException: Failed to parse value '000003648*Wh' as unit kWh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.335 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:2.8.2)
2021-08-30 22:24:16.335 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:2.7.0, obisId: 1-0:2.7.0, values: (000000000*W)
2021-08-30 22:24:16.336 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 1-0:2.7.0 in the fixed lookup table
2021-08-30 22:24:16.336 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_ACTUAL_PRODUCTION
2021-08-30 22:24:16.337 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000000000*W)
2021-08-30 22:24:16.338 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.338 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_ACTUAL_PRODUCTION, values: (000000000*W)
java.text.ParseException: Failed to parse value '000000000*W' as unit kW
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:112) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.340 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:3.8.0, obisId: 1-0:3.8.0, values: (000005672*varh)
2021-08-30 22:24:16.341 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_TOTAL_IMPORTED_ENERGY_REGISTER_Q
2021-08-30 22:24:16.342 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000005672*varh)
2021-08-30 22:24:16.343 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.344 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_TOTAL_IMPORTED_ENERGY_REGISTER_Q, values: (000005672*varh)
java.text.ParseException: Failed to parse value '000005672*varh' as unit kvarh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.346 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:3.8.0)
2021-08-30 22:24:16.347 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:3.8.1, obisId: 1-0:3.8.1, values: (000001954*varh)
2021-08-30 22:24:16.348 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:3.8.1)
2021-08-30 22:24:16.349 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:3.8.2, obisId: 1-0:3.8.2, values: (000003718*varh)
2021-08-30 22:24:16.350 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:3.8.2)
2021-08-30 22:24:16.351 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:3.7.0, obisId: 1-0:3.7.0, values: (000000000*var)
2021-08-30 22:24:16.351 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 1-0:3.7.0 in the fixed lookup table
2021-08-30 22:24:16.352 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_ACTUAL_REACTIVE_DELIVERY
2021-08-30 22:24:16.353 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000000000*var)
2021-08-30 22:24:16.356 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.357 [TRACE] [l.device.p1telegram.P1TelegramParser] - Adding Cosem Object(type:EMETER_ACTUAL_REACTIVE_DELIVERY, cosemValues:{=0}) to list of Cosem Objects
2021-08-30 22:24:16.359 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:4.8.0, obisId: 1-0:4.8.0, values: (000217237*varh)
2021-08-30 22:24:16.360 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_TOTAL_EXPORTED_ENERGY_REGISTER_Q
2021-08-30 22:24:16.361 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000217237*varh)
2021-08-30 22:24:16.363 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.365 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Failed to construct Cosem Object for type EMETER_TOTAL_EXPORTED_ENERGY_REGISTER_Q, values: (000217237*varh)
java.text.ParseException: Failed to parse value '000217237*varh' as unit kvarh
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:106) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemQuantity.getStateValue(CosemQuantity.java:1) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObject.parseCosemValues(CosemObject.java:127) ~[bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObjectInternal(CosemObjectFactory.java:169) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.cosem.CosemObjectFactory.getCosemObject(CosemObjectFactory.java:139) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.storeCurrentCosemObject(P1TelegramParser.java:382) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.setState(P1TelegramParser.java:414) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.p1telegram.P1TelegramParser.parse(P1TelegramParser.java:224) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.DSMRTelegramListener.handleData(DSMRTelegramListener.java:74) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRBaseConnector.handleDataAvailable(DSMRBaseConnector.java:116) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.handleDataAvailable(DSMRSerialConnector.java:317) [bundleFile:?]
	at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.serialEvent(DSMRSerialConnector.java:276) [bundleFile:?]
	at org.openhab.core.io.transport.serial.rxtx.RxTxSerialPort$1.serialEvent(RxTxSerialPort.java:82) [bundleFile:?]
	at gnu.io.RXTXPort.sendEvent(RXTXPort.java:834) ~[bundleFile:5.2.1]
	at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1]
	at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1]
2021-08-30 22:24:16.367 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:4.8.0)
2021-08-30 22:24:16.369 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:4.8.1, obisId: 1-0:4.8.1, values: (000144753*varh)
2021-08-30 22:24:16.370 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:4.8.1)
2021-08-30 22:24:16.372 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:4.8.2, obisId: 1-0:4.8.2, values: (000072484*varh)
2021-08-30 22:24:16.373 [DEBUG] [rnal.device.cosem.CosemObjectFactory] - Received unknown Cosem Object(OBIS id: 1-0:4.8.2)
2021-08-30 22:24:16.375 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Received obisIdString 1-0:4.7.0, obisId: 1-0:4.7.0, values: (000000480*var)
2021-08-30 22:24:16.376 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Found obisId 1-0:4.7.0 in the fixed lookup table
2021-08-30 22:24:16.377 [TRACE] [rnal.device.cosem.CosemObjectFactory] - Parse values for Cosem Object type: EMETER_ACTUAL_REACTIVE_PRODUCTION
2021-08-30 22:24:16.379 [TRACE] [mr.internal.device.cosem.CosemObject] - Parsing CosemValue string (000000480*var)
2021-08-30 22:24:16.380 [TRACE] [mr.internal.device.cosem.CosemObject] - Received items: 1 is supported
2021-08-30 22:24:16.381 [TRACE] [l.device.p1telegram.P1TelegramParser] - Adding Cosem Object(type:EMETER_ACTUAL_REACTIVE_PRODUCTION, cosemValues:{=480}) to list of Cosem Objects
2021-08-30 22:24:16.382 [TRACE] [l.device.p1telegram.P1TelegramParser] - telegramState OK, crcValue to check 0x7F45
2021-08-30 22:24:16.383 [TRACE] [l.device.p1telegram.P1TelegramParser] - received CRC value: 7F45, calculated CRC value: 0x7F45
2021-08-30 22:24:16.384 [TRACE] [internal.device.DSMRTelegramListener] - Received 4 Cosem Objects with state: 'OK'
2021-08-30 22:24:16.385 [TRACE] [r.internal.handler.DSMRBridgeHandler] - Telegram received time set: 1374314520754233
2021-08-30 22:24:16.386 [TRACE] [l.device.p1telegram.P1TelegramParser] - State after parsing: WAIT_FOR_START

debugging the Cosem Wildcards and stuff looks complicated for now

tknaller · September 3, 2021, 7:50am

got it working for me now, download here: https://github.com/tknaller/openhab-addons/releases/tag/Snapshot-2021-09-03

but will probably not be included into official openhab, my pull request is a desaster https://github.com/openhab/openhab-addons/pull/11193

DerPeterIsh · September 15, 2021, 6:30pm

@tknaller you’re a star - thanks for your work!

I also have a Sagemcom T-210-d-r in Austria.

My plan was to use the API of the ‘HomeWizard Wi-Fi P1 Meter’ to get the encypted telegrams (as the P1 meter does not support decryption). And to then use a python script that calls the API once per minute and decrypts the data and makes it available.

But I am afraid that I am only receiving junk data from the P1 meter, a few examples:

curl http://192.168.0.31/api/v1/telegram | hexdump
0000000 4f2f b886 c97f 4d74 8c18 6839 6e3a 69e2
0000010 4c61 4575 b078 1216 7aa7 75da c343 2b85
0000020 4d51 cd9c b333 267b c7cf 3189 9fca 8353
0000030 9679 664e fbd8 e2ad 358f ab74 1578 41bc
0000040 dc1c 3a4d c05c c731 caed 8ae2 8ada 9cf7
0000050 034c 4cdb dcbd fb1e 96b5 f465 efee ab43
0000060 d44f dc6d 026f 3e2a 2d1f a7f4 32e2 ca11
0000070 3515 d36f 9548 163c 0b48 88c9 daea 5136
0000080 d973 73f3 ea38 545f 9c86 896b aa6c ff15
0000090 0c47 fcad 7f27 f5b9 dbc4 28a1 b056 7a35
00000a0 8566 e90c
00000a4

curl http://192.168.0.31/api/v1/telegram | hexdump
0000000 9f2f a23a 89e9 4fa9 692d e590 d57a ad15
0000010 3d09 0012
0000013

curl http://192.168.0.31/api/v1/telegram | hexdump
0000000 e72f 2005 01f2 b1f3 4251 b70b 88e0 2946
0000010 e504 58c6 db97 f136 f365 fd05 44bd 0021
000001f

curl http://192.168.0.31/api/v1/telegram | hexdump
0000000 f52f f0f0 b7b3 56ac eb13 aaf4 7db5 b9dd
0000010 85fd 1fc4 6d37 17ad 2ade 57e8 81a3
000001e

Can you confirm this is just junk data which I will never be able to decrypt to a proper message?

If so, I will buy a P1 cable and will try to follow your steps above to make it work via your smarty_dsmr_proxy app.

Thanks again.

hilbrand · November 2, 2021, 7:46am

Support for the Austrian smart meter has been merged into the 3.2.0-SNAPSHOT version and will be available next release. It would be great if it can be tested if it works as expected.

If you used the version made by @tknaller you need to update the channels, because the channel names are different. This is because it now reuses channels that where already present in the binding.

norbert_jordan · November 2, 2021, 2:54pm

Thanks for the effort, Hilbrand.

I’m using Austrian T210-D as well, tried now to connect as shown in the pic below. But i do not even get power to the ESP.

So for me the question, is P1 normally enabled by default or does the provider remotely enable as soon as the client requests it…

OR does the Pinout vary depending on the country / customizations. Because my operator (EVN) provides following PDF on the internet. Which brings in another level of confusion. Here it’s clearly stated that 1 does not provide 5V and even more strange there is a 2wire MODBUS communication depicted.

I’ve seen people post that the T210-D is using the same NL slimme meter cable…but how can this be the case when here its written as MBUS and not serial RX/TX.

Thanks for reading and i really hope that someone can clarify my confusions.
Many Thanks
Norbert

norbert_jordan · November 2, 2021, 3:05pm

i now found a PDF of all energy providers in AT. It seems that EVN is using T210 with MBUS only. I can build a modbus adapter to serial. BUT does anyone know if the DSMR binding will handle MBUS as well?
Luck seems not to be on my side

DerPeterIsh · November 2, 2021, 3:57pm

Hi ich weiß nicht ob euch das etwas hilft aber laut Auskunft Energienetze Steiermark gibt es ca ab Jänner einen P1 Dongle der in Österreich funktioniert: hier dazu auch eine E-Mail der Firma Ginzinger die das Ding produziert:

Ja den Dongle wird es geben und wir sind der Produzent und Entwickler.

Aber dieser wird nicht direkt über uns bestellbar sein.

Soweit ich informiert bin wird der Vertrieb direkt über die Netzbetreiber erfolgen.

Der Verkaufszeitpunkt wird dazu noch über die Netzbetreiber bzw. den Verein E-Wirtschaft bekannt gegeben.

GINZINGER ELECTRONIC SYSTEMS GMBH

hilbrand · November 2, 2021, 5:05pm

The p1 connectors Im aware of are 4 pins RJ11.

While it mentions 5volt it’s not always available and it’s recommend to use an external power supply. This can be 5v via USB if it’s a USB to serial cable.

It might be the provider needs to enable the port. But this seems country specific. But I don’t know if that is the case for you.

The binding does not support the mbus protocol.

csi_oh · November 8, 2021, 8:56am

hi there, do you have any recommendation for a cable to be connected to the Sagemcom T210-D? I’d love to have something like P1=>RJ45, but P1=>USB (for RPI) is also fine!

many thanks!

emerich · December 4, 2021, 3:01pm

Hello,
@tknaller: could you please outline how to use your binding? Where do I have to configure the Encryption Key and Authentication Key in your binding? Could you please provide a short description?
Is the USB interface detecting the baudrate on its own? According to my provider I need 2400 baud.

Thanks for your effort!!

br. Christian

splatch · December 5, 2021, 1:53pm

Question is it mbus at physical and application layer or only at physical? If its later one then there are multiple adapters which could be used to bridge it to serial interface. One I tested in past was from relay (micro master), yet I didn’t check if adapter does anything with frames themselves or it is just basic level shifter.