How to manage serial port disconnection

General
1

Hello,

I'm using Node-red on a Raspberry Pi 3B+ with Raspbian Stretch.
I'm also using UUgear 7-port USB hub.

I connected RS232 devices with node-red-node-serialport, using the serial request node.

For easier device management I gave names to my USB ports by adding udev rules using this and this tutorials.

This is working very well.

But sometimes my USB ports disconnect, often when I plug a new device or when I touch the hardware.
They reconnect immediatly and can be found using the cmd console, but Node-red lost them and I have to restart Node-red to get them back.

Do you know how I can manage this so Node-red can fin them back ?

Thanks for your help

1 Like
2

How do you know they are lost to node-red?

3

Before disconnection it is written "connected" with a green dot below the node.
After it is written "disconnected" with a red dot.
And I have a message in the debug console :

"serial port /dev/port_usb_2 closed unexpectedly"

port_usb_2 is the name I gave to my USB port, instead of ttyUSBx

4

Is this using the standard serial port node (node-red-node-serialport) or have you installed another serial port node?

5

Yes I'm using the standard one.
The disconnection is due to the hardware however what I need is when I detect a disconnection (I can with status or catch), wait a bit and ask nodered to reconnect. But I have no idea how to do that.
Sometimes it reconnect by itself but most of the time it doesn't.

6

I suggest you raise an issue against the node, it should reliably reconnect without you doing anything.
I don't know whether there has been any work on that node that might have improved it recently, are you using the latest version?

7

OK thanks
I installed nodered and serial port a few weeks ago so it is probably the latest version.

8

It should reconnect automatically on a disconnect... but sometimes we get reports that once it disconnects it then comes back as another port so then of course it won't reconnect.... is that the case here ? if/when it does it again can you list he serial ports you now have available (I would say ls /dev/ttyU* but you have renamed them, so I'll let you figure that out...)

9

I believe that this wouldn't be the case here as she has given the ports fixed names already.

10

Depends how they were (re)named.

11

Yes I renamed them also because I observed they changed names (ttyUSB*) when reconnecting.

To rename them I created a file 10-local.rules in /etc/udev/rules.d like this :

KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.4", SYMLINK+="port_usb_1"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.7", SYMLINK+="port_usb_2"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.6", SYMLINK+="port_usb_3"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.5", SYMLINK+="port_usb_4"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.1", SYMLINK+="port_usb_5"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.2", SYMLINK+="port_usb_6"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.3.3", SYMLINK+="port_usb_7"
KERNEL=="ttyUSB*", KERNELS=="1-1.1.2", SYMLINK+="port_usb_8"
KERNEL=="ttyUSB*", KERNELS=="1-1.3", SYMLINK+="port_usb_9"
KERNEL=="ttyUSB*", KERNELS=="1-1.2", SYMLINK+="port_usb_10"

After disconnection if I check my ports on the cmd console with

ls -l /dev/port_usb_1

I can find it, but it has not reconnected in Nodered.

12

I fought and won this battle many moons ago with node-red-contrib-rfxcom, though recent versions of the serialport node did cause some trouble. It is a case of listening to serialport events, and using a timer to attempt reconnection at regular intervals if a disconnection is detected. But this is USB-serial device specific, and may cause problems with actual hardware UARTs. It could be made an option on the serialport node, maybe?

Edit to add: The logic is split between node-red-contrib-rfxcom and node-rfxcom.

1 Like
13

I have also seen this sometimes. To solve the issue, I use a utility named usbreset (with google you will find it here: https://github.com/jkulesza/usbreset)

I configured NR to use a status node checking the status of rfx node. In case it showed "OK", everything is fine but if it shows "disconnected", the trigger node kicked in and activated the exec node. Shortly after, everything was working again. Today I do not recognize any communication problems with the RFXtrx

The command I use for the exec node is as follows:

export DISPLAY=:1 && xterm -geometry 96x24-450+450 -e sudo /home/pi/usbreset /dev/bus/usb/001/005

but, if you do not want it shown on the monitor screen, I guess you could just use

sudo /home/pi/usbreset /dev/bus/usb/001/005

(you have to find out on which usb device it is connected to, in my case 001/005)

image
image.png1439Ă—692 97.6 KB

14

Hi,

Thanks for your advices.

RFXcom doesn't seem to fit my need compare to serialport nodes.

I tried using usbreset however I was not successful.
I manage to reset the USB port however when it reconnects it is still in error ("waiting").

If I look for the devices with

ls -l /dev/usb_1

I find it properly (usb_1 is the simlink given to the port)

If I deploy again Nodered app, the port reconnects.

I don't know how to trigger the reset from the dashboard, as a "deploy" does. Do you have any idea ?

Thanks for your help.

15

RFXcom is a special product for a special purpose, obviously is of no interest if you just wanna do serial comms

Are you talking about "full deploy"? If so, I think it is restarting the flow and it might be that this in itself is releasing some handles to the serial port. In later versions of NR you have the possibility to restart the flow via the "Deploy" button in the editor. Next time you see the problem with the serial, you could try this to see if it is enough to fix it, just to verify

If it seems to help, you could implement a flow restarter in the dashboard using a template node, in this thread there is a possible solution discussed

16

Thanks a lot, this is working for me.
The remaining issue I have to solve is that it's reloading all flows, so I have some undesired behaviours.

17

@Charlotte have you found a solution for disconnect/reconnect issue with USB serial device as symlink? I have been struggling to get this right, but restarting the flow is not the solution for me. I have an open session in Node Red that I don't want to loose by restarting the flow.

18

@Charlotte I may have solved it myself with a temporary solution. It seems that something has changed or broken with node-serialport >=0.9.0? I can make it work by installing earlier version of it. It works just fine on my platform with node-serialport 0.8.8, and symlinks to physical ports work as well in my box.