[nrjavaserial] Multiple versions

[5iver]

This is more of a question than an issue (maybe). Could someone please explain why there are multiple versions in use? It looks like there are at least two...

openhab> list -s |grep serial
233 │ Active │  80 │ 3.14.0                │ com.neuronrobotics.nrjavaserial
234 │ Active │  80 │ 3.15.0.OH2            │ com.neuronrobotics.nrjavaserial

https://github.com/openhab/openhab-core/search?q=nrjavaserial

[maggu2810]

You are right, there is a "bug".

• openhab-core/features/karaf/openhab-core/src/main/feature/feature.xml

  Line 612 in 2c7ca34

  <bundle>mvn:org.openhab/nrjavaserial/${nrjavaserial.version}</bundle>

• openhab-core/features/karaf/openhab-tp/src/main/feature/feature.xml

  Line 157 in 2c7ca34

  <bundle>mvn:com.neuronrobotics/nrjavaserial/3.14.0</bundle>

The feature "openhab-transport-serial" of the "openhab-core" feature repo should not depend on nrjavaserial directly but use the feature "openhab.tp-serial-rxtx" of the "openhab-tp" feature repo.

There should be a hard requirement for "openhab.tp;feature=serial" and an optional dependency for the "rxtx" one if no other one is already provided.

[maggu2810]

Why is there "openhab-core-io-transport-serial" and "openhab-transport-serial"?
If this second feature is necessary at all, I assume "openhab-transport-serial" depend on "openhab-core-io-transport-serial" as this one provides already the option to choose between different implementations.

[maggu2810]

  <feature name="openhab-core-io-transport-coap" version="${project.version}">
  <feature name="openhab-core-io-transport-dbus" version="${project.version}">
  <feature name="openhab-core-io-transport-http" version="${project.version}">
  <feature name="openhab-core-io-transport-mdns" version="${project.version}">
  <feature name="openhab-core-io-transport-mqtt" version="${project.version}">
  <feature name="openhab-core-io-transport-serial" version="${project.version}">
  <feature name="openhab-core-io-transport-serial-javacomm" version="${project.version}">
  <feature name="openhab-core-io-transport-serial-rxtx" version="${project.version}">
  <feature name="openhab-core-io-transport-serial-rfc2217" version="${project.version}">
  <feature name="openhab-core-io-transport-upnp" version="${project.version}">

vs.

  <feature name="openhab-transport-coap" description="CoAP Transport" version="${project.version}">
  <feature name="openhab-transport-http" description="HTTP Transport" version="${project.version}">
  <feature name="openhab-transport-mdns" description="mDNS Transport" version="${project.version}">
  <feature name="openhab-transport-mqtt" description="MQTT Transport" version="${project.version}">
  <feature name="openhab-transport-serial" description="Serial Transport" version="${project.version}">
  <feature name="openhab-transport-upnp" description="UPnP Transport" version="${project.version}">

[5iver]

Why is there "openhab-core-io-transport-serial" and "openhab-transport-serial"?

I was actually wiating for a response to ask the same question! I missed the conversations about what to do with serial when ESH was reintegrated. There is some discussion in the forum about a serial issue with the zwave binding, after this move, where the serial is not starting with OH but starts after the binding is restarted.

[maggu2810]

IMHO:

The openhab-core-io-transport features provide the specific bundle itself and that dependencies.
The openhab-transport features provide the specific transport bundle (using the correspondent openhab-core-io-transport feature) and optional some other stuff that is mostly used for that transport (see e.g. the config part for serial etc.).

The "old" openHAB feature do not following the split between targetplatform and openHAB part as done before and in the migrated ones.
Features in the openHAB Core repo should not contain a hard dependency to a non-openHAB bundle.
They depend on a openHAB targetplatform feature.

• openhab-transport-serial should not depend on nrjavaserial but on a targetplatform feature
• in the specific transport case it should not reuse what already exist and should not depend on the targetplatform feature but on the correspondent openhab-core-io-transport feature
• ...

[cweitkamp]

Seem to happen for other dependencies too:

openhab> bundle:list | grep -i guava
 22 │ Active │  80 │ 18.0.0                │ Guava: Google Core Libraries for Java
 23 │ Active │  80 │ 21.0.0                │ Guava: Google Core Libraries for Java
265 │ Active │  80 │ 20.0.0                │ Guava: Google Core Libraries for Java

• openhab-core/features/karaf/openhab-core/src/main/feature/feature.xml

  Line 520 in 2c7ca34

  <bundle>mvn:com.google.guava/guava/18.0</bundle>

• openhab-core/features/karaf/openhab-tp/src/main/feature/feature.xml

  Line 180 in 2c7ca34

  <bundle dependency="true">mvn:com.google.guava/guava/21.0</bundle>

• Version 20.0.0 results from Google TTS add-on (see https://github.com/openhab/openhab2-addons/blob/master/features/karaf/openhab-addons/src/main/feature/feature.xml#L1199).

[mvalla]

Hallo, I have found that if nrjavaserial 3.14.0 is present and selected, finding USB serial ports on Windows10 does not work, see: #370.
So when solving this multiple versions issue, make sure that 3.15.0 is selected (a workaround for nrjavaserial has been put in place in 3.15.0 see NeuronRobotics/nrjavaserial#121)

[maggu2810]

@kaikreuzer What's the difference between the openHAB nrjavaserial release and the upstream one?

[kaikreuzer]

@maggu2810 This was built by @wborn, for details see https://github.com/wborn/nrjavaserial-builder/releases/tag/3.15.0.OH2.

[maggu2810]

So, it seems the difference is the usage of "liblockdev".

# Disable using lock files
sed -i 's#-DLIBLOCKDEV#-DDISABLE_LOCKFILES#g' "$GIT_REPO_DIR/src/main/c/Makefile.ubuntu64"
sed -i 's# -llockdev##g' "$GIT_REPO_DIR/src/main/c/Makefile.ubuntu64"

@wborn Can you give me some insides?
Why should liblockdev not being used?
Is there something wrong with that library?

[wborn]

The liblockdev library doesn't work properly with newer Linux distributions. As a result it doesn't properly unlock serial ports so openHAB can no longer use them. You'll run into it whenever you restart openHAB in the Docker container (Debian 9). IIRC liblockdev has also been removed from the current Debian based distros.

See:

• Use proper lock directory (NeuronRobotics/nrjavaserial#60)
• RXTX fhs_lock() Error: opening lock file: /var/lock/LCK..ttyUSB0: File exists. It is mine

The release we use also adds arm64 support which isn't available in any official nrjavaserial release. Using openHAB with a 64-bit JVM is sometimes the only option (e.g. on arm64 based Synology NAS-es, see community).

[maggu2810]

No change to get it upstream (arm64 support and the liblockdev removal)?

[wborn]

The PR for adding arm64 support was merged upstream (NeuronRobotics/nrjavaserial#134) but there hasn't been an official release since it was merged. I didn't have time for looking into a structural solution for the liblockdev issue yet.