Programmatically Enabling a Serial Port Node?

[JethroNull]

I've got several USB/UART serial nodes, available to my flows.  Currently I have to delete them out of the flow if there is nothing connected to their respective port or they throw continuous errors (is that an issue anyway?  filling up logs?).  It would be much nicer if I could check to see if the port was available at startup (or periodically) and only enable the flow or serial node if the port was found to be available.  Anybody got any ideas if this is possible?

Also, related to that, I've been trying to figure out how to ensure that my flows always talk to the correct port.  several of my serial devices are identical, same device descriptor etc. So the usual udev script is not so easy.  From what I've read it looks like I should be able to define udev rules that specify the physical port.  As always, I am lazy and wondering if there is any easier way, especially from within node-red?  Seems like this would be a common issue for Linux-based IoT products that have to think for themselves on startup and don't have the luxury of a friendly human to reconfigure them.

[Andrew Lindsay]

Also having issues after a reboot on Linux, in that the names of the usb to serial devices get swapped round. Are there some udev rules or similar to force devices to be on the same device name.

I don't have this to deal with much due to rare reboots. Should be solving one when I upgrade CurrentCost to use Ethernet instead of serial.

Cheers

Andrew

[Stuart Poulton]

Andrew,

Really depends on your USB to serial adaptors, if it’s FTDI based one’s it’s easier as each one has a serial number

For others you need to make use of the USB hierarchical tree, see below for some pointers.

http://askubuntu.com/questions/49910/how-to-distinguish-between-identical-usb-to-serial-adapters

[Greg EVA]

Hey... for the issue of knowing which port is which, you need to use udev rules in order to map/link the port to a symbolically named reference when the USB device is plugged in.

3. Use symlinks if you use more than one USB port Create or add to existing file (/etc/udev/rules.d/50-usb-serial.rules) a rule like the following:

SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{product}=="RFXrec433", SYMLINK+="USBrfx", GROUP="dialout", MODE="0666" SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="USBzwave", GROUP="dialout", MODE="0666"

You can use lsusb -l or -v I think to find the specifics of your USB devices, then setup a rule as mentioned above, and you are golden!

Greg

[JethroNull]

Here's what I've been doing that SEEMS to work for me, but it's early days and I'm just guessing at stuff:

Type:

dmesg | grep tty

I get:

pi@raspberrypi / $ dmesg | grep tty
[    0.000000] Kernel command line: dma.dmachans=0x7f35 bcm2708_fb.fbwidth=656 bcm2708_fb.fbheight=416 bcm2709.boardrev=0xa21041 bcm2709.serial=0xebbb2914 smsc95xx.macaddr=B8:27:EB:BB:29:14 bcm2708_fb.fbswap=1 bcm2709.disk_led_gpio=47 bcm2709.disk_led_active_low=0 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x3ea00000 vc_mem.mem_size=0x3f000000  dwc_otg.lpm_enable=0 console=tty1 root=/dev/mmcblk0p2 rootfstype=ext4 elevator=deadline rootwait
[    0.001729] console [tty1] enabled
[    0.692261] dev:f1: ttyAMA0 at MMIO 0x3f201000 (irq = 83, base_baud = 0) is a PL011 rev3
[    3.309195] usb 1-1.5: FTDI USB Serial Device converter now attached to ttyUSB0
[    3.463609] usb 1-1.3: cp210x converter now attached to ttyUSB1
pi@raspberrypi / $

I'm interested in the two last lines and I interpret them to mean:

what is currently known as ttyUSB0 is on physical bus 1 hub 1 port 5

what is currently known as ttyUSB1 is on physical bus 1 hub 1 port 3

I then wrote a new file "10-usb-serial.rules" in /etc/udev/rules.d which has the following lines:

KERNEL=="ttyUSB*", KERNELS=="1-1.3", NAME="ttyUSB0"
KERNEL=="ttyUSB*", KERNELS=="1-1.5", NAME="ttyUSB1"

As I understand it this equates to:

If this device is type ttyUSB and is on physical port 1-1.3 then call it ttyUSB0

You can choose other parameters to define the device you are looking for, serial number or manufacturer code for instance.  I think that's what Greg is showing above.  The Ah ha moment for me was realizing that the chunks that have == in then are parameters to match and the chunks that have = are the instructions to fulfill if there is a match.  Greg, am I right?

