Thanks for confirming … that’s the answer I was afraid of though … 
Any hints on what to tell Creos to get them to make the right change? Did they give you any feedback about what they did to fix your issue?
Since I can decrypt with the python script my key should be good so I foresee a long, ping pong discussion with Creos where they just tell me it’s working and I keep replying not for me … etc. etc.
If it works with the script I would expect it to also work with the binding. What is the exact error you get?
Hi Hilbrand, thanks for taking the time to reply.
I turned up the logging to TRACE and attached the output, but in summary :
2021-03-10 17:36:58.760 [WARN ] [dsmr.internal.device.SmartyDecrypter] - Decrypting smarty telegram failed: javax.crypto.AEADBadTagException: Input too short - need tag
2021-03-10 17:36:58.765 [TRACE] [internal.device.DSMRTelegramListener] - Received 0 Cosem Objects with state: ‘INVALID_ENCRYPTION_KEY’
2021-03-10 17:36:58.767 [DEBUG] [r.internal.handler.DSMRBridgeHandler] - Parsing worked but something went wrong, so there were no CosemObjects:Failed to decrypt P1 telegram due to invalid encryption key
openhab.log (4.8 KB)
This log snippet has the encryption key blanked out but the original shows the correct key.
I tweaked the python script to dump some more frame details and the results are below. Decryption seems to work and there are some OBIS codes present but not as many as I expected.
The unencrypted frames seem about right but it looks to me like there might be 1 extra byte (with a fixed value of 82h?) after the system-title field. I don’t see this in the spec that’s floating around the internet but maybe that’s out of date or I’m just not reading it properly 
Anyway, if others are successfuly decrypting the meter data, then it’s probably not the issue.
EDIT: I also obfuscated the header & logical device values in the unencrypted data. Not sure if they are specific to me but I can give you them if you want.
Framecounter 00002127
Buffer length 466
Encrypted Buffer :
db08534147677002b9088201c330000021271e0e24bffbd7481a3b5a281104a28d1485f95e16ee733a43ec135aa3862e54a374f0c8103c8bcf366bfb7b616dae89f12de5fb2b332e7bca62d7c458cfc199530bc41ae31b09a6ccd69aadfd4d6bae01bfd7b58f23b49edaad18561aa557e52a09e02b5d48444e978997f9740e08a63936a9251fc12a096c7c7798c2e02237733aa24416712c4b738650e6cc2dc6bfc2a81a5bd336efae82fd2a1f5e48c0924daaa64b3e06716c23fba43c71572794108804ce5150bf19a24f66c0738ac3cb79de1019947b3f2be4a99d8e24faa0cfeb58e61595dc8db675c3a88b8ddc6eb688a929ba102f49cbd652cf7d6559524904a66691ac837c606a7ede71b69717f9809fdede7aef00f6dacd1e8fc113f0c9e50166c6a1f554579cf88f54b3089938220b6b1847023f9e53ee5296beae388faeaf3bae32ff607e02ada39378e002a1b71aa4edbc8d26cd5e13b8bf2d432fecc4c4f92b04ffe00274e6f4b142d0e0cfea6a8a3e975a1cc4d2ef532d3c46e9e2fe6f0282324c979e1a06dc695b7e2852137e41e28e456c836354f920cb2d618c41a8a987e38d2fedf2436cfd05ac884ed8f716592e1b576d7210bb9aeb0c88835ca3fb5d1c967b3caf7a22ac7cffef
Decrypted data :
/Lux5\123456789_D\r\n\r\n1-3:0.2.8(42)\r\n0-0:1.0.0(210308231759W)\r\n0-0:42.0.0(12345678901234567890123456789012)\r\n1-0:1.8.0(039645.931kWh)\r\n1-0:2.8.0(000000.247kWh)\r\n1-0:3.8.0(000040.384kvarh)\r\n1-0:4.8.0(006192.035kvarh)\r\n1-0:1.7.0(00.876kW)\r\n1-0:2.7.0(00.000kW)\r\n1-0:3.7.0(00.000kvar)\r\n1-0:4.7.0(00.000kvar)\r\n0-0:17.0.0(27.600*kVA)\r\n0-0:96.3.10(1)\r\n0-0:96.13.0()\r\n0-0:96.13.2()\r\n0-0:96.13.3()\r\n0-0:96.13.4()\r\n0-0:96.13.5()\r\n!BBD7\r\n
Framecounter 00002128
Buffer length 466
Encrypted Buffer :
db08534147677002b9088201c3300000212885b8928313b53ff07d79a28b156192df4c3e038d6c7ed2fdaabb6c8d4c03723f7db923cbbaa6f33eca9c686d843ab15165c4f1fbf39d5c427e5d789a28a79ad0f629a64f09e8bb51b4cf38f9df86a8e60275d5c6ecd8e5e49477c69523f70e4049dc269690cfddaa1d5e12d29537c06180e6fd866fd06dc22456bd3bdeaf33ff5a12d0843f49062060b8438a80aae53325844c9f5ade814098055a9d4dab1b9ca7042ffa7aa043de7ab75ef02c1c8078042f60eedfd92939d9c113ac997b5b2181edd6cbb5480a0914620e11cd4680f78a14c2d828e75a643ef58ee2976cc4d83e0f573b1f6c550c43cc5704d18191c576a6a1561f5905d71beae62509729542141015c21b1f3918c10a1708630abf28612dfc574fbf3af1ac64f324fffa74e378e1e487c38fa76029fb68d8cb80b545fa3c763e0abea20213d8251dad84e1d775694010202a27465b27d4f3f164b2f57d7a94972dedc4356d85ba6bcd0fa47fa816bb75b5550b73817430a3d81ba0e5261d136bb60272fa4ade5031e4afb9555c2c015edaada276c9fd095efdc5a8fcb5be7d462d82a75ebac1d3ebeb42fe9db199fa94f9900b5530350f42e788c40330b89461a00ddcee12249ff5088f
Decrypted data :
/Lux5\123456789_D\r\n\r\n1-3:0.2.8(42)\r\n0-0:1.0.0(210308231809W)\r\n0-0:42.0.0(12345678901234567890123456789012)\r\n1-0:1.8.0(039645.934kWh)\r\n1-0:2.8.0(000000.247kWh)\r\n1-0:3.8.0(000040.384kvarh)\r\n1-0:4.8.0(006192.037kvarh)\r\n1-0:1.7.0(00.846kW)\r\n1-0:2.7.0(00.000kW)\r\n1-0:3.7.0(00.000kvar)\r\n1-0:4.7.0(00.000kvar)\r\n0-0:17.0.0(27.600*kVA)\r\n0-0:96.3.10(1)\r\n0-0:96.13.0()\r\n0-0:96.13.2()\r\n0-0:96.13.3()\r\n0-0:96.13.4()\r\n0-0:96.13.5()\r\n!A22B\r\n
For info, I eventually got an email back from Creos to say that they had updated my meter to the latest version and asking me to try again.
When I deleted the previous Smarty Meter thing and created a new one it all worked perfectly. I’m not really sure what has changed since the frames seem identical except they now contain a lot more meter data but I’m not going to worry about that
This is very similar to experience of @piggel, so best advice for anyone who lands here later with a similar problem is to email the details to the Creos helpline then be patient. They do seem to sort it eventually.
Hi,
As a beginner on OpenHAB, I will just describe the steps, that I have performed, to have the Smarty available.
1-) Request your encryption key from CREOS
2-) Buy a cable: DSMR Dutch P1 Poort Cable for Smart Slimme Meter (Für ISKRA AM550/Sagemcom XS210 T210-D ) Available on Amazon
3-) For my installation: I have converted the USB to RJ45 (using LogiLink Over CAT 5/5e/ 6 Up to 60m USB Line Extender ) as the Smarty is far away from my OpenHAB server
4-) When USB is plugged on OpenHAB server, go on the system and check which port (ie: /dev/ttyUSB1) is using (on Debian go on: /dev → cd /dev; ls -lart)
5-) On OpenHAB: Install DSMR Binding
I perform a scan but it did not discover anything.
I have manually added the Bridge (dsmr:smartyBridge). To do so, you only need the port (cf 4-) and the key (cf 1-)
2 news Things will appears:
-device.label (Not really useful)
-main_electricity.label (This one will give you the channels needed)
Adding the ActualPowerDelivery channel:
It was not a big deal as I have followed the explanation from the previous post.
If any question, let me know.
Cheers,
Cyril
Hi everybody,
I can read electricity data through the DSMR/smarty binding, but I cannot see any channels providing information on the gas consumption. The binding page states that there are more meters that could be read. My gas meter sends the consumption data to my electricity meter (connected to my openHAB). Is it possible to read gas data from this binding in Luxembourg?
Cheers,
Gilbert
Gas consumption is a different thing. When you run discovery manual it should detect the meter or it could be your meter is not recognized. When your meter is not recognized look in the log for more information on what it did find.
If it didn’t find any thing you could try manually add a gas meter thing that is similar to the version you have. It might report some of the channels.
Dear Hilbrand,
Thanks for your answer. I indeed got some info in the log file, after manually running the thing scanner:
There are unrecognized cosem values in the data received from the meter, which means some meters might not be detected. Please report your raw data as reference: /Lux5\253663629_D
Here is the full log excerpt. Maybe it is helpful for you.
DSMR.log (20.1 KB)
It looks like the gas meter data is not connected to the electricity meter as the gas meter data is not present in the data as shown in the log file you provided. The values it report as missing are from the electricity meter. Therefore you might try to find out why the data is not present and ask your energy provider if they have an explanation for this.
Thanks a lot for that hint! I’ll contact them to inquire where the issue lies.
The gas company had connected the gas meter to the electricity meter (for their own metering), but it was not routed through the P1 port. All solved now. Unfortunately the water meter is from a different company and not connected to this system.
Update: I just found out, that their is also an outgoing P1 port on my dongle. But I would prefer to catch the data from the Dongle over Wifi.
Hello,
I am using 2 Smarty+ dongles (Smarty+ by Nexxtlab Smarty+ Ihre Energiedaten auf einen | Letzshop) to monitor Energy consumption and energy production. Both are attached to their Smart Meters over the P1 Port.
The data is visualized on a smartphone App.
Now I would like to read out this data on OpenHAB. Because the P1 Ports are in use, I cannot use the bridge described here in this thread.
Is there another possibility to read the data?
Thanks
After lots of packages got decrypted successfully, one package fails (maybe due to transfer error):
14:31:48.507 [WARN ] [.dsmr.internal.device.SmartyDecrypter] - Decrypting smarty telegram failed:
javax.crypto.AEADBadTagException: Tag mismatch!
at com.sun.crypto.provider.GaloisCounterMode.decryptFinal(GaloisCounterMode.java:623) ~[?:?]
at com.sun.crypto.provider.CipherCore.finalNoPadding(CipherCore.java:1116) ~[?:?]
at com.sun.crypto.provider.CipherCore.fillOutputBuffer(CipherCore.java:1053) ~[?:?]
at com.sun.crypto.provider.CipherCore.doFinal(CipherCore.java:853) ~[?:?]
at com.sun.crypto.provider.AESCipher.engineDoFinal(AESCipher.java:446) ~[?:?]
at javax.crypto.Cipher.doFinal(Cipher.java:2260) ~[?:?]
at org.openhab.binding.dsmr.internal.device.SmartyDecrypter.decrypt(SmartyDecrypter.java:213) [bundleFile:?]
at org.openhab.binding.dsmr.internal.device.SmartyDecrypter.processCompleted(SmartyDecrypter.java:190) [bundleFile:?]
at org.openhab.binding.dsmr.internal.device.SmartyDecrypter.parse(SmartyDecrypter.java:103) [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.OH1]
at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1.OH1]
at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1.OH1]
While this might happen, what happens afterwards is a mess. I get continuous buffer overflows:
14:31:49.547 [WARN ] [.device.connector.DSMRSerialConnector] - RuntimeException during handling serial event: 1
java.nio.BufferOverflowException: null
at java.nio.Buffer.nextPutIndex(Buffer.java:666) ~[?:?]
at java.nio.HeapByteBuffer.put(HeapByteBuffer.java:200) ~[?:?]
at org.openhab.binding.dsmr.internal.device.SmartyDecrypter.processStateActions(SmartyDecrypter.java:125) ~[bundleFile:?]
at org.openhab.binding.dsmr.internal.device.SmartyDecrypter.parse(SmartyDecrypter.java:102) ~[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.OH1]
at gnu.io.RXTXPort.eventLoop(Native Method) [bundleFile:5.2.1.OH1]
at gnu.io.RXTXPort$MonitorThread.run(RXTXPort.java:108) [bundleFile:5.2.1.OH1]
Any idea how to solve this ? @hilbrand ?
@HSorgYves I’ve added an extra check to the [DSMR beta binding here in the marketplace.] to handle the overflow. (DSMR Smartmeter (Beta)). You can try this version by installing from the marketplace and see if that performs better. (Note that it is a jar and requires to have another binding installed with serial support bundle dependency, see note in marketplace topic)
The beta version was working fine. However the official version 3.4 does not. Didn’t you push the changes to the main repository?
No the changes are not yet in the main repo, I was still testing and wanted to make some improvements. Therefore it didn’t make the 3.4 release.
Thanks for the quick reply. I will revert back to the 3.3 Beta then. I confirm again that it was working fine under OH 3.3. Or is there another Beta I should test?