The port is OK and functions when it works. Restarting my he ZigBee bindings breaks OH access to the port even though it is a selectable option in HABmin.
Sorry to ask again, but are the ports defined on the OH command line options?
Otherwise I don’t know why this would happen. It should not be anything to do with the ZWave binding at least as that only opens its own port.
Sorry, I am not familiar with doing that so it must be whatever is default. Where would I check or define this? I did not see anything in /etc/default/openhab2.
If I remember correctly it’s in the main openHAB installation docs.
I also found it described here-:
I’m not sure if it will help, but the driver uses this to work out what ports are available. I think without this it might do some sort of scan, which might cause problems. Otherwise, I’m not really sure what else to look at.
Thanks Chris.
Something there might be worth a try. I will need to look later today.
EDIT: I tried quickly and have some success. Here is what I added to EXTRA_JAVA_OPTS in /etc/default/openhab2.
-Dgnu.io.rxtx.SerialPorts=/dev/ttyUSB0:/dev/ttyUSB1
@brianlay would need to add their Z-Wave serial port too. It should be tested with vanilla Milestone 4. That is the next step.
to make both my zwave and zigbee stick work I had to actually create symlinks for both of them as described in the link that @chris posted because just adding the ports to the extra java opts was not sufficient. This is what worked for me: Raspberry Pi - Make serial USB ports persistent via symlinks
but the whole thread is actually worth reading. Dont know if it will work that way with your stick as its two in one and I had two separate sticks but my problem was very similar otherwise.
Johannes
Adding the options seems like a workaround to me. Is your server a Pi?
Yes it’s a 3b+. Using symlinks is actually generally recommended in Linux when working with multiple USB devices I think as the operating system assigns port numbers in a different order on reboot or even when unplugging and replugging a device. I think this could be a culprit of a lot of problems people have when using multiple sticks on their pis. With symlinks you just make sure the software actually always finds the right device of multiple plugged ins. At least that’s my understanding.
Johannes
My ports have stayed in the same order.
It’s in order of connection. So you can be lucky. But there is nothing wrong with the stability and predictability Symlinks provide. And it’s only two lines in two files 
that way I am for example able to have three sticks on my pi without ever worrying. Enocean, Zigbee and Zwave.
Johannes
In our particular cases, both interfaces are in the same device so it may control order of association.
Do you see one or two devices for the stick when you do lsusb in the commandline?
Three?
For standard USB devices on a Pi, there ideally should be no configuration file edit needed, IMO
root@raspberrypi:~# dmesg | grep tty
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 bcm2708_fb.fbwidth=640 bcm2708_fb.fbheight=480 bcm2708_fb.fbswap=1 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 root=/dev/mmcblk0p7 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait
[ 0.000902] console [tty1] enabled
[ 0.934372] 3f201000.serial: ttyAMA0 at MMIO 0x3f201000 (irq = 81, base_baud = 0) is a PL011 rev2
[ 2.866071] systemd[1]: Created slice system-getty.slice.
[ 5.148772] usb 1-1.1.3: cp210x converter now attached to ttyUSB0
[ 5.160085] usb 1-1.1.3: cp210x converter now attached to ttyUSB1
root@raspberrypi:~# lsusb
Bus 001 Device 004: ID 10c4:8a2a Cygnal Integrated Products, Inc.
Bus 001 Device 005: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I will now set up 2.4 and try to determine at which Milestone things broke since I can seem to re-create the issue on demand…
sorry, can or cannot reproduce?
I can reproduce with Milestone 4 & later. I just tested and I cannot reproduce on 2.4 I am trying to narrow down where the problem occurred. I guess I need to figure our how to upgrade to Milestone 1.
For now, the workaround appears to be to define the serial ports in the OH configuration…
Defining the aerial ports is not really a workaround - this is recommended and sometimes required to make the serial driver work. It’s possible there is a new version of the drivers that works differently - I’m not sure, but if that fixes the problem you are having them this sounds like the fix.
Serial ports in java are not the best supported, and OpenHAB complicates things further by adding additional levels of abstraction.
It works OK in 2.4 and the behavior changed sometime later. I thought if I could narrow down when the behavior changed it might help getting it changed back to things are automatically detected fully. Now the port appears fir selection but does not always work without manual configuration.
This was working in June without using EXTRA_JAVA_OPTS. I haven’t noticed an issue recently, since I have my ports defined in EXTRA_JAVA_OPTS.
In addition, you will always need to use EXTRA_JAVA_OPTS if you’re not using standard Linux port names in your symlinks. Meaning, /dev/zwave and /dev/zigbee will require EXTRA_JAVA_OPTS. However, /dev/ttyUSB-5 and /dev/ttyUSB-55 do not. See the last note in this old wiki article. I looked, but I do not see anything like this communicated in the current docs.
I am / we are using the standard port names. Perhaps I need to verify that this is mentioned in the binding documentation it should also then be mentioned on the pages in the PaoerUI and HABmin where the port is specified.
EDIT: I see that change was 5 months ago which was after 2.4. Perhaps we are seeing some unintended side effect of that change. The port appears in the drop down but is not always usable.