New DSMR-binding for OpenHAB 2

Add-ons Bindings
21

I have implemented an aynchronous version of the binding. I have added this as download here:

About the multiple listeners. The DSMR-binding has a DSMR-bridge and DSMR-meter things. The DSMR-bridge is the only thing communicating with the Serial port. If there are communicaton problems the bridge will go offline. The OH2 framework will make sure the Things relying on this Bridge are going offline.
So imho there is no need for the DSMR-meter Things to know anything about the Serial Port.

I did some testing with disconnecting and connecting the cable to the P1-meter. In my test setup this is very responsive (as expected of an event-driven implementation). I need to do some additional testing as the behaviour in problem situations is not what i want to have.

I did not commit anything yet, but you can try the binary version. If i have commit the changes, i will let you know.

I will have also a look at the autodiscovery. I very much like the idea that without manual configuration the binding will become functional. So i will look at your work and see if i can reuse anything.

22

I made again some updates and you can find a newer version in the thread that is linked above.
The newest version also supports autodiscovery of the DSMR bridge Thing.

I committed the changes into my repository. Hope you enjoy this version.

23

I tried the new changes for an hour or two now and it seems to work well! Want to see the performance in CPU overnight. Iā€™ve looked through the commits and it seems quite a change. I did notice that, when I disconnect the cable, Linux decides to make a new port (/dev/ttyUSB0 becomes dev/ttyUSB2). So, I change the serial port setting to reflect this. The bridge gets to ONLINE, but the associated meters stay offline. Could it be that the identity is coupled somehow to the serial port name?

24

It was indeed quite a change to make the binding completely event driven.

Thanks for your testing. The autodiscovery method uses a hexidecimal hashcode of the portname as identifier of the bridge thing. However this is just a chosen algorithm to create a unique id (adding it manually generates also an id based on a different algorithm and with manual configuration you choose the id yourself).
So i would expect changing the port setting would not affect the meters. I will investigate this.

25

I noticed a pretty substantial improvement in CPU usage in the event-driven implementation (btw, itā€™s still running here, but we probably have very similar meters). See the CPU usage in Grafana: http://imgur.com/a/0Deca

@rtvb if you have time, it would be great to see if the new changes to the binding are working, so perhaps youā€™d like to compile and test the latest version? (I just uplodaded the .jar Iā€™m testing with: https://github.com/gedejong/openhab2-addons/blob/master/org.openhab.binding.dsmr-2.1.0-SNAPSHOT.jar)

26

Hello,
Sorry to break in, but i have a problem with the latest binding. If i need to start a new topic just let me know.
Installed the latest binding and the DSMR-bridge was found succesfull. Added it and set the correct serial port (/dev/SmartMeter). First tried to let it autodiscover the correct settings, that didnā€™t work. Then tried setting it using Paper-UI.
when triying to set it (9600 8N1) i canā€™t save it. The only way i can set the serial port is using jsondb and type it there:

In the log i can see that it uses that setting but i have a ā€œerrorā€

when i use cu (cu -l /dev/SmartMeter -s 9600 --parity=none) it works flawlessly.
Do you have a suggestion what i can try?

27

Iā€™m not sure if this is going to help, but could you try setting the serialPortSetting to: "9600 8N1 IGNBRK"?

28

tried it with the suggested IGNBRK, but that makes no difference whatsoever.

29

First of all, whatā€™s going on is: the serial line has a special bit which goes high (break interrupt) when the serial data input line sends zeroes for longer than the size of one word. Normally it would send ones when idle or flip like crazy when sending data. Sending zeroes usually means that the line is broken. However, bright minds thought using the break interrupt is useful to send out-of-band data. Perhaps your meter is doing this and ours isnā€™t. So, first of all, I guess weā€™d like to know which meter you have!

Then, while you reply to this message, Iā€™ll compile a new test version with the break interrupt detection removed. Hopefully that will solve your problem, although itā€™s not really a definitive solution. Perhaps the ā€˜rightā€™ solution would be to see if the break interrupt is high for a longer amount of time (say, one second), before triggering an error. Well, lets first see if the patched version works.

30

Ok, weird, the file upload feature of github seems broken. Perhaps because of the S3 outage before. Anyways, I compiled the patched version and uploaded a jar (which is rather ugly) here: https://github.com/gedejong/openhab2-addons/blob/test-dsmr-branch/addons/binding/org.openhab.binding.dsmr/org.openhab.binding.dsmr-2.1.0-SNAPSHOT.jar

31

Thanks alot. Just installed the binding and the fault is still there.
The device is a ISKRA

/ISk5\2MT382-1004
The Telegram ends with a ā€œ!ā€.

However i did find another error:

22:47:45.157 [ERROR] [org.openhab.binding.dsmr            ] - FrameworkEvent ERROR - org.openhab.binding.dsmr
org.osgi.framework.BundleException: Could not resolve module: org.openhab.binding.dsmr [236]
  Another singleton bundle selected: osgi.identity; osgi.identity="org.openhab.binding.dsmr"; type="osgi.bundle"; version:Version="2.1.0.201702261333"; singleton:="true"

        at org.eclipse.osgi.container.Module.start(Module.java:434)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1582)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.incStartLevel(ModuleContainer.java:1562)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.doContainerStartLevel(ModuleContainer.java:1533)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1476)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.container.ModuleContainer$ContainerStartLevel.dispatchEvent(ModuleContainer.java:1)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.framework.eventmgr.EventManager.dispatchEvent(EventManager.java:230)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]
        at org.eclipse.osgi.framework.eventmgr.EventManager$EventThread.run(EventManager.java:340)[org.eclipse.osgi-3.10.101.v20150820-1432.jar:]

donā€™t know if this means anything, get the same kind of error for my zwave addon and that works fine.

32

@arjveld Your definitely posting to the correct thread.

Could you please set the logging of the binding to ā€˜DEBUGā€™ and post the results?

I will look in to the problems with setting the configuration from Paper UI.

@edejong The IGNBRK is certainly not supported in my branch. I expect it will fall back in autodiscover mode when you are doing this.
I also fixed the bug you experienced when changing the serial port. I commited the changes and uploaded a new binary version.

33

@arjveld.

Can you please post a full telegram you are receiving?

I need to know if you have a DSMR v4 or earlier version. The fact that the telegram ends with ā€˜!ā€™ makes me thing you have a DSMR V3 meter.
It is also very helpful if you can try using the serial port setting 9600 7E1 (please use my version of the binding).

34

@mvolaart i do that by using log:set DEBUG org.openhab.binding.dsmr

I have a version 3 that is correct.

35

I did try to set it to 9600 7E1 and the message stays the same.

i also did a quick cu:

[23:18:16] pi@openHABianPi:~$ cu -l /dev/SmartMeter -s 9600 --parity=none
Connected.
Sk5\2MT382-1004

0-0:96.1.1(5A424556303035313834303139323133)
1-0:1.8.1(06976.657*kWh)
1-0:1.8.2(05643.656*kWh)
1-0:2.8.1(00000.008*kWh)
1-0:2.8.2(00000.005*kWh)
0-0:96.14.0(0001)
1-0:1.7.0(0000.47*kW)
1-0:2.7.0(0000.00*kW)
0-0:17.0.0(0999.00*kW)
0-0:96.3.10(1)
0-0:96.13.1()
0-0:96.13.0()
0-1:24.1.0(3)
0-1:96.1.0(3234313537303032393933313038383132)
0-1:24.3.0(170228230000)(00)(60)(1)(0-1:24.2.1)(m3)
(04597.540)
0-1:24.4.0(1)
!
~.
Disconnected.
36

Thank you for the information. It is good to know we are dealing a V3 meter.

If the meter is following the standard it should use 9600 7-databit, even parity, 1 stop bit as communication standard. From the cu man-page i cannot find how to set the data-bits and stop bits.

To figure this out i need the following information:

Did you use the v1.9 version of the binding?
Yes: Configure the same serial port settings as you used for v1.9 and let the binding run for some minutes in ā€˜DEBUGā€™-log mode.
No: Can you please put the binding into ā€˜DEBUGā€™-log and let the binding run twice using the settings ā€œ9600 8N1ā€ and ā€œ9600 7E1ā€?

Iā€™m really interested in these logs.

Could you please try:

  • If cu is wo
    Iā€™m very interested in the following information:
  • Debug log for some minutes
  • If you tried also the v1.9 version of the binding.
37

first of all.
tried cu with different settings (parity none, even and odd in that order) with the debug option.this is the outcome:

[10:38:02] pi@openHABianPi:~$ cu -d -l /dev/SmartMeter -s 9600 --parity=none
cu: fconn_open: Opening port /dev/SmartMeter (speed 9600)
cu: fconn_set: Changing setting to 1, 2, 2
Connected.
/ISk5\2MT382-1004

