I am having one issue with a USB device, where sometimes it is registered at /dev/ttyUSB0 and sometimes it is at /dev/ttyUSB1, where can I find information to set a custom udev rules to make sure that this device always starts as USB0, for example.
Thank you
Hi Juan, there are some udev examples here: https://github.com/tmigone/balena-udev-examples. There is this forum thread about renaming a network interface using udev, but the principle is the same. Let us know if that helps, and feel free to post your findings here so others can benefit as well.
thanks @sradevski, for what I am looking here, both usb0 and usb1 comes from the same FTDI chip.
root@5517bbd:/dev# udevadm info /dev/ttyUSB0
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
L: 0
S: serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
S: serial/by-id/usb-FTDI_Dual_RS232-HS-if00-port0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB0/tty/ttyUSB0
E: DEVNAME=/dev/ttyUSB0
E: MAJOR=188
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=11501625
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_ID=0403
E: ID_MODEL=Dual_RS232-HS
E: ID_MODEL_ENC=Dual\x20RS232-HS
E: ID_MODEL_ID=6010
E: ID_REVISION=0700
E: ID_SERIAL=FTDI_Dual_RS232-HS
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=ftdi_sio
E: ID_PATH=platform-3f980000.usb-usb-0:1.3:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_3_1_0
E: ID_MM_CANDIDATE=1
E: DEVLINKS=/dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0 /dev/serial/by-id/usb-FTDI_Dual_RS232-HS-if00-port0
E: TAGS=:systemd:
root@5517bbd:/dev# udevadm info /dev/ttyUSB1
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1/ttyUSB1/tty/ttyUSB1
N: ttyUSB1
L: 0
S: serial/by-id/usb-FTDI_Dual_RS232-HS-if01-port0
S: serial/by-path/platform-3f980000.usb-usb-0:1.3:1.1-port0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.1/ttyUSB1/tty/ttyUSB1
E: DEVNAME=/dev/ttyUSB1
E: MAJOR=188
E: MINOR=1
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=11503610
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_ID=0403
E: ID_MODEL=Dual_RS232-HS
E: ID_MODEL_ENC=Dual\x20RS232-HS
E: ID_MODEL_ID=6010
E: ID_REVISION=0700
E: ID_SERIAL=FTDI_Dual_RS232-HS
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=01
E: ID_USB_DRIVER=ftdi_sio
E: ID_PATH=platform-3f980000.usb-usb-0:1.3:1.1
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_3_1_1
E: ID_MM_CANDIDATE=1
E: DEVLINKS=/dev/serial/by-id/usb-FTDI_Dual_RS232-HS-if01-port0 /dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.1-port0
E: TAGS=:systemd:
So the udev rules should be something like:
"os":{ "udevRules": { "10" : "ACTION==\"add\", SUBSYSTEM==\"tty\", ENV{MAJOR}==\"0188\", ENV{MINOR}==\"0\", NAME=\"USB0\"" } }, ?
Thanks
Do you have connected multiple of these ftdi chips? If you would have something already connected that gets assigned the ttyUSB0 devname then if you next connect your usb serial adapter it will naturally be assigned ttyUSB1.
So please share more about your usecase
So right now there is only one things connected to the ftdi chip.
But one thing that I noticed, sometimes if I turn the usb device (it’s a modbusrtu device) and then I turn on the raspberry pi, it assigns the ttyUSB1 to it. Which then I would have to change in the code to connect to.
Can you share the dmesg from your rpi when you ttySUB1 gets assigned please?
Unable to test due to not having the hardware on hand, but something like this maybe?
SUBSYSTEM=="tty", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6010", ENV{ID_SERIAL}=="FTDI_Dual_RS232-HS", ENV{ID_USB_INTERFACE_NUM}=="00", SYMLINK+="serial/ttyUSB_port0"
SUBSYSTEM=="tty", ENV{ID_VENDOR_ID}=="0403", ENV{ID_MODEL_ID}=="6010", ENV{ID_SERIAL}=="FTDI_Dual_RS232-HS", ENV{ID_USB_INTERFACE_NUM}=="01", SYMLINK+="serial/ttyUSB_port1"
Source: https://gist.github.com/laanwj/fb8774b5ca9cd1517df2cd09f0fd0b61
I will give it a try, thank you very much!
No dice.
What’s the best way to know which usb is being configured, or how would you advice to proceed with the investigation to fix this?
Thank you
Also I see that sometimes the GSM Modem is being connected to USB0, what if I force the GSM to be on USB1 instead?
Hi, if you can share the link to your device and enable support access, we can have a look and test a few things on your device. We’d also need permission to reboot the machine possibly
Hi there – taking another look at your boot messages (https://hastebin.com/nabajowusu), it looks like the USB Serial and the GSM modem are indeed getting enumerated differently each time as you suggested. In the first message, the serial ports were assigned to usb0 and usb2, and the GSM got usb1, usb3, usb4 and usb5. In the second, the GSM got usb0, usb1, usb2 and usb3, while the serial ports got usb4 and usb5.
Can you try adding udev rules for both devices and let us know how it goes? That may sort out the problem.
Thanks,
Hugh
of course, here is the device (i’m just pushing the update and gonna leave like that for a bit). Thank you
Will do, could you help me build the udev rules? 
Hi
One of my colleagues has created a handy repo with example containers and a blog to go along with that. See
This should help you configure the udev rules correctly for your devices
udevadm info /dev/ttyUSB0
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0/tty/ttyUSB0
N: ttyUSB0
L: 0
S: serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0
S: serial/by-id/usb-Android_Android-if00-port0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.4/1-1.4:1.0/ttyUSB0/tty/ttyUSB0
E: DEVNAME=/dev/ttyUSB0
E: MAJOR=188
E: MINOR=0
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=2585713782
E: ID_VENDOR=Android
E: ID_VENDOR_ENC=Android
E: ID_VENDOR_ID=2c7c
E: ID_MODEL=Android
E: ID_MODEL_ENC=Android
E: ID_MODEL_ID=0125
E: ID_REVISION=0318
E: ID_SERIAL=Android_Android
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ffffff:ff0000:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=option
E: ID_USB_CLASS_FROM_DATABASE=Miscellaneous Device
E: ID_USB_PROTOCOL_FROM_DATABASE=Interface Association
E: ID_VENDOR_FROM_DATABASE=Quectel Wireless Solutions Co., Ltd.
E: ID_MODEL_FROM_DATABASE=EC25 LTE modem
E: ID_PATH=platform-3f980000.usb-usb-0:1.4:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_4_1_0
E: DEVLINKS=/dev/serial/by-path/platform-3f980000.usb-usb-0:1.4:1.0-port0 /dev/serial/by-id/usb-Android_Android-if00-port0
Then for the other device whicih should be usb0
P: /devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1
N: ttyUSB1
L: 0
S: serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0
S: serial/by-id/usb-FTDI_Dual_RS232-HS-if00-port0
E: DEVPATH=/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3:1.0/ttyUSB1/tty/ttyUSB1
E: DEVNAME=/dev/ttyUSB1
E: MAJOR=188
E: MINOR=1
E: SUBSYSTEM=tty
E: USEC_INITIALIZED=2585562550
E: ID_VENDOR=FTDI
E: ID_VENDOR_ENC=FTDI
E: ID_VENDOR_ID=0403
E: ID_MODEL=Dual_RS232-HS
E: ID_MODEL_ENC=Dual\x20RS232-HS
E: ID_MODEL_ID=6010
E: ID_REVISION=0700
E: ID_SERIAL=FTDI_Dual_RS232-HS
E: ID_TYPE=generic
E: ID_BUS=usb
E: ID_USB_INTERFACES=:ffffff:
E: ID_USB_INTERFACE_NUM=00
E: ID_USB_DRIVER=ftdi_sio
E: ID_VENDOR_FROM_DATABASE=Future Technology Devices International, Ltd
E: ID_MODEL_FROM_DATABASE=FT2232C/D/H Dual UART/FIFO IC
E: ID_PATH=platform-3f980000.usb-usb-0:1.3:1.0
E: ID_PATH_TAG=platform-3f980000_usb-usb-0_1_3_1_0
E: DEVLINKS=/dev/serial/by-path/platform-3f980000.usb-usb-0:1.3:1.0-port0 /dev/serial/by-id/usb-FTDI_Dual_RS232-HS-if00-port0
The udev rules that I tried are:
SUBSYSTEM=="tty", ENV{ID_VENDOR}=="FTDI", ENV{ID_SERIAL}=="FTDI_Dual_RS232-HS", SYMLINK+="ttyUSB0"
SUBSYSTEM=="tty", ENV{ID_VENDOR_FROM_DATABASE}=="Quectel Wireless Solutions Co., Ltd.", ENV{ID_MODEL_FROM_DATABASE}=="EC25 LTE modem", SYMLINK+="ttyUSB1"
Btut when the system boots, it still doesn’t get recognized.
Hello,
Have you tried using /dev/serial/by-id/usb-Android_Android-if00-port0 and /dev/serial/by-id/usb-FTDI_Dual_RS232-HS-if00-port0 instead of /dev/ttyUSB0 and /dev/ttyUSB1.
That would solve your issue without adding new udev rules.
Hey there, this actually solves the problem!
I will test it further during tomorrow and next week!
Thank you a bunch 
Glad to know it worked, let us know how your testing goes!