Is there any way to permanently set USB0 to one node and USB1 to different node?

Hi all,

I have node red setup on a raspberry pi4b. Everything works, but the usb to serial connection. In the raspberry pi I specified each usb in by adding their attributes to the 10-usb-serial.rules file.
I can identify each cable by its unique Serial number. Here is an example (where UniqueSN is the
actual Serial Number):
KERNEL=="ttyUSB1", ATTRS{serial}=="UniqueSN01"
KERNEL=="ttyUSB0", ATTRS{serial}=="UniqueSN02"

I have it set like this as each usb has a different job and I can not have the data conflicting. When I go to the dashboard, if only one usb-serial connection is taking in data , both the serial nodes default to the port bringing in the data. I can not have this.
Is there any way to permanently set say USB0 to one node and USB1 to different node?
Here is a image where you can see both the connections are being set to the port receiving the data:
image

Here is what I did with 2 USB interfaces, 1x for RS232 and 1x for Modbus. This to have always the right information from the right interface

sudo cat /etc/udev/rules.d/99-usb-serial.rules
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60",SYMLINK+="tty-onduleur"
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523",SYMLINK+="modbus"

For example it creates a symbolic link like this

ls /dev/tty-onduleur -l
lrwxrwxrwx 1 root root 7 oct.  23 09:34 /dev/tty-onduleur -> ttyUSB0

And inside NR flows editor, i use this one for Modbus

image

and this one for the other RS232

image

like this, never mix data.
I hope this will help you.

3 Likes

Here is a link to a starter for writing udev rules, but it is quite heavy stuff.

2 Likes

Hi Jean-Luc,

Thanks for the quick reply. I tried this already where I added SYMLINK+="ttyUBS_COM1" and SYMLINK+="ttyUSB_COM2" to each cables attributes respectively. For some reason the dashboard does not pickup the set names, and when I manually change the name, the dashboard sets both serial inputs (although displaying different names) to take the input from the single working connection.
Here is an example image of it:

I also updated the .rules file:
KERNEL=="ttyUSB1", ATTRS{idProduct}=="2303", ATTRS{idVendor}=="067b", ATTRS{serial}=="CTAQf103Y23", SYMLINK+="ttyUSB_COM2"
KERNEL=="ttyUSB0", ATTRS{idProduct}=="2303", ATTRS{idVendor}=="067b", ATTRS{serial}=="BZBPv103Y23", SYMLINK+="ttyUSB_COM1"

For some reason when I set the name in node red to the SYMLINK name I added, It does not connect. But if I leave it as the default USB0 or USB1 like depicted in the original post image it is able to connect. I think that the rules I set are correct, have you had issues connecting them in node red before?

Unplug the devices then run
tail -f /var/log/syslog
and plug them in one at a time. Check that it recognises them and creates the symlinks.

1 Like

We will try to understand, what does it look like if you do this command ?

ls /dev/ttyUSB_COM1 -l and the same for ttyUSB_COM2

and this one when the 2 interfaces connected
lsusb

did you launch this order as well ? I can imagine
sudo udevadm trigger

Hmm thanks for the assistance,
It looks like my rules file is not going through properly.

When I run the ls command:

~$ ls /dev/ttyUSB_COM2 -l
ls: cannot access '/dev/ttyUSB_COM2': No such file or directory
~$ lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 004: ID 067b:23c3 Prolific Technology, Inc. 
Bus 001 Device 003: ID 067b:23c3 Prolific Technology, Inc. 
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Also I did launch the order.

when checking the usb's connected it is clear the name has not changed.

~$ ls -l /dev/ttyUSB*
crw-rw---- 1 root dialout 188, 0 Oct 27 16:27 /dev/ttyUSB0
crw-rw---- 1 root dialout 188, 1 Oct 27 16:27 /dev/ttyUSB1

Hi Colin,

