OH3.X & OH4.X Alternative Java serial provider

By default, the serial connection on the openHAB system is done with nrjavaserial.
Unfortunately there are some issues with this provider, so some (unstable) COM-connections can lock up after a while. See here:

In my case I had big problems with the connection to my smart meter trough an optical probe. As “workaround” I had to restart the whole openHAB instance after some hours. This was very frustrating.
Now there is a “real workaround”, which I found here in the forum more or less by accident.
So I want to share this here. I am very happy with it. On my system it is working since weeks without any issues. It should work with all bindings that need a serial connection.

The way it is done is very simple. See following steps:

  1. Download .jar file:
    OH3.X: org.connectorio.addons.io.transport.serial.purejavacomm-3.0.0-20210705.jar
    OH4.X: org.connectorio.addons.io.transport.serial.purejavacomm-4.0.0-20230928.jar
    See here:
    Z-Wave USB stick not working after OH 3.1 update - #14 by splatch

  2. Put the file into your addons folder. See here:
    Installation of Add-ons | openHAB

  3. Login to openHAB Console. See here:
    The Console | openHAB

  4. Check if the PureJavaComm provicer is active:
    openhab> bundle:list | grep ConnectorIO
    Result should be like this:
    351 x Active x 80 x 3.0.0.202107051005 x ConnectorIO PureJavaComm serial port provider

  5. Reboot your system.

  6. Now you should be able to change the port identifier in the thing configuration:
    purejavacomm uses different port identifiers (ttyUSB0) from rxtx (/dev/ttyUSB0). So in my case the prefix “/dev/” is no more needed in the configuration.
    image

  7. Your serial device should already get online and work like expected.

If you see exceptions in log or it is still unstable just uninstall rxtx bundles (la -l|grep rxtx, then remove bundle without rfc in the name).
bundle:uninstall XXX
Where XXX is the ID of your bundle.
See also here:

So at the end it should look like this.

openhab> la -l|grep rxtx
339 x Installed x  80 x 3.2.0.M3                x mvn:org.openhab.core.bundles/org.openhab.core.io.transport.serial.rxtx.rfc2217/3.2.0.M3

If you use rfc ports at the same time then they will fail without main part of rxtx.

This is it. Any comments on this are very welcome.

Please beware, I am not a Linux or openHAB specialist.
So everything I said before can be wrong. I am just explaining a way how to work with a different serial provider. In my case I am a lot more happier with the alternative.
All thanks and credits to @splatch who developed this. :clap: Thank you very much.

9 Likes

Hi @Tuny,

thank you very much for your workaround. I followed all your steps and it looks like I have ttyUSB0 available in OpenHAB now. However, I still receive the “No provider for port ttyUSB0 found” error. The smartmeter readout in OpenHAB won’t even start anymore, even after a reboot.

I wonder if I screwed up my configuration by following this advice:
https://github.com/openhab/openhab-addons/issues/11489

I stopped the service as it didn’t work but after that I keep getting the “No provider” error all the time. I tried reinstalling the smartmeter binding but no luck yet.
cat /dev/ttyUSB0

cat /dev/ttyUSB0

gives me readings from the optolink.
Any ideas?

EDIT: I followed this advice

Now I get a reading from /dev/ttyUSB0 again. ttyUSB0 still gives me the error message. I wonder how long it will work now until I get the error again. The workaround does not seem to be active. I can see the port ttyUSB0 in the thing configuration but it says “No provider found”.

Please try to restart and also clear the cache

Thank you, @Sascha_ . I cleaned the cache and have the smartmeter on ttyUSB0 online now. Let’s see if the problem has been fixed now.
Thank you all for being such active community members. Happy new year!

1 Like

I had problems with serials too after some time, on github there is a snapshot of nrjavaserial 5.2.1 solves this problem for me:


To update the bundle on the Karaf Console to a snapshot build with the fix (in my fork) use:

bundle:update nrjavaserial https://github.com/wborn/nrjavaserial/releases/download/5.2.1-20220113/nrjavaserial-5.2.1.202201130000.jar