0-0:96.1.1(5A424556303035313834303139323133)
1-0:1.8.1(06980.398*kWh)
1-0:1.8.2(05645.254*kWh)
1-0:2.8.1(00000.008*kWh)
1-0:2.8.2(00000.005*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(0000.20*kW)
1-0:2.7.0(0000.00*kW)
0-0:17.0.0(0999.00*kW)
0-0:96.3.10(1)
0-0:96.13.1()
0-0:96.13.0()
0-1:24.1.0(3)
0-1:96.1.0(3234313537303032393933313038383132)
0-1:24.3.0(170301100000)(00)(60)(1)(0-1:24.2.1)(m3)
(04600.210)
0-1:24.4.0(1)
!
~.cu: Exit status 0
cu: fconn_close: Closing connection


Disconnected.
[10:38:37] pi@openHABianPi:~$
[10:38:37] pi@openHABianPi:~$ cu -d -l /dev/SmartMeter -s 9600 -e
cu: fconn_open: Opening port /dev/SmartMeter (speed 9600)
cu: fconn_set: Changing setting to 2, 2, 2
Connected.
/ISk5\2MT382-1004

0-0:96.1.1(5A424556303035313834303139323133)
1-0:1.8.1(06980.398*kWh)
1-0:1.8.2(05645.259*kWh)
1-0:2.8.1(00000.008*kWh)
1-0:2.8.2(00000.005*kWh)
0-0:96.14.0(0002)
1-0:1.7.0(0000.20*kW)
1-0:2.7.0(0000.00*kW)
0-0:17.0.0(0999.00*kW)
0-0:96.3.10(1)
0-0:96.13.1()
0-0:96.13.0()
0-1:24.1.0(3)
0-1:96.1.0(3234313537303032393933313038383132)
0-1:24.3.0(170301100000)(00)(60)(1)(0-1:24.2.1)(m3)
(04600.210)
0-1:24.4.0(1)
!
~.cu: Exit status 0
cu: fconn_close: Closing connection

Disconnected.
[10:40:18] pi@openHABianPi:~$ cu -d -l /dev/SmartMeter -s 9600 -o
cu: fconn_open: Opening port /dev/SmartMeter (speed 9600)
cu: fconn_set: Changing setting to 3, 2, 2
Connected.
cu: Got hangup signal
cu: Exit status 0
cu: fconn_close: Closing connection

Disconnected.

Next iā€™ve set a logfile for dsmr.
using 9600 8N1
9600-8N1.pdf (92.8 KB)
Using 9600 7E1
9600-7E1.pdf (149.4 KB)

38

Donā€™t know if it relevant for this topic if not iā€™ll make a new topic for it

I have a question about which nrjavaserail library I have to use. Iā€™m now using ā€œnrjavaserial-3.12.1.jarā€ downloaded from nexus repository.
Iā€™m running out of options for my OH2(#814) setup on a Synology NAS (x86) with DSM6.1.
I found out with ā€œdmesgā€ that the driver version was not compatible and that was fix by jumbotroll (http://www.jadahl.com/synology6.1/ a couple of days back).
I changed the permission settings for /dev/ttyUSB0 to 666.
And still iā€™m getting this in the log.

[ERROR] [inding.dsmr.internal.device.DSMRPort] - Port /dev/ttyUSB0 does not exists gnu.io.NoSuchPortException at gnu.io.CommPortIdentifier.getPortIdentifier(CommPortIdentifier.java:273)[230:com.neuronrobotics.nrjavaserial:3.12.1] at org.openhab.binding.dsmr.internal.device.DSMRPort.open(DSMRPort.java:176)[232:org.openhab.binding.dsmr:2.1.0.201702282146] at org.openhab.binding.dsmr.internal.device.DSMRDevice.handleInitializeDSMRDevice(DSMRDevice.java:353)[232:org.openhab.binding.dsmr:2.1.0.201702282146] at org.openhab.binding.dsmr.internal.device.DSMRDevice.handleDeviceState(DSMRDevice.java:228)[232:org.openhab.binding.dsmr:2.1.0.201702282146] at org.openhab.binding.dsmr.internal.device.DSMRDevice.access$1(DSMRDevice.java:215)[232:org.openhab.binding.dsmr:2.1.0.201702282146] at org.openhab.binding.dsmr.internal.device.DSMRDevice$1.run(DSMRDevice.java:193) 232:org.openhab.binding.dsmr:2.1.0.201702282146] at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)[:1.8.0_121] at java.util.concurrent.FutureTask.run(FutureTask.java:266)[:1.8.0_121] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)[:1.8.0_121] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)[:1.8.0_121] at java.lang.Thread.run(Thread.java:745)[:1.8.0_121]

Setting the log level to DEBUG does not give me any use full information where this problem could be.
I also set the EXTRA_JAVA_OPTS="-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyS0:/dev/ttyS2:/dev/ttyACM0:/dev/ttyAMA0" in the file /runtime/bin/setenv ( a quick solution to find the problem. then iā€™ve to find the correct spot for this code line)

There for i think its the nrjavaserail library or something else on my system but i canā€™t think of anything else what to check or change.
I made the openhab2 users part of the root group so I can rule out that permissions are the problem. I set these back if I got it to work.

I hope that someone has any idea what to do next.

39

@arjveld Thank you very much for the logs.

It is revealing some weird behavior that that may be the cause of the problems you experience.

I will look into this.

Iā€™m also still interested if you used also the 1.9 version of the binding (OH1) successfully? (No need to do additional testing, but if you used it successfully it is relevant information)

@levers I think you have more success opening a new topic. I expect that the cause of the problems you experience is outside of the DSMR-binding and this topic is only targeting the DSMR-binding so not everybody who can help will see this.

40

@mvolaart Sorry, forgot to tell. the 1.9 binding iā€™ve never used. On openHAB1 iā€™ve used it but that was the 1.8.
back then it was working.

@levers Is it the only usb device and can you use it using cu. If you donā€™t make usb devices persistent linux has a habbit of changing the usb devices at random (when there is more than 1 usb device)