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.
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.
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
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.
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?
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.)
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.
and also on the guide somewhere, but search function on the guide pages is as much use as a chocolate fireguard!