openHAB serial dependency : how does it work?

[dalgwen (Gwendal Roulleau)]

Hello all,

I made a (newly merged) binding for sending / receiving sms with USB modem, using AT messages protocol.

The binding has a dependency (in feature.xml) toward openhab-transport-serial, and it uses it the openHAB way :

serialPortManager.getIdentifier(“path to serial tty”)

If I understand correctly, this dependency will be installed automatically.
If I understand correctly, there are several provider available for serial connection (rxtx, javacom, and maybe another one)
What I don’t undestand is what provider does it use ?. How does it choose which one to install ?
And depending on the provider, can some of them have more or less luck identifying serial port ?

The bundle is working stable for several users for several month, but one user has an issue with the binding, because the provider doesn’t recognize his usb serial modem as a proper serial port.

His modem and the port associated is working because he can use it with gammu (a software to handle
sms with gsm modem/phone)

Please, does someone have a clue about how to help him ?

[wborn (Wouter Born)]

@dalgwen

Please, does someone have a clue about how to help him ?

Done! Most of the time it’s some kind of permissions issue they run into just like this time.

[wborn (Wouter Born)]

@dalgwen

If I understand correctly, this dependency will be installed automatically.

The Karaf feature dependencies will only be installed for official openHAB add-ons and Marketplace entries using KAR files. Your Marketplace entry is using a JAR file so Karaf will not know what other dependencies to install (similar to copying a JAR file to the /addons dir).

@dalgwen

What I don’t undestand is what provider does it use ?. How does it choose which one to install ?
And depending on the provider, can some of them have more or less luck identifying serial port ?

Unless users customize openHAB, they will all be using the RXTX serial based transport.
It depends on the implementation how to configure and use it and how well it all works.
For instance when using this one, you’ll get some additional port identifiers.

[dalgwen (Gwendal Roulleau)]

Thank you very much for your answers !

Sorry to have you taking time for a permission issue that I should have thought about by myself.

By the way, I am working on a pull request for the serial service to accept/propose the links under /dev/serial/by-id/tty* (some changes in the PortProvider and PortIdentifier of the rxtx and javacomm on the two transport.serial bundles)
This is to avoid the user battling with udev.
If you have some remarks, if you think it’s not a good idea, I’m more than interested in hearing it, before I make the pull request.

[wborn (Wouter Born)]

I think users would be happy to be able to use that as an additional option based on
Can I use “/dev/serial/by-id”?.

You can probably already use them because the RXTX serial transport will add any configured device path to the list of ports in gnu.io.rxtx.SerialPorts .

But I read there is a bug which crashes the JVM which currently prevents using long device names.

See also:

JVM Crash and OH Restart Loop When Connecting to Serial Devices with Long Device Names

First of all thanks for the development of openHAB and the Zigbee binding, it’s a great piece of software I just upgraded to OpenHAB 3.3 running on an Ubuntu 20.04 system (apt installation). My system sometimes changes the assignments of the USB ports to the tty devices, i.e. sometimes the Zigbee stick will be at /dev/ttyUSB0 and sometimes /dev/ttyUSB1. So I changed the device to a symlink that always resolves to the right device: /dev/serial/by-id/usb-Silicon_Labs_BV_2010_10_01382705-if0…

So I think after upgrading nrjavaserial to a version that has the fix the only missing part is adding these identifiers to the discovered port identifier list so they can be more easily configured?

[dalgwen (Gwendal Roulleau)]

Thanks !

So, I made the pull request.
(I choose a way to not have to fix the issue with long device name : I simply resolve the symbolic link, which is to me more error proof than keeping the symlink to low level library)