Thanks for the suggestion!
When I followed your steps, I see the device is recognized. The serial number and make are all the same from what I have in the rules file. :

Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.294632] usb 1-1.2: new full-speed USB device number 5 using xhci_hcd
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.441730] usb 1-1.2: New USB device found, idVendor=067b, idProduct=23c3, bcdDevice= 3.05
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.441751] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.441770] usb 1-1.2: Product: USB-Serial Controller 
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.441788] usb 1-1.2: Manufacturer: Prolific Technology Inc. 
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.441805] usb 1-1.2: SerialNumber: CTAQf103Y23
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.446657] pl2303 1-1.2:1.0: pl2303 converter detected
Oct 27 16:30:34 raspberrypiscale2and3 kernel: [  233.449241] usb 1-1.2: pl2303 converter now attached to ttyUSB0
Oct 27 16:30:34 raspberrypiscale2and3 mtp-probe: checking bus 1, device 5: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2"
Oct 27 16:30:34 raspberrypiscale2and3 mtp-probe: bus: 1, device: 5 was not an MTP device
Oct 27 16:30:34 raspberrypiscale2and3 watchdog[608]: device eth0 did not receive anything since last check
Oct 27 16:30:34 raspberrypiscale2and3 mtp-probe: checking bus 1, device 5: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.2"
...
Oct 27 16:30:45 raspberrypiscale2and3 watchdog[608]: device eth0 did not receive anything since last check
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.524569] usb 1-1.1: new full-speed USB device number 6 using xhci_hcd
Oct 27 16:30:46 raspberrypiscale2and3 watchdog[608]: device eth0 did not receive anything since last check
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.661731] usb 1-1.1: New USB device found, idVendor=067b, idProduct=23c3, bcdDevice= 3.05
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.661754] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.661773] usb 1-1.1: Product: USB-Serial Controller 
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.661790] usb 1-1.1: Manufacturer: Prolific Technology Inc. 
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.661807] usb 1-1.1: SerialNumber: BZBPv103Y23
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.666513] pl2303 1-1.1:1.0: pl2303 converter detected
Oct 27 16:30:46 raspberrypiscale2and3 kernel: [  245.669196] usb 1-1.1: pl2303 converter now attached to ttyUSB1
Oct 27 16:30:46 raspberrypiscale2and3 mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1"
Oct 27 16:30:46 raspberrypiscale2and3 mtp-probe: bus: 1, device: 6 was not an MTP device
Oct 27 16:30:46 raspberrypiscale2and3 mtp-probe: checking bus 1, device 6: "/sys/devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1"
Oct 27 16:30:46 raspberrypiscale2and3 mtp-probe: bus: 1, device: 6 was not an MTP device
Oct 27 16:30:47 raspberrypiscale2and3 watchdog[608]: device eth0 did not receive anything since last check

It is connecting to the USB but it does not seem like the rules are being applied

Wrong product.

1 Like

Did that help?

Hi Colin, I was out of town for the past 5 days so I was not able to update this ticket. It did help. I am able to see both cables are now connected in node red! Now I am just trying to test the data. I will update the forum later today if I am able to get data from both.

Thanks a bunch for the help everyone! Crazy that such a silly mistake caused the issue.

I find I often get the easy bit wrong. Typos are very difficult to detect oneself. The brain sees what you think is there, not what is actually there.

3 Likes

You could probably use the exec node to see which ports are available and use this to enable that part of your flow?

Oh m a side note, it would be nice if we could choose serial device from /dev/serial/by-id To save using the udev rules

the search we use wraps the serialport library find function which eventually calls

Thanks @dceejay for the response. The code you've quoted doesn't mean a great deal to me due to my limited programming abilities. It did however, prompt me to try using by-id instead of just the tty port. It did work like this. Which makes me think it's easier to assign port by-id from now on.

Does this seem like a reasonable approach? (I have multiple ports on my node-red instances also).

image

1 Like

I haven't been able to find out how the system allocates serial by_id. Do you know how it is done?

That would work, but I want to make it cable specific as it will be used in an area where other people are working. If a cable gets unplugged I wanted it to work regardless of which port it is in hence using the cable's serial as an identifier.

This is what we originally tried, but if one connection was not receiving data, Node-red would automatically switch it to the other connection for some reason. We found this on two different raspberry pi setups running node red with 2 serial cables. This was not an option for us as something like this could easily slip under the radar and cost us greatly. Again I am not sure why it auto switches when data is not being received.

lsusb shows the id:

~ $ lsusb
Bus 006 Device 002: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter

Note the 1a86:7523.

Then look for the device by id:

~ $ ls /dev/serial/by-id
usb-0658_0200-if00 usb-1a86_USB2.0-Ser_-if00-port0

Note in my case there are two devices. One has the vendor id of 0658, the other has the vendor id of 1a86.

So the port I want to use is /dev/serial/by-id/usb-1a86_USB2.0-Ser_-if00-port0