Instructions for openHAB on FreeNAS?

Sadly no. From what I understand, OH has compiled a version of nrjavaserial without liblockdev library - to resolve issues like these. But, the JAR in the distribution package has “OH” in its name, insinuating that it is the recompiled version; and grabbing an older one and replacing it makes no difference either.

I’ve also tried adjusting the devfs rule to pass through the USB device with open permissions, and for the openhab user specifically

/sbin/devfs rule -s ${NUMBER} add path 'cua*' mode 777 group 235 unhide

Same error, same error same error…

Ironically, the closest to working I get is when not adding the openhab user to the dialer group. This way the JRE never crashes, but it’s stuck in a loop trying to recreate the lock file, so the Zwave binding goes offline/online once every minute. It actually stays up! But I mean, no…

I have a feeling the issues is related to how OpenJDK utilizes the nrjavaserial package. Something may have changed in later versions of OpenJDK8. Perhaps reverting back a few versions would give some more information.

1 Like

Thank you for your thoughts, @MrRusch. I have also tried using a different version of nrjavaserial, substituting it in the /runtime tree, but when I checked in Karaf it was still showing 3.15.0.OH2. I suspect the whole openhab-core needs to be recompiled with the newer version, have you tried that?

There are more issues related to the lockfiles, it seems, and they are known to the openhab-core developers. See this and this and even as far back as here. There is an open request to recompile nrjavaserial 3.20.0 for FreeBSD, see here. Unless you get to it before me, I can have a look next weekend.

I think I will report it as a bug in openhab-core next, as it seems that no one is able to run this on FreeBSD at the moment.

Other than that, all that remains is to run OH 2.5 in bhyve on Openhabian/Debian, with the ZWave stick on a remote Pi with USB over TCP using ser2net. Hopefully the new nrjavaserial would support RFC2217 port.

How I wish the ZWave binding was as easy to connect as RFXCOM, that was a breeze. :slight_smile:

I have not.

I might give this a try if the instructions referenced there are detailed, otherwise I’m not sure I can manage.

EDIT: OK, so this was either not so hard - or way beyond me. :rofl: But I think I managed to build it. Now what hmm…
nrjavaserial-5.0.0.jar.txt (711.8 KB)
32bit: libNRJavaSerial.so.txt (50.9 KB)
64bit: libNRJavaSerial.so.txt (63.6 KB)

Great! Hopefully we’ll get some attention from the pros.

Might as well just run OH on the RPi then no? :laughing:

If you have a Github account, you should fork the repo, do what you did, then create a PR for the built binaries, see this fresh comment.

As I am sure is the case for you, we are both trying to move away from having OH on the Pi. It is a bit slow and I would like it to be snappier in how it replies to events and commands. It is hard to manage: no snapshots. Above all, it is a weak point in what is increasingly an essential piece of home infrastructure. However, having Pi run the easy task of being merely a USB hub over TCP, with a spare one in a cupboard just in case, is more than ok for me—and a necessity, since I cannot get signal for ZWave and RFXCOM from the server enclosure, and so I need the dongles in the attic.

I have reported the issue on Github openhab-core repo.

About this… I don’t think you can simply replace the JAR file. In console, find the 3.15.0.OH2 bundle with “bundle:list” command. Then stop it using its ID, e.g. “bundle:stop ”. Then install the replacement JAR using “bundle:install file://<PATH_TO_JAR>>” and start it with “bundle:start ”.

I just tried this with my newly built JAR, but same error occurs. I think I need to build it from source with the liblockdev library disabled. I remember seeing instructions somewhere.

1 Like

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.

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. :wink:

2 Likes

Good idea. Done.

1 Like

Thanks @wborn for clearing that up!

Looking forward to being able to boot OH on FreeBSD soon :crossed_fingers:

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. :slight_smile: