-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better handling of serial ports with multiple serial implementations #31
Comments
I guess my question would first be - why do you want multiple serial libraries? Now I could offer an answer - and that might be to split out things like USB, and RFC2217 - currently this is embedded in nrjavaserial, and that library seems to have a few problems and (IMHO) it would be better to split them out. If they were split, then this may be required - or you could use the fact that one URI is a |
I believe that RFC2217 is one of reasons why someone could need rxtx + other serial lib. I am aware of ie. ebus binding which requires From implementation perspective I'd say that USB port number is actually a thing which we currently miss! The |
I am not sure if that's an issue, I would rather qualify it as request for clarification or an input towards discussion.
Currently there is no simple way for system to work with multiple serial port libraries. For example if there is a
rxtx
(nrjavaserial) implementation combined with ie.javacomm
then created serial port connection can be handled by any of these libraries. Binding can't really know by which one as first one registered in system wins. This means that if you stop rxtx, restart binding and start rxtx back your other serial port provider will work. However, after restart situation will flip since rxtx usually starts earlier than other extensions.In quite many bindings so far people worked this around by provisioning of their own serial port handling implementations. This is far from perfect, cause an end user experience is quite awful.
I had a look on how serial handling is made and I believe we could utilize a basic strategy which uses URI scheme (it is partially used) and render multiple options. For example
rxtx:/dev/ttyUSB0
andjavacomm:/dev/ttyUSB0
. End user could simply select a specific serial port implementation. The binding developer could assure specific implementation through additional methodSerialPortIdentifier.getProvider
which could return a scheme (ie. rxtx) if a specific port implementation is required.This could open a path towards implementation of a reliable serial port handling (see openhab-core issue 2119). I made an attempt to implement that. It seems to work within junit tests without any udev injections. User could then see a completely different category of port which is not bound to system but a specific USB device (based on idVendor, idProduct).
I described implementation logic is OH forums: https://community.openhab.org/t/co7io-persistent-serial-port-identifier-provider-for-openhab/124223
The text was updated successfully, but these errors were encountered: