How to match a ttyUSBX device to a USB Serial device

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.

1 Like

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 for example and context.

Hereā€™s the udev rule I use with all my USB connected emonTxā€™s (usually 3+ per install)

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

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)

[EDIT]

Interesting choice to name your FTDI device ā€œCH340ā€ and the other one ā€œFTDIā€, that might prove confusing at some point down the line. :grin:

Hereā€™s the vendor:product idā€™s of the above mentioned 3 FTDI emonTxā€™s

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)

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.

Thatā€™s called ā€œfat-fingeringā€ the typing. :sunglasses:
(maybe I need a new pair of glasses too) :grin:
Fixed.

1 Like

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?

Thanks
Barry

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?..

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.)

1 Like

Or, if it canā€™t hear the competition, same results.

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.ā€

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.

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?

It is here somewhere :frowning_face: 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.