Originally posted by @wborn in Serial ports getting blocked after some re-connecting · Issue #1842 · openhab/openhab-core · GitHub

4 Likes

Hi,

I have tried with the new version, but still have problems with the connection to the smartmeter binding. :frowning:

smartmeter:meter:cac42147b1’ changed from OFFLINE (COMMUNICATION_ERROR): Termination sequence is wrong to ONLINE

and after a while i get the error:

smartmeter:meter:cac42147b1’ changed from ONLINE to OFFLINE (COMMUNICATION_ERROR): Termination sequence is wrong

I just needed a restart after installing snap and works fine. Maybe depends on used stick? Mine is amb8465-M

I did that, unfortunately it did not help

I also tried but did not have success.

When I look at the bundle:list it shows me V5.2.1 of nrjavaserial:
255 x Active x 80 x 5.2.1 x nrjavaserial

Is this correct? Or has the Version look like this “5.2.1-20220113”?

After installation
Xxx│ Active │ 80 │ 5.2.1.202201130000 │ nrjavaserial

Try update <bundle-id> file:<file location>. Updated bundle should be retained across restarts unless you do clean of data dirs.

A nrjavaserial 5.2.1.OH1 release with a fix for this annoying issue is now integrated in 3.3.0-SNAPSHOT build #2849 or newer.

3 Likes

Quick question on this: If I’m on a plain 3.3.0 Release Build, still experiencing this problem just yesterday after reboot, being able to fix it with this workaround, does it mean my installation misses something? Doesn’t your comment above mean that the nrjavaserial-bug should be gone in OH 3.3.0 Release Build? Or am I misunderstanding something?

I would say there is nothing missing.
You have to install a milestone release of 3.3 or go directly to 3.4.

You can check your nrjavaserial version when you check your bundles in the console:

 bundle:list | grep nrjavaserial

This one contains the fix:

5.2.1.OH1 nrjavaserial

Hmm, very odd: I just had one manifestation of the problem yesterday (Z-Wave stick not getting online after reboot), even though I have the version of nrjavaserial installed (as part of my 3.3.0 release build), which you state should already contain the fix (254 │ Active │ 80 │ 5.2.1.OH1 │ nrjavaserial)

I think I’ll then wait for 3.4, since I fear a bit installing “something manually” which cause problems later on in the process with the automatic update to 3.4.

Of course, I was wrong.
Snapshots are before the main release.
So the fix is in 3.3.0… also the update to 3.4. might not change anything then. :neutral_face:

Hmm. Anything an average user can do to incentivize a fix? Contribute to a bounty? Though I got the impression that this is a rather large bug, affecting not only openHAB users?

Yes, question your hardware setup. You might have reached the limits of your raspberry. I think the power consumption of your USB devices is high? Do you know how much they need?
When booting, your load on the raspberry is also very high…

What power supply are you using? I like the raspberry, but I think for your needs and for “production” use you need to invest a little more in your hardware.
I personally like the odroid C4 this has a 12V power supply. Bit i am also very careful when adding external devices.
The best think might be a thin PC…

When did your issue start?
Did you also try the alternative provider described in this topic?
BR

this issue is much larger then openHAB and has been on going for some time.

I remember @splatch created an alternative serial provider… see here

I’m a bit reluctant, because I fear this will impact potential future upgrades. If this is not the case (does anyone know for sure?) I might give it a try.

Though, just wondering, why not putting the alternative java into e.g. OH 3.4? Won’t this solve the problem root-cause based?

I haven’t measured the power consumption, but the Amber Wireless AMB8465 and the Aeotec Z-Wave Gen5+ don’t even get warm, so they can’t draw that much power. I mean, I can’t rule it out, but (even though I’m not a pro) I believe we’re looking at the nrjavaserial bug described above, don’t you think? The description fits 100%.

The original Raspberry 2,4 A power supply, so that looks ok to me.

It existed from day 1 onwards when I got the Aeotec Z-Wave Gen5+.