When the node-red starts, the flow(program) picks up the hard-coded serial ports and open them. But when a device re-connects after disconnecting for any reason, it may be possible the port number change, but the end user of the flow can't change the port unless he/she has the access to the node-red editor.
Recently I had to develop a feature on top of node-red-node-serialport that enables the end user of node-red to change the port number/name without the access to the node-red editor.
I would like to contribute my work to node-red-node-serialport, and I would like to understand & follow the procedures to do this.
Hi @yhur, welcome to the forum and thanks for your contribution.
I have moved this to the feature requests category and tagged with the module name.
The core devs generally prefer to see suggestions appear here in the forum first so that they can be discussed. If they agree that it is worth looking at further, they will probably ask you to do a PR.
SerialPortNode was changed to have a new function close the current port and open a new port with passed parameters like port number/name, baudrate, databits, parity, stopbits, and so on.
SerialOutNode and SerialInNode are modified to reflect newly changed port connection on 'newport' event.
a new PortSelectNode is introduced that has in and out ports. It receives the port config information, updates, emit 'newport' event.
This is the basic idea implemented. And this is the diff of the changes
Hi @yhur thanks for your efforts & your desire to feedback into the community. It is much appreciated.
Can I ask you to do some screenshots or better still - a short video that demonstrates the features you are adding?
This will permit us to quickly understand the features & make sense of your offering. I'm sure it is all good but we might spot soothing that needs addressing before accepting a pr. I'm sure you understand.
Do you mean here, when the interface (eg /dev/ttyUSB0 or COM1) disconnects and reconnects as /dev/ttyUSB1, rather than a device disconnecting from the serial interface, but the interface remains active in the system.
To repeat, what I meant was the user physically disconnecting and reconnecting the device. For Linux and macOS, it's not big problem, but for Windows, the COM? port may or may not change. Besides, the project team who used my work needed to connect several different devices in turn to test with them.
That still is ambiguous. For example, if I have a USB serial adaptor wired to a serial slave of some sort, if I disconnect the wire from the slave and reconnect it then the port should not change. If, however, I unplug the serial adaptor from the USB socket and plug it in again, then the port may change.
Colin, for the purposes of this request I don't think it matters. He just wants the ability for the end user to be able to change / select which serial port they want to use without editing the flow itself, whether it has changed replugging USB and it moving or the user plugging a device into a different port.
@Colin,
Sorry for the unclear explanation on device. What you said later is what I meant. As you said when the USB FTDI device is unplugged and replugged there are chances the port number change on the Windows.
and some dodgy clone usb chips have identical IDs - so if you plug in more than one it can get confusing also...
But regardless - this suggestion of a new way of letting the user manage the port does seem to have merit. IE having a separate node to manage the underlying control node - so advanced users can use it if they want to - but for simple use cases it is not necessary and doesn't add extra complexity to the existing simple in and out nodes.
I know, but for others finding this I thought it was useful to clarify that disconnecting the serial device (not the adaptor) should not cause the com port to change.
