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.
Since I believe tis to be related to the PR referenced, I have added to the comments there. I suspect the issue developed between 2.5M1 and 2.5M2.
It’s mentioned in the installation instructions because this is a Linux specific issue.
What I don’t know is whether openHABian adds these automatically or not.
- ZigBee is not mentioned
- Perhaps precautionary warnings for Linux users in the binding port configuration would be appropriate.
- My understanding of the PR mentioned above was to elimimate for need for the configurstion but it appears to only work as expected sometimes. I commented in the PR about this.
- Not in the openHABian instructions
It does not.
Nor is zwave, KNX, RF443, MySensors, BlueTooth, or any of the many and growing list of bindings that require a serial device. And that doesn’t belong there.
You could go and do the research to find all the bindings amount the 320 or so currently approved that use serial devices and file an issue to have them update their README to mention this. But this is really a side effect of the fact that we have made a conscious decision to not repeat information in the docs. We don’t have the man power to keep everything in sync if the same thing is documented in more than one location.
Is “Recommended Additional Steps” not enough? It’s right there in the docs. “Please do this other stuff too.”
This might warrant an issue on openHABian then.
Looks like it is to me.
An openHAB setup will often rely on hardware like a modem, transceiver or adapter to interface with home automation hardware. Examples are a Bluetooth, Z-Wave, Enocean or RXFcom USB Stick or a Raspberry Pi add-on board connected to the serial port on its GPIOs.
Where is it in the openHABian docs I use?
I may do that depending on the response to my PR comments.
At the end of the day, it relates to anything using serial ports. I don’t think that general documentation should try to reference bindings like this as there will always be comments like yours where it doesn’t reference some specific binding. As rich implies, it can’t reference them all - there are a lot, and trying to keep this up to date with every binding that makes use of serial ports would be a never ending circle of updates…