I learnt (fully recognizing that I blundering in the dark) the above from http://www.reactivated.net/writing_udev_rules.html

Scan down to the heading 'Basic Rules' to get to the interesting bits.

Jon

[Greg EVA]

@Jon,

There are two approaches to udev rules, and so also device referencing, from what I have learned.  You can reference where the thing is connected to, or reference the thing itself.  Depending on what you are doing each has its uses.  For example, people have started referencing hard disks by ID instead of the bus connection.  This way it doesn't matter which SATA,SAS,etc. port you have it plugged into.

So you are correct in your understanding about specifying the USB port which the device is connected to; however this implies that you will always plug these devices into the same ports.  Plugging them in differently would once again land you with errors due to getting unexpected data as you don't know what device you are reading from.

This is why I have tried to detected the actual device being connected (in my example rule).  This way you can identify the exact device which is connected.  Now this isn't always so simple however as the devices are often FTDI serial devices and don't necessarily implement the correct product, family, and specifically serial number fields.  Using the serial number is nice, because you could use two of the same devices, however otherwise there is no way to know for sure which is which if they have the same vendor/product/etc fields.

And yes.... the == are more conditional evaluation, and = is for setting something.  To be honest, I have no real idea of how the udev rule syntax works.... I just found the details I needed, found a couple examples online, and did a bunch of trial and error.

Cheers,

Greg

[Dave C-J]

If you have FTDI based serial devices you can try the ft_prog app from ftdi http://www.ftdichip.com/Support/Utilities.htm#FT_Prog to change many of the settings....

I have used this to set the description which can then be picked up by udev rules. (You can of course set/reset device codes etc but I decided not to push my luck).

With udev you can also assign a unique port name to the device if you wish... Eg ttyWeather, ttyPowermeter etc - then connect Node-RED to /dev/ttyWeather...

[Greg EVA]

Sweet!  Thanks for that tip Dave.

[Jon Richings]

Greg, we are planning on using our setup commercially where only certain devices will be plugged in and we can control what is plugged into which port.  But all devices have the FTDI chip so all report as the same.  We don't want to have to check and configure by serial numbers for every installation, that would get really labor intensive.  

For the same reason we couldn't use Dave's tip, though I echo your sentiment: Sweet Dave, didn't know you could do that.  I'll add it to the armory!

On Tue, Jun 9, 2015 at 7:34 AM, Greg EVA <ge...@ge-volution.eu> wrote:

Sweet!  Thanks for that tip Dave.

--
http://nodered.org
---
You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/ehyR8G7RWfI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Dave C-J]

Jon,

yes - if you can control the physical port being used then use the bus-hub.port method you have already identified. (and you can still use custom names if it helps)

KERNEL=="ttyUSB*", KERNELS=="1-1.3", NAME="ttyMyThing"

[Dave C-J]

Only downside of this is that autodetect may/will not work as the auto-detect often assumes ttyUSB... or ttyACM... etc  - but manually specifying the port in the app will work.

[Jon Richings]

Wooh, look at me, getting all Linuxy;)  Thanks for the validation Dave.  

RPi's serial port always seems to come up as ttyAMA0, is there any scenario where that might not be relied upon?

BTW, do you go by Dave or CJ?

On Tue, Jun 9, 2015 at 3:19 PM, Dave C-J <dce...@gmail.com> wrote:

Only downside of this is that autodetect may/will not work as the auto-detect often assumes ttyUSB... or ttyACM... etc  - but manually specifying the port in the app will work.

--

[Dave C-J]

As it's part of the Pi chipset you would like to think it doesn't move (unless you have a hardware failure).

not fussed - I'll respond to either :-)

[Greg EVA]

@Jon

I understand... that's the cool thing is that you can choose the approach which best suits your needs.

In regards to counting on the /dev/ttyAMA0 naming on the RPi, in my experience I have a number of USB devices which are really serial devices which have implemented a serial to USB chip, and what I have seen is that some of them show up as ttyAMA0,1 and others as ttyUSB0,1.

I think you can safely assume however that for a particular piece of hardware, if it is detected as AMA, then it will always be so.  Should you not want to make such assumptions for your commercial product... I'd suggest you root around in the udev rules.  I was pretty amazed to find rules for detecting, naming, setting up, pretty much ALL devices.  Not only will this help you understand how udev and the rules work, but you may be able to find the piece which is detecting/naming the ttyAMA0 device in order to better understand its programming.

Cheers,

Greg