OH 3.3 restarts using USB-Serial (Smartmeter and ebus)

Have done a upgrade from OH 3.2 to OH 3.3 on my Raspberry.
It restarts nearly all 15 minutes. Found out, that this is only if Smartmeter (openhab-binding-smartmeter) and/or ebus (openhab-binding-ebus) binding is active.

Common here: both have a connection to external devices via USB-Serial adapter.
Maybe I have to change a little bit for using USB-serial, but don’t found a hint.
There are no messages in the log which showing an issue in this direction.

I am a little bit active in the community of eBus-Binding (https://community.openhab.org/t/ebus-binding-3-x/) - but seems the developer is not active since a half year…

Could someone have an idea?

Tap the logs, if you have a constant behavior it should leave some traces. It is unlikely that these bindings alone cause whole system to fail.

Hi @splatch there is really no info in the log when it crashes. Have set the log from info over debug to trace - even the same.
Thanks goodness the Developer of ebus is online. Have upload there a whole log after booting. He created a change, now it crashes not automatically after the boot, but when I access the configuration menu via UI (Settings → items → bridge). My hope is, that another one has equal issues and found a solution. Or if the developer could fix it, that other user can participate…

In the mean time it is clear, why no log-entries are done in openhab-logs. java crashes.
But still not clear, how can it fixed. In openhab3.2 all was running, only the update was done to openhab3.3 via openhabian-config.
Now somewhat is going wrong if an access to (usb)serial is activ. can be seen in daemon.log
If someone have an idea - you are welcome!

Example from daemon.log:
Jul 3 19:58:02 openHABianPi karaf[6044]: #
Jul 3 19:58:02 openHABianPi karaf[6044]: # A fatal error has been detected by the Java Runtime Environment:
Jul 3 19:58:02 openHABianPi karaf[6044]: #
Jul 3 19:58:02 openHABianPi karaf[6044]: # SIGILL (0x4) at pc=0xaa407e80, pid=6044, tid=8297
Jul 3 19:58:02 openHABianPi karaf[6044]: #
Jul 3 19:58:02 openHABianPi karaf[6044]: # JRE version: OpenJDK Runtime Environment Zulu11.56+19-CA (11.0.15+10) (build 11.0.15+10-LTS)
Jul 3 19:58:02 openHABianPi karaf[6044]: # Java VM: OpenJDK Client VM Zulu11.56+19-CA (11.0.15+10-LTS, mixed mode, serial gc, linux-arm)
Jul 3 19:58:02 openHABianPi karaf[6044]: # Problematic frame:
Jul 3 19:58:02 openHABianPi karaf[6044]: # C [libNRJavaSerialv8_HF.so+0x2e80]
Jul 3 19:58:02 openHABianPi karaf[6044]: #
Jul 3 19:58:02 openHABianPi karaf[6044]: # No core dump will be written. Core dumps have been disabled. To enable core dumping, try “ulimit -c unlimited” before starting Java again
Jul 3 19:58:02 openHABianPi karaf[6044]: #
Jul 3 19:58:02 openHABianPi karaf[6044]: # An error report file with more information is saved as:
Jul 3 19:58:02 openHABianPi karaf[6044]: # /var/lib/openhab/hs_err_pid6044.log
Jul 3 19:58:02 openHABianPi karaf[6044]: [thread 8328 also had an error]
Jul 3 19:58:03 openHABianPi karaf[6044]: #
Jul 3 19:58:03 openHABianPi karaf[6044]: # If you would like to submit a bug report, please visit:
Jul 3 19:58:03 openHABianPi karaf[6044]: # Customer Support for Platform Core & Platform Prime | Azul
Jul 3 19:58:03 openHABianPi karaf[6044]: # The crash happened outside the Java Virtual Machine in native code.
Jul 3 19:58:03 openHABianPi karaf[6044]: # See problematic frame for where to report the bug.
Jul 3 19:58:03 openHABianPi karaf[6044]: #
Jul 3 19:58:04 openHABianPi systemd[1]: openhab.service: Main process exited, code=killed, status=6/ABRT
Jul 3 19:58:04 openHABianPi systemd[1]: openhab.service: Failed with result ‘signal’.
Jul 3 19:58:04 openHABianPi systemd[1]: openhab.service: Consumed 18min 30.073s CPU time.
Jul 3 19:58:09 openHABianPi systemd[1]: openhab.service: Scheduled restart job, restart counter is at 5.
Jul 3 19:58:09 openHABianPi systemd[1]: Stopped openHAB - empowering the smart home.
Jul 3 19:58:09 openHABianPi systemd[1]: openhab.service: Consumed 18min 30.073s CPU time.
Jul 3 19:58:09 openHABianPi systemd[1]: Started openHAB - empowering the smart home.

What is in
/var/lib/openhab/hs_err_pid6044.log ?

Oh, there are infos in. Here there are:
hs_err_pid6044.log (107.0 KB)

In the other thread I read that you did several steps to migrate from an older OH version as well as from an older OS version to OH3 on a more recent OS.
I don’t know if that will help but as the lib is stored in the tmp location did you also try to clean/clear the cache ?

Little bit more investigation… seems to be an issue of nrjavaserial-5.2.1.jar.
See also ARMv5 crashes the JVM · Issue #224 · NeuronRobotics/nrjavaserial · GitHub

For my raspberry it should be used the lib libNRJavaSerialv8.so, not libNRJavaSerialv8_HF.so.
tried to change by copy the ‘right’ file to the place, where openhab store it:
/var/lib/openhab/tmp/libNRJavaSerialv8_HF_openhab_0/libNRJavaSerialv8_HF.so
But in the first step, openhab did overwrite it. Next step giving openhab no access rights to file and directory: It creates a new directory and uses it (/var/lib/openhab/tmp/libNRJavaSerialv8_HF_openhab_1)

Have someone the idea how I could do a change, that openhab is use the other (hopefully right) file ?

Did you try the workaround ( place the “right” file somewhere and add the path to runtime environment in e.g. EXTRA_JAVA_OPTS ) that is mentioned in the link that you posted ?

Yes - I am still testing. Up to now: All variants ending with _HF are crashing. Still testing them without those extension - until now the tested not crashing, but no working USB-Serial transport. But I will give the final result later on…

I Think I can give a next statement.
The jar-file nrjavaserial-5.2.1.jar is containing those native files for linux/ARM_32 which I have tried:
libNRJavaSerialv6_HF.so
libNRJavaSerialv7_HF.so
libNRJavaSerialv8_HF.so
libNRJavaSerialv5.so
libNRJavaSerialv6.so
libNRJavaSerialv7.so
libNRJavaSerialv8.so

With all _HF files the system is crashing if an app try to access.
By all files without the _HF system is not crashing - but both applications (Smartmeter and eBUS Binding) are not able to access. Giving the result "“Unable to connect to serial port /dev/ttyUSB0”
Those for both, eBUS Binding try to access to USB0 for eBUS-Adapter, meter binding to USB1 for meter-provider.

eBUS Binding has the possibility to choose for serial access between nrjavaserial and jserialcomm. Without the restart the app is working by using jserialcomm.
smartmeter do not have this option and is not working.

As a result my understanding: Still not working, but without the restarts as last eBUS Binding can by used via jserialcomm.

Your crashing JVM issue very much looks like nrjavaserial#108.

Looks like you are using one of the less commonly used/older Raspberry Pi models so that might explain why many other Raspberry Pi users don’t run into this:

/proc/cpuinfo:
processor	: 0
model name	: ARMv6-compatible processor rev 7 (v6l)
BogoMIPS	: 697.95
Features	: half thumb fastmult vfp edsp java tls 
CPU implementer	: 0x41
CPU architecture: 7
CPU variant	: 0x0
CPU part	: 0xb76
CPU revision	: 7

Hardware	: BCM2835
Revision	: 0010
Serial		: 00000000fef6d62b
Model		: Raspberry Pi Model B Plus Rev 1.2

Normally nrjavaserial iterates over all available libraries and expects the JVM to throw a UnsatisfiedLinkError if a library does not work and continue with another.

It might be an issue specific to the Zulu JVM, so it may be worth a try to switch to the Debian default OpenJDK as JVM. See also: openhabian#182.

Hi @wborn
Thanks for info. That makes sense - that not so much other user of an raspi have this issue. Maybe its time to get a newer one. Have it around 4 years already…

openJDK makes also no different. Currently I am using:
openjdk 17.0.3 2022-04-19
OpenJDK Runtime Environment (build 17.0.3+7-Raspbian-1deb11u1rpt1)
OpenJDK Client VM (build 17.0.3+7-Raspbian-1deb11u1rpt1, mixed mode, emulated-client)

Here the info of my raspi:

cat  /proc/cpuinfo
processor       : 0
model name      : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2835
Revision        : 0010
Serial          : 00000000fef6d62b
Model           : Raspberry Pi Model B Plus Rev 1.2

Maybe as workaround for other users…
Since I am a little bit more familiar with it I found out that with apt an old txtxSerial driver can be installed, which will be ignored by openhab (name: librxtx-java ). Its a quite old one, from 2018 and will stored as file usr/lib/jni/librxtxSerial-2.2pre1.so
Have copied it to /home/openhabian/librxtx/librxtxSerial.so
If I give this in java acces eg as replacement of original file java:
/usr/lib/jvm/java-17-openjdk-armhf/bin/java -DlibNRJavaSerial.userlib=/home/openhabian/librxtx/librxtxSerial.so $*

Than smartmeter is working fine. eBUS-Binding is not working with this, but can run via jSerialComm.

So I can wait a little bit to set up another system for openhab with a newer raspberry…

Many thanks for the comments, it helps me to find the issue - and the workaround.

1 Like

If the issues started due to a newer nrjavaserial version, you can also downgrade it to an older version as long as it is in the range [3.12, 6) :slight_smile:

Hi @wborn
Thanks. I tried version 5.1.1 without success. For me I can live with the situation as workaround and will upgrade the system to raspi pi4 with 4GB RAM. Order is already placed.
Hope there is not also such old equipment :wink:

1 Like

There is alternative serial provider: OH3.X Alternative Java serial provider which does not have a native part.

1 Like

Hi @splatch thanks for the tip. The old rxtx-driver seems not to be stabile (after some hours no data from serial any more). And nrJavaSerial do not run on my system - even not the older versions (as least not wit eBUS-Binding).

So I tried it. It is working, for smartmeter very good. On eBUS-Bindings there are errors by transmitting.
Maybe difference is - smartmeter do only read the coming data. eBUS-Binding is also transmitting. And on the serial interface is a lot of traffic.
Think the Alternative Java serial is a very good choice to use a serial interface with less traffic.

Next week I will get a rapberry pi 4 with 4GB. Hope there will all running without workarounds…

Its interesting what you say on traffic volume. I actually might try to see how this serial provider goes with ebus.

I am not a specialist for the eBUS
What I see is, if I activate the Alternative Java serial I get lots of messages like

2022-07-06 21:28:25.314 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0xAA is not equal to send byte 0xED! Stop send attempt ...

2022-07-06 21:28:25.975 [WARN ] [dev.ebus.core.EBusLowLevelController] - Received byte 0xAA is not equal to send byte 0xED! Stop send attempt 

When I change the eBUS-Binding configuration to use jserialcomm those kind of messages are only coming sporadic

What I now is, that it is not allowed to send on the eBUS if already another device is sending. The eBUS-Adapter is reading in time of sending. If the data are other it stops sending.
Those are the meaning of this error messages.