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 ?
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).
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.
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.
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)