NodeRed serial ports keep disconnecting

General
1

Hi there. I am having issues with serial connections in NodeRed. I am using the 'node-red-node-serialport' node to connect a Raspberry Pi 5b to various serial USB devices controlled by PIC24's.

This works fine, but if I leave the setup running for long enough then eventually some will timeout. This seems restricted only to devices connected to USB ports on the PI, whilst the other devices on a USB extension (which in itself is plugged into the PI of course), stay working fine. All start timing out at the same time, it is not a gradual failure.

'dmesg | grep usb' shows:

[54676.834941] ftdi_sio ttyUSB2: usb_serial_generic_read_bulk_callback - urb stopped: -32
[54676.835316] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

repeated... ~ 10 times

This perfectly coincides with when I stopped receiving returns from requests in NodeRed, I only have 2 things unexplained:

  1. I stopped receiving data from 3 devices acc. to NodeRed - not just the 2 I can see in dmesg
  2. Disabling power management did not remedy the situation, and I am now stuck, as explained below:

My first thought was that this was a power management issue, so I set all the USB devices to autosuspend off:

for d in /sys/bus/usb/devices/*/power/control; do
    echo on | sudo tee "$d"
done

However I still get the same recurring issue.

Manually requesting using, echo -ne "" > /<DEVICE_PATH> & cat /<DEVICE_PATH> | xxd, stops working at the same time too. It is not just NodeRed failing to request data from these, I have to restart the computer to get them to work again at all.

Have I disabled it wrong? Are there any other suggestions as to the issue being entirely different?

2

Interesting... This has been reported several times over the years - and so far we have been unable to pin it down... but the fact that you have found that the echo also stops working is pointing to something outside of Node-RED which is both good and bad. Good in that it is not something we are doing (or not doing) in Node-RED - but bad in that we are still none the wiser as to what it could be and how to fix it. If it was a generic problem you would think you would see more reports elsewhere of the serial port stopping , which I don't really see "outside" of Node-RED world - so...

3

Yes it's interesting isn't it. It's clear its an OS/driver issue rather than a NodeRed one given even the basic request fails.

I've found other cases of people having similar issues on raspbian OS Pi's, but I don't know what the common factor is. Does anyone know if its possibly a Pi issue or just a linux issue etc. ? I haven't used NodeRed on anything other than a Raspberry Pi before so genuinely have no idea.

I am running Armbian not Raspbian for context.

I think its very interesting that the devices attached through the USB hub don't fail. The HUB itself is attached through the same set of USB ports that seem to go down for individual devices, but non of the ports the HUB exposes go down.

I feel like the solutions in there somewhere, I could just plug in another HUB by this logic and solve it, but that seems a waste.

4 
[Fri Oct 17 10:35:27 2025] usb 1-1.4: USB disconnect, device number 6
[Fri Oct 17 10:35:28 2025] usb 1-1.4: new full-speed USB device number 14 using xhci_hcd                                            
[Fri Oct 17 10:35:28 2025] usb 1-1.4: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[Fri Oct 17 10:35:28 2025] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Fri Oct 17 10:35:28 2025] usb 1-1.4: Product: USB-Serial Controller
[Fri Oct 17 10:35:28 2025] usb 1-1.4: Manufacturer: Prolific Technology Inc.
[Fri Oct 17 10:35:28 2025] usb 1-1.4: pl2303 converter now attached to ttyUSB1
[Fri Oct 17 14:15:02 2025] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Fri Oct 17 14:15:02 2025] pl2303 ttyUSB1: usb_serial_generic_read_bulk_callback - urb stopped: -32
[Sun Oct 19 13:10:27 2025] usb 1-1.4: USB disconnect, device number 14
[Sun Oct 19 13:10:28 2025] usb 1-1.4: new full-speed USB device number 15 using xhci_hcd
[Sun Oct 19 13:10:28 2025] usb 1-1.4: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 4.00
[Sun Oct 19 13:10:28 2025] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[Sun Oct 19 13:10:28 2025] usb 1-1.4: Product: USB-Serial Controller
[Sun Oct 19 13:10:28 2025] usb 1-1.4: Manufacturer: Prolific Technology Inc.
[Sun Oct 19 13:10:28 2025] usb 1-1.4: pl2303 converter now attached to ttyUSB0
[Sun Oct 19 14:45:42 2025] pl2303 ttyUSB0: usb_serial_generic_read_bulk_callback - urb stopped: -32

After leaving it long enough, one of the devices eventually naturally reconnected. I did not do anything for this, I was away over the weekend, its in a locked cabinet, and I don't have remote SSH setup. So this was completely automatic.

I'm just perplexed at this point. Any ideas as to other logs I could check to get some more clues as to whats going on?

5

Auto suspend?

6

Note that on 17th the usb disconnected and then immediately reconnected. This is not unusual with usb serial devices. Are you using a good quality PSU? It reconnected as device ttyUSB1. Then on the 19th it disconnected again and reconnected as ttyUSB0. What device have you configured the serial node to use?

If you run
ls -l /dev/serial/by-id
you should be able to find the device there. If you use that as the device name then it will work even if it connects via a different ttyUSB number.