I think what needs to happen is the changes from the original NeuronRobotics repo need to be pulled into the OH fork: GitHub - openhab/nrjavaserial: A Java Serial Port system. This is a fork of the RXTX project that uses in jar loading of the native code.
After managing any conflicts in this, we rebuild the OH-specific version without liblockdev and other changes. Not sure how much work this means…
1 Like
I just compared the openhab/nrjavaserial with the current head of neurorobotics/nrjavaserial and the two branches merge cleanly. Last commit in openhab/nrjavaserial is from 2017, by the way.
Either all of OH modifications have been already merged into the neuronrobotics original, or (more likely) OH-specific work was done in another repo—but I cannot find it, and I cannot see any openhab-labelled PRs in the neuronrobotics original, either.
If you have hunted down the location of the OH-specific changes, I can compare.
In any case, my understanding is that the newer nrjavaserial introduces a native way of dealing with locking, hence I am keen to test it. My build succeeded yesterday and I have been asking for some help to figure out how to test it. I will have an answer this evening.
I have done a quick test using nrjavaserial-5.0.0. It still crashes OH runtime but now gives a different error in the rfc2217 issue—see the Github issues I linked for more info. I suspect, as you did @MrRusch, that we need to get those OH-specific patches to make that work.
Well, there’s some information in the repo’s README under “Some of the features we have added”. But if you managed to merge latest code from original into OH-fork, they should all be included still?
@MrRusch, please see the GitHub issue discussion, as it is a bit further now. The OH version of nrjavaserial was built using additional flags and a liblockdev library (not present on FreeBSD) by @wborn, but that seems to be no longer necessary. We need to figure out what exactly crashes the runtime in the new (and perhaps the old) library for me and you under FreeBSD and hopefully get a fix for that—we see exactly the same errors and crashes, after all, on two different installs, albeit both under the same OS.
- The openhab/nrjavaserial fork was used to produce nrjavaserial 3.12.0.OH which was used with OH 2.0.0 - 2.3.0.
- For OH 2.4.0 - OH 2.5.x we’ve been using nrjavaserial 3.15.0.OH2 produced by this wborn/nrjavaserial-builder
Perhaps @Kai can archive the openhab/nrjavaserial repo so people no longer waste their time on it?
We needed to upgrade nrjavaserial for OH 3 because it depends on Java 11 and the library would crash the Java 11 JVM on Windows (openhab-core#1384). Since nrjavaserial now uses a different locking mechanism and has some fixes, the official nrjavaserial library is now used with OH 3 (openhab-core#1426).
I’ll update the version we use to something recent before OH 3 is released. Haven’t done so yet because there is like a new nrjavaserial release every week or day nowadays. 
2 Likes
Good idea. Done.
1 Like
This being weekend, I plan to recompile OH2.5 again against nrjavaserial 5.0.2 to see if that made a difference. I think I will also do a Hello World in Maven with this version of nrjavaserial to see if it trips up under FreeBSD sans OH. If it does, it would make it easier, at least, to debug nrjavaserial issues. If all fails, I will go the bhyve/Openhabian/Debian route and sit out till I can run OH properly under FreeBSD. If anyone has any other suggestions, please share.
Find the Java hs_err_pid file for the crash, create an issue for it in the nrjavaserial issue tracker and attach the file. 
Unfortunately, OH 2.5 still crashes with nrjavaserial 5.0.1 and 5.0.2:
RXTX uucp_lock() /var/spool/lock/LK.255.000.242 is there
Abort trap
Thanks (again) for the suggestion, @wborn, about hs_err_pid. I cannot see it anywhere on the system, having run sudo find / -name hs_err_pid. Any other artefacts I could locate to help debug?
It has the process ID of the crashed process in it. So try:
sudo find / -name hs_err_pid*.log
Right. I’ve got the same lock problem - running openHAB in an iocell/jail on freebsd.
I’m happy to put some effort into resolving this. What’s the current state of play? Have any of you got a working config, or are you all getting the lock issue every time?
It depends. If you plan on locally plugging-in a USB ZWave stick, then all of us get abort traps and it is unusable. For that reason, and also because I prefer to have my ZWave away from the server running FreeBSD/FreeNAS, I have pushed for an RFC2217 connection. After a lot of effort on the side of several community members, that seems to work, but I need to do more testing (tomorrow) because I am unsure how stable it is.
If you are thinking of a remote USB device and using socat to create a local port, you will get abort traps just as if you plugged it in to the server. Realistically, rfc2217 is the only option if you need ZWave. For RFXCOM USB (which I also use) it works well just over TCP. No experience of other types of USB in my setup.
I had the same error and I tried this solution but the erros is still there… what should I do?
Have you cleared the OpenHAB caches? On FreeBSD/FreeNAS delete the files in /var/db/openhab2/userdata/cache/ and for a good measure also in /var/db/openhab2/userdata/tmp/
After restarting OpenHAB it will throw a Java error about unresolved dependency (in the log), then a few minutes later it restarts again, populates the cache, and starts working—at least for me.
You can confirm if you are using the newer version of the ZWave binding in Karaf with list -s | grep zwave
I’ve managed to get it working in a cage ok - I fixed devfs to make the device node available, and I was able to plug the zwave controller into the machine and poll devices inside of OpenHAB. I did then get the lock file failure - removing the lock file by hand fixed it until I got the issue again.
So, my problem appears only to be that the usb device lock file isn’t being managed properly. Are there other issues too?
(This was using the most recent openhab2 from the freebsd ports).
Joe
The locking issue is the problem—see the long thread (bottom of it) for more on that, as well as a good few reports on Github. There is an underlying issue in either nrjavaserial or in OH itself that affects lock handling with USB devices. The only way I have managed to bypass that is by using rfc2217 connection to a remote Pi running nothing other than the ZWave stick (and RFXCOM USB in my case).
Any other issues? I am not sure if Homekit integration works and I do not know if that is a FreeBSD or an OH issue. I have just failed on it, and I am awaiting info on a newer jar of the add-on to test. Having hit a good few walls with OH on FreeBSD so far, I am experimenting with HA+FreeBSD which seems to run smoother, no locking issues etc. 
What’s HA?
Are there any ports available to support the remote zstick? Can that be run on the same host and networked via the loop back?
I’ve seen a lot of file locking code over the years. Why are they rolling their own? There are standard plock/flock semantics available on most posix operating systems.
That is an interesting idea. I suspect all you need to do is install ser2net (from pkg/ports), add a line in its config pointing to the USB stick and expose on a port of your choice. Then connect to it using rfc2217://localhost:port as the ZWave port specifier. I suppose you could run it in the same or a different jail.
If you want to try this, make sure to use the newest version of the ZWave binding from this post: [SOLVED] [Zwave, Zigbee, ...] RFC2217 remote serial port HowTo? - #28 by wborn