Thank you @5iver and @wborn. I will try both approaches and report. Out of interest @wborn, if I understand it, OH3 core requires Java 11: would the 2.5 bindings work with it? By the way, in case you have not been following the other discussions about nrjavaserial, 5.1.1+ will have, at long last, a functioning rfc2217—the implementation that sat there for a long time was behind inaccssible code…
No they won’t work. Not because of Java 11, but because all Eclipse SmartHome packages were renamed from org.eclipse.smarthome to org.openhab.core. We do have a Jenkins build job for porting all OH2 add-ons to OH3 so we can test the add-ons with OH3.
So you can also try the OH3 snapshot build and update the nrjavaserial bundle in it and then every add-on using the serial transport should already work. I.e. not one of those we have to update as listed in this issue. I’ll probably do another PR for adding a version range to the imports of the add-ons still using gnu.io so they work with 3.12-5.x. That way everyone can use their favorite nrjavaserial version. 
The new UI is still a bit buggy though. You sometimes have to manually refresh the page.
Thank you for the suggestions. I had a quick look at the master branch of openhab-addons and it looks like only a small number of bindings made it there—but I can see pretty much all of them in the artifacts of that Jenkins job, except for the http binding (which is still OH1 I believe). It is an intriguing idea to try the new build instead of OH2, though I am a little unsure about its overall stability at this stage—if things do work, I would like them to run my home just as 1.8.3 has been happily running it for a few years 
I wonder what is your take on the current OH3 stability vs OH2.5 in “production”—the UI does not concern me?
My current workflow is: I am (just) recompiling OH2.5 with the 5.1.1 of nrjavaserial (which does not have the rfc2217 but is the newest in Maven repos) by having manually edited these to depend on it instead of the OH2 variant that you built:
modified: bom/compile/pom.xml
modified: bom/runtime/pom.xml
modified: features/karaf/openhab-tp/src/main/feature/feature.xml
this way I will have the right imports. Then I will
rsync -a ~/.m2/repository /usr/local/libexec/openhab2/runtime/system
and then I manually
cp ~/nrjavaserial/build/libs/nrjavaserial-5.1.2.jar /usr/local/libexec/openhab2/addons/
then I will do what @5iver suggested, ie. clear the OH caches, tmp, and use Karaf to
bundle:uninstall com.neuronrobotics.nrjavaserial
bundle:install -s file:///path/to/my/file.jar
and see if that works. Does it seem like a reasonable approach?
I wouldn’t recommend using OH3 for production only use it for testing. 
Since you’ve already recompiled the serial transport with a 5.x nrjavaserial version, bnd will have added a [5.x,6) version range to the manifest. So you no longer need to recompile the core if you just want to test new nrjavaserial 5.x versions.
Personally I would only recompile and update the bundles in an existing OH 2.5.x release. But that requires knowing exactly what bundles to update.
1 Like
Ah, you just made me wonder: do I also need to recompile the 2.5.5 zwave binding to take advantage of the new nrjavaserial? Or is its functionality encapsulated through an openhab-core abstraction?
It’s using the serial transport so that’s an advantage this time around. 
So it shouldn’t be recompiled.
1 Like
Thank you, @wborn, very much indeed. Without your guidance I would not be able to proceed. I see the core has finished compiling—funny, it got quicker, only 17 mins (but with -DskipTests=true). Fingers crossed I get to the top of what is affecting nrjavaserial under OH today. From my tests of nrjavaserial using a hello world app yesterday I have, at long last, seen it not crash under FreeBSD. I will look for the crash pid file if it does.
1 Like
For an even faster build, try a parallel build, disable static code analysis, tests and Karaf feature validation
mvn clean install -DskipChecks=true -DskipTests -Dfeatures.verify.skip=true -T 1C
Builds in less than 1 minute on my aging quad core i7-6700K CPU @ 4.00GHz
There’s now also a PR for updating the version ranges of the add-ons still depending on gnu.io:
1 Like
Hmm… I am still not doing it right. Even though I cleared the system of all variants of nrjavaserial, and cleared tmp and cache, having then reinstalled in Karaf from the file carefully placed in addons, I get this as soon as the ZWave binding tries to open the port (this is trying with rfc2217, I will try the direct route in a few moments):
2020-05-10 10:00:57.309 [INFO ] [zwave.handler.ZWaveControllerHandler] - Attempting to add listener when controller is null
Native Library /var/db/openhab2/userdata/tmp/libNRJavaSerial_openhab_0/libNRJavaSerial.so already loaded in another classloader
java.lang.UnsatisfiedLinkError: Native Library /var/db/openhab2/userdata/tmp/libNRJavaSerial_openhab_0/libNRJavaSerial.so already loaded in another classloader
at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1900)
which is followed later by:
java.lang.ExceptionInInitializerError thrown while loading gnu.io.RXTXCommDriver
java.lang.NoClassDefFoundError: Could not initialize class gnu.io.RXTXCommDriver thrown while loading gnu.io.RXTXCommDriver
I suppose I am missing a step in Karaf.
I have tried once again, making sure the only things I have in addons are:
-rw-r--r-- 1 root wheel 713K 10 May 09:23 nrjavaserial-5.1.1.jar
-rw-r--r-- 1 root wheel 185M 21 Apr 16:25 openhab-addons-2.5.4.kar
-rw-r--r-- 1 root wheel 3.1M 4 May 12:09 org.openhab.binding.zwave-2.5.5-20200504.110626-5.jar
-r-xr-xr-x 1 root wheel 70B 19 Apr 14:08 README
Cleared again cache and tmp, then bundle:uninstall and install of the above nrjavaserial. This time, I can see both the RFXCOM binding and ZWave started. Unfortunately—and unlike when running nrjavaserial without OH in place—I get the Abort trap:
RXTX uucp_lock() /var/spool/lock/LK.255.000.242 is there
Abort trap
I searched for
sudo find / -name "*hs_err*"
and there is nothing on the system. Do I need to start OH with some flags to tell it to generate the hs_err file when Java aborts? Also, how can I be sure OH is defnitely using the new library—this is what I did in Karaf, but is that sufficient?
list -s | grep serial
214 │ Active │ 80 │ 5.1.1 │ nrjavaserial
Also, when I tried over rfc2217 I got:
check_lock_status: device is locked by another application
check_lock_status: device is locked by another application
check_lock_status: device is locked by another application
and no attempt to actually connect (whilst monitoring the remote ser2net USB server).
It all feels as if I were not using the new version of nrjavaserial but something older…
Debugging OpenHAB is hard. 
If it doesn’t crash the JVM and only logs errors or throws exceptions it won’t generate the file. You can also configure where it will be created using a JVM startup option. IIRC it’s generated by default in the openHAB userdata dir.
Usually I update the nrjavaserial bundle, then stop openHAB, remove the userdata/tmp/libNRJavaSerial_openhab_0 dir and restart openHAB to be 100% sure the right library is used.
After that you’ll see it will recreate the dir and extract a new .so file into it. You can then run md5sum on the extracted .so file to see if the MD5 matches that of the .so file you’d expect it to be.
Does it work properly if you only use one serial connection type? I.e. not both a physically connected device and a rfc2217 connection type? I have never used rfc2217 serial connections or a combination of both.
I cannot be sure. In my case I have both RFXCOM (which works perfectly) and ZWave (which is causing all these issues). The difference is that RFXCOM directly handles the port over TCP (as a bridge) while ZWave expects the openhab-core+nrjavaserial to do it. I have only been able to test (leading to that Abort trap) the RFXCOM + ZWave over a “local” socat’ed port.
I have not been able to successfully test ZWave over rfc2217, despite confirming, yesterday, that I can get connected using a plain Hello World nrjavaserial-5.1.1+ app, because there is another issue: ZWave binding tries to .getSerialPortIdentifier of the rfc2217 port, but for some reason (which I tried to debug) that call goes down the wrong abstraction tree and ends in RxTxPortProvider.java instead of RFC2217PortProvider.java, which then ends up causing “no such port”… Please see my findings on this GH issue, perhaps you can see something that could get this further.
Unfortunately, I think I have no other option but to give up on trying to fix rfc2217 in openhab. The core’s use of it is incomplete and likely has more issues. I am not competent enough to do it on my own, and even with your extremely helpful hints I would need more support from an existing OH developer to get properly set-up. I realise you and others have other things you need to be focusing on, so with much regret, I think I have to give up. 
I just tried connecting to my Dutch smartmeter over rfc2217 using the DSMR binding by @Hilbrand while also being connected to a Plugwise Stick on Ubuntu. In the end I got them both working at the same time.
I used a .things file for configuring the rfc2217 connection for the DSMR Thing:
Bridge dsmr:dsmrBridge:smartmeter [serialPort="rfc2217://192.168.1.26:3000"] {
Things:
device_v5 dsmrV5Device [channel=-1]
electricity_v5_0 electricityV5 [channel=0]
}
The UI wouldn’t allow me to enter a port because it only allows for selecting known serial ports. Adding them using gnu.io.rxtx.SerialPorts will probably not work because these rfc2217:// URL prefixes are an openHAB convention.
Another issue with these rfc2217 connections is that not all serial port operations properly work. For the DSMR binding it would throw an exception:
23:02:41.156 [DEBUG] [.device.connector.DSMRSerialConnector] - Port does not support requested port settings (invalid dsmr:portsettings parameter?): rfc2217://192.168.1.26:3000
org.eclipse.smarthome.io.transport.serial.UnsupportedCommOperationException: gnu.io.UnsupportedCommOperationException
at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:157) ~[?:?]
at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.open(DSMRSerialConnector.java:158) [bundleFile:?]
at org.openhab.binding.dsmr.internal.device.connector.DSMRSerialConnector.open(DSMRSerialConnector.java:119) [bundleFile:?]
at org.openhab.binding.dsmr.internal.device.DSMRSerialAutoDevice.start(DSMRSerialAutoDevice.java:152) [bundleFile:?]
at org.openhab.binding.dsmr.internal.device.DSMRSerialAutoDevice.restart(DSMRSerialAutoDevice.java:162) [bundleFile:?]
at org.openhab.binding.dsmr.internal.device.DSMRDeviceRunnable.run(DSMRDeviceRunnable.java:82) [bundleFile:?]
at java.lang.Thread.run(Thread.java:834) [?:?]
Caused by: gnu.io.UnsupportedCommOperationException
at gnu.io.rfc2217.TelnetSerialPort.enableReceiveThreshold(TelnetSerialPort.java:948) ~[?:?]
at org.eclipse.smarthome.io.transport.serial.rxtx.RxTxSerialPort.enableReceiveThreshold(RxTxSerialPort.java:155) ~[?:?]
... 6 more
After I commented those incompatible operations, and used the updated/recompiled binding no exceptions were thrown and the connection using rfc2217 with ser2net properly worked.
I see that the ZWave Binding by @chris is using the same operations that will throw exceptions when used with rfc2217 connections.
There are others too, see UnsupportedCommOperationException in this nrjavaserial TelnetSerialPort.java
So my conclusions are:
- it should be possible to get physically connected devices and rfc2217 devices working at the same time
- there are Paper UI limitations that currently make it difficult to use these rfc2217 connections and it’s probably best to configure them using .things files
- it’s not guaranteed that all operations on normal serial ports also work on rfc2217 connections, thus they are currently not transparent or a drop in replacement for a normal serial port
3 Likes
3 Likes
Congratulations on having rfc2217 run with the DSMR binding. I would have wanted to see the same with ZWave, but I must agree with both of you that rfc2217 is not a transparent/drop-in replacement for a normal serial port.
Regrettably, I will have to leave this for others to resolve—but based on the comments from @chris, I assume this is unlikely to get looked at by OH developers. Unfortunately, this issue, combined with the locking-related abort traps when using the ZWave binding on FreeBSD is a blocker for my move towards OH 2 or 3—having the ZWave stick on a remote machine, away from the server, is a must for my installation.
I would still be happy to occasionally test things if anyone needs that, please ping me.
Above all: thank you for your help. Much appreciated.
There are other ways to access a zwave controller over IP, so no need to give up. Do you have a post about your installation and why you require this?
1 Like
I have first tried with a locally socat’ed port. Unfortunately, that does not work, because the binding throws Abort traps under FreeBSD. I have gone to the lengths of debugging it down to nrjavaserial to eliminate the library as the source of the aborts. I found that nrjavaserial works fine as of 5.1.1+ (some issues got fixed). However, running OH 2.5 with the new version of the library still breaks the runtime.
I was hoping to just connect ZWave binding to the remote ser2net just like RFXCOM binding does it, but @chris has wisely explained that it would not be possible to make ZWave do that, as instead the ZWave binding must rely on the rest of OH for serial port functionality, with or without RFC2217. He also explained that very few users need the RFC2217 and so it is not going to happen. I am of the opinion that having a location remote from the server for any antenna-like devices is essential, but that is only my opinion, I suppose.
Since RFC2217 is essentially broken/incomplete in OpenHAB as of now, and since I cannot use ZWave over a socat’ed port on FreeBSD that gives me no other options that I could think of.
For completeness, ZWave is also not working on FreeBSD using a locally plugged-in “real” USB stick, see this long-running discussion, in which a good number of other users went through the same iterations as I did, eventually giving up—I just tried to debug it a bit further, I suppose.
What devices do you have, what are the distances between them, and what materials are the walls/floors separating them?
OH runs very well on other distributions. Why not use something else?
Approx 40 ZWave switches, sockets and a couple of rollers. Walls are stone, approx 1.5m in thickness, mostly 19th century. ZWave works very well for me when the antenna is in the attic. I do not want my server to be there.
Because I like FreeBSD and I have substantial experience of it. I no longer want to run OH 1.8.3 on a Pi with a Linux. If I cannot run OH 2/3 on FreeBSD I would rather not use OH anymore.
This topic was automatically closed 41 days after the last reply. New replies are no longer allowed.