Replace gnu.io dependency of add-ons with serial transport

[wborn]

There are still add-ons which depend on gnu.io for their serial communications. By using the serial transport we can switch between serial implementations (rxtx, javacomm) without having to change any add-on code. It also allows for using RFC2217 ports.

These bundles still depend on gnu.io:

• [x] org.openhab.binding.digiplex (#7617)
• [x] org.openhab.binding.dscalarm (#7618)
• [x] org.openhab.binding.elerotransmitterstick (#7619)
• [x] org.openhab.binding.jeelink (#7620)
• [x] org.openhab.binding.knx (gnu.io is a transitive dependency of calimero-rxtx) (#14051)
• [x] org.openhab.binding.lgtvserial (#7631)
• [x] org.openhab.binding.lutron (#7609)
• [x] org.openhab.binding.meteostick (#7632)
• [x] org.openhab.binding.nibeheatpump (#7633)
• [x] org.openhab.binding.oceanic (#15044)
• [x] org.openhab.binding.openwebnet (gnu.io is a transitive dependency of openwebnet4j, https://github.com/mvalla/openwebnet4j/issues/34, https://github.com/openhab/openhab-addons/pull/16376)
• [x] org.openhab.binding.phc (#6447)
• [x] org.openhab.binding.pioneeravr (#7588)
• [x] org.openhab.binding.regoheatpump (#7636)
• [x] org.openhab.binding.rme (#7638)
• [x] org.openhab.binding.rotelra1x (will be removed in OH3 #7577, replaced by https://github.com/openhab/openhab-addons/pull/5805)
• [x] org.openhab.binding.urtsi (#7640)
• [x] org.openhab.binding.velbus (#7641)
• [ ] org.openhab.binding.cm11a (uses notifyOnRingIndicator, currently unsupported by transport)
• [ ] org.openhab.binding.pentair (uses disableReceiveFraming/disableReceiveThreshold, currently unsupported by transport) (#13485)
• [ ] org.openhab.binding.proteusecometer (uses jSerialComm because messages got corrupt when using the serial transport see #11333)
• [ ] org.openhab.io.transport.modbus (gnu.io is a transitive dependency of net.wimpi:jamod which is an OH fork, https://github.com/openhab/jamod/issues/19)

[lolodomo]

The rotelra1x binding is supposed to be removed in OH 3.0 as it was replaced by the rotel binding. We kept it in 2.5 to let the time to users to move to the new binding.

[wborn]

Great! I've updated the list so we won't spend any time on migrating that one. :+1:

[gnlpfjh]

With #6447 phc binding uses serial transport.

[wborn]

Very nice! I even see you updated the POM for the import that was added in https://github.com/openhab/openhab-addons/pull/7589. :+1:

[mvalla]

What is to be done in case of a transitive dependency from a library that uses nrjavaserial (like in the case of KNX) ?

[bodiroga]

This should be pinned again, I think that @jsjames has unpinned it unintentionally :wink:

[wborn]

Yes all 3 issues were unpinned by @jsjames. :neutral_face:

[wborn]

What is to be done in case of a transitive dependency from a library that uses nrjavaserial (like in the case of KNX) ?

It depends on the library implementation. In case of KNX it might be possible to remove the calimero-rxtx dependency and instead reimplement RxtxAdapter by using the serial transport instead.

If it's named tuwien.auto.calimero.serial.RxtxAdapter it will be used instead by the LibraryAdapter, see

• L87-L90
• L144-L148

[holgerfriedrich]

@wborn I could need some advice on how to proceed with KNX binding (Calimero library). We could easily remove the calimero-rxtx library, but the would also remove the KNX over serial interfacte feature. So this is not an option. Rewriting the RxtxAdapter class as suggested could be an option, but we would need to do it in the context ""tuwien.auto.calimero.serial", as a class lookup is hard coded in the calimero-core library as follows: src/tuwien/auto/calimero/serial/LibraryAdapter.java: final Class<?> c = Class.forName("tuwien.auto.calimero.serial.RxtxAdapter"); Not sure if this is a good idea (technically). Reusing the source code for RxtxAdapter might be a problem as well, as we might run into issues with incompatible licenses (Calimero is GPL2 with classpath exception, openHab EPL2).

[kaikreuzer]

@wborn Do you have any good idea wrt @holgerfriedrich's question on how to best proceed for KNX?

[holgerfriedrich]

@kaikreuzer Calimero 2.5.1 release branch has just been created a few hours ago; the code for serial port has changed..... let's see....

[wborn]

Yes it looks like you can now create your own SerialCom implementation and use that instead of the calimero-rxtx dependency. It will create/use a SerialCom instance based on the class name in META-INF/services/tuwien.auto.calimero.serial.spi.SerialCom, see: https://github.com/calimero-project/calimero-rxtx/commit/1e74d815b05ef1a14268095df2b512e760305d09

[lsiepel]

Work for the Pentair binding is on the way as @jsjames filed a PR for it: https://github.com/openhab/openhab-addons/pull/13485

[holgerfriedrich]

@wborn I created our own SerialCom implementation. In principle this seems to work, but there is a problem once the framework reloads the KNX plugin. ServiceLoader does not find the implementation anymore (or I have not yet found a way to properly push it), so I need to restart openHAB to properly reload. If you have any suggestion, please comment in #14051.

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/usb-port-conflict-zigbee2mqtt-and-modbus/143448/8

[mvalla]

For [openwebnet] just sbmitted a new PR that makes the binding independent from gnu.io. See #16376.