Wishing you success @MrRusch!
@MrRusch, I have just recompiled the native code for nrjavaserial and submitted a PR to them. Interestingly, my executables had different filenames from yours. Did your not end up as:
src/main/c/resources/native/freebsd/x86_32/libNRJavaSerial.so
src/main/c/resources/native/freebsd/x86_64/libNRJavaSerial.so
somehow? In any case, this is what I have PRed. Hope it helps them help us, and in the meantime, if you have any success or otherwise with getting the ZWave stick not crash OH runtime, please share.
PS. Never mind—you just ended up somehow getting .txt extension, I suppose the files must be the same.
Upload restrictions on file extensions.
The recompiled version has just been merged into the master. Even if there is a release of 5.0.0 soon I am unsure if it helps. In the meantime, I am trying to rebuild openhab-core@2.5.0 having updated the only 2 references to nrjavaserial that I can see in its 2 pom.xml files to 5.0.0. If I succeed I will report. Unfortunately, I could not follow the older OH1.8 instructions from Serial port access from FreeBSD as the new openhab-core repo does not seem to have the nrjavaserial.jar anywhere in it. I hope it just pulls the right one from GH, somehow.
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