# How to match a ttyUSBX device to a USB Serial device **URL:** \ **Category:** Hardware\ **Created:** [7 October 2018 22:18 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747 "2018-10-07T22:18:58Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [7 October 2018 22:18 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/1 "2018-10-07T22:18:58Z")
By adding some rules to the /etc/udev/rules.d directory, you can force Linux to always use the same USB serial device which you can refer to by a more meaningful name. e.g. You have 2 USB-to-RS485 adapters. One is FTDI based, the other CH340 based. You want to use them both on the same Raspberry Pi to read two modbus instruments. The problem is sometimes the OS enumerates the adapters in opposite order. i.e. what was `/dev/ttyUSB0` at last boot time is now `/dev/ttyUSB1` and vice-versa. Adding a udev rule for each device, enables referring to the device by a name like `/dev/FTDI` or `/dev/CH340` as well as ensuring each name refers to the same USB device _every_ time. Here’s what the rules look like: ``` SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="CH340", MODE="0666" SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="FTDI", MODE="0666" ``` These two rules are specific to FTDI and CH340 USB-to-RS485 hardware. The link below shows how to find vendor IDs so you can make udev rules for your adapters. > ---
**Author:** ![pb66](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/pb66/32/27_2.png) [@pb66](https://community.openenergymonitor.org/u/pb66)\ **Post date:** [8 October 2018 12:04 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/2 "2018-10-08T12:04:47Z")
If you have FTDI based adapters you can often edit the device id’s and utilize that in the udev rules too, so for example if you have multiple devices the same (FTDI based) they are given both a recognizable prefix and a unique ref that doesn’t change regardless of connection order etc. See [Does the emonTx Shield need an actual Arduino? - #21 by pb66](https://community.openenergymonitor.org/t/does-the-emontx-shield-need-an-actual-arduino/2198/21) for example and context. Here’s the udev rule I use with all my USB connected emonTx’s (usually 3+ per install) ```auto pi@emonBase24(ro):~$ cat /etc/udev/rules.d/09-pb66.rules SUBSYSTEMS=="usb", ATTRS{product}=="emonTx*", ATTRS{idProduct}=="6001", ATTRS{idVendor}=="0403", SYMLINK+="emonTX-$attr{serial}" ``` and 3 connected emonTx USB devices listed by ls ```auto pi@emonBase24(ro):~$ ls -la /dev/emonTX* lrwxrwxrwx 1 root root 7 Dec 5 2017 /dev/emonTX-N1110RBF -> ttyUSB2 lrwxrwxrwx 1 root root 7 Dec 5 2017 /dev/emonTX-N212X7O2 -> ttyUSB1 lrwxrwxrwx 1 root root 7 Dec 5 2017 /dev/emonTX-N3Z3VPD -> ttyUSB0 ``` there is a free windows “FT\_PROG” utility available from FTDI to edit the ID (and other stuff) ([https://www.ftdichip.com/Support/Utilities.htm#FT\_PROG](https://www.ftdichip.com/Support/Utilities.htm#FT_PROG)) [EDIT] > [@Bill.Thomson](#): > > Here’s what the rules look like: > > ```auto > SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="FTDI", MODE="0666" > SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="CH340", MODE="0666" > > ``` > > These two rules are specific to FTDI and CH340 USB-to-RS485 hardware. Interesting choice to name your FTDI device “CH340” and the other one “FTDI”, that might prove confusing at some point down the line. 😁 Here’s the vendor:product id’s of the above mentioned 3 FTDI emonTx’s ```auto pi@emonBase24(ro):~$ lsusb Bus 001 Device 006: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 005: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 004: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ``` notice the vendor:product id’s are the same for the your FTDI usb~rs485 and my FTDI usb~serial programmer. and here’s one of those cheap rs485 usb adapters on a local Pi (top of the list) ```auto pi@raspberrypi:~ $ lsusb Bus 001 Device 004: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter Bus 001 Device 005: ID 10c4:ea60 Cygnal Integrated Products, Inc. CP210x UART Bridge / myAVR mySmartUSB light Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. SMC9514 Hub Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub ``` the second one down is an old style (full USBA) OEM shop bought programmer. ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [8 October 2018 15:23 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/3 "2018-10-08T15:23:45Z")
> [@pb66](#): > > Interesting choice to name your FTDI device “CH340” and the other one “FTDI”, that might prove confusing at some point down the line. 😁 That’s called “fat-fingering” the typing. 🕶 (maybe I need a new pair of glasses too) 😁 Fixed. ---
**Author:** ![gadgetbazza](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/gadgetbazza/32/8167_2.png) [@gadgetbazza](https://community.openenergymonitor.org/u/gadgetbazza)\ **Post date:** [22 November 2021 22:56 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/4 "2021-11-22T22:56:26Z")
Hi gents. I know I’m dragging up an old post here, but… I’m looking to connect 3 emonTx’s to an emonPi over a more reliable method. Currently they are posting using the Rfm2Pi which has issues with conflicting radio transmissions over time, despite the various attempts to stagger the transmissions. It’s just not bullet proof enough. I’ve also got 1 emonTx elsewhere on an ESP8266 which is not reliable in maintaining it’s connection to the Wifi despite there being plenty of coverage. Anyway, I’m not looking to discuss the above, but move to something reliable. I beleive I was pointed towards direct serial connection previously, so here I am. Reading through a few threads that are discussed on here, with regards to adding the nodeid to the interfacer output and changes to emonhub as well as the longer discussions about the wider issues of keeping compatibility with the different output formats for ESP8266 etc. So I’m looking for the simplest way forward and from what Im reading here, these programmable vendor id FTDI USB to Serial devices would still be the best option here? Or is there something more current in terms of sketch’s / emonhub updates etc that I’m missing? I’ve had a quick look on Amazon and identified the following possible candidate USB \> Serial cables, would these be ideal? > **[DTECH 6 Pin FTDI USB to TTL 5V Serial Converter Adapter 0.1 inch Pitch Female...](https://www.amazon.co.uk/Serial-Converter-Adapter-FT232RL-Windows-Black/dp/B08DKLKZTK)** > > 6-Foot FT232RL FTDI USB to TTL serial adapter cable for 5V logic level serial communication It is built with FTDI FT232 chip, FTDI’s royalty-free VCP allow for communication as a standard COM port and D2XX ‘direct’ drivers... Thanks Barry ---
**Author:** ![JustPlaying](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/j/b487fb/32.png) [@JustPlaying](https://community.openenergymonitor.org/u/JustPlaying)\ **Post date:** [7 October 2022 11:51 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/5 "2022-10-07T11:51:40Z")
> [@gadgetbazza](#): > > I’m looking to connect 3 emonTx’s to an emonPi over a more reliable method. > > Currently they are posting using the Rfm2Pi which has issues with conflicting radio transmissions over time, despite the various attempts to stagger the transmissions. It’s just not bullet proof enough. What measures have you tried to get them more stable? What’s the symptom of your RF problem. Is there anything unusual about your RF setup - big distances? Thick walls? Metal walls? Insulated walls with alumuniun foil bnded to the insulation to reduce radiant heat?.. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [7 October 2022 13:28 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/6 "2022-10-07T13:28:44Z")
As he hasn’t come back, I expect he’s happy - or given up. The latest rfmTxLib can ‘sniff’ the band before transmitting. It’s not completely foolproof, because if the competing transmitters don’t do the same, or dive in between the first one deciding the band is free and turning around to transmit, there’s still a collision. But I did find an improvement, with fewer missing values. (emonTHs don’t check first - it costs in battery life and they only transmit once a minute anyway.) ---
**Author:** ![Bill.Thomson](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/bill.thomson/32/1834_2.png) [@Bill.Thomson](https://community.openenergymonitor.org/u/Bill.Thomson)\ **Post date:** [7 October 2022 16:42 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/7 "2022-10-07T16:42:15Z")
> [@Robert.Wall](#): > > It’s not completely foolproof, because if the competing transmitters don’t do the same… Or, if it can’t _hear_ the competition, same results. ---
**Author:** ![Robert.Wall](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/robert.wall/32/38246_2.png) [@Robert.Wall](https://community.openenergymonitor.org/u/Robert.Wall)\ **Post date:** [7 October 2022 17:39 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/8 "2022-10-07T17:39:54Z")
Indeed, and I think that’s mentioned in the documentation. [Edit] And it is: “…a signal above the threshold is detected at the transmitter, it does not necessarily indicate conditions at the receiver.” The documentation also points out “Refer to JeeLib documentation for more information about the usage of the network group. Specifically, all groups use the same radio band, therefore although receivers ignore traffic in a different group, mutual interference might still occur.” ---
**Author:** ![gadgetbazza](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/gadgetbazza/32/8167_2.png) [@gadgetbazza](https://community.openenergymonitor.org/u/gadgetbazza)\ **Post date:** [10 October 2022 15:13 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/9 "2022-10-10T15:13:15Z")
Nothing to make them more stable per se (over rFM). I have 3 emonTX’s in close proximity to each other, one per phase next to where the power comes into the property in a workshop attached to the side of the garage. The other side of the single skin brick wall of the garage, maybe 10 feet away is where the pi is located. On my data collection I would see random periods where one of the emonTX unit’s data feeds are all dropped collectively, suggesting that this particular unit cannot communicate. This was also verified in the emonCMS tool looking at the inputs screen and seeing the delays on the input updates in many minutes rather than within 10 seconds as they are usually. Resolution was to move them all to USB serial and put the Pi in the workshop with them once I’d run an ethernet cable to that location. ---
**Author:** ![JustPlaying](https://community.openenergymonitor.org/letter_avatar_proxy/v4/letter/j/b487fb/32.png) [@JustPlaying](https://community.openenergymonitor.org/u/JustPlaying)\ **Post date:** [10 October 2022 15:33 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/10 "2022-10-10T15:33:58Z")
> [@gadgetbazza](#): > > Resolution was to move them all to USB serial Sounds like you’ve sorted it - by going non-wireless to the sensors - all good. Others might benefit if you posted a Recipe of how you did that. or is it already online here somewhere already? ---
**Author:** ![borpin](https://community.openenergymonitor.org/user_avatar/community.openenergymonitor.org/borpin/32/193_2.png) [@borpin](https://community.openenergymonitor.org/u/borpin)\ **Post date:** [30 October 2022 15:48 UTC](https://community.openenergymonitor.org/t/how-to-match-a-ttyusbx-device-to-a-usb-serial-device/8747/11 "2022-10-30T15:48:56Z")
It is here somewhere ☹ and also on the guide somewhere, but search function on the guide pages is as much use as a chocolate fireguard! Generally, you connect something to the EmonTX UART and then send that data by Wi-Fi.