Hi, I'm working on a Pd patch that connects to a few sensors via SLIP serial OSC. The serial implementation is based on this example : https://github.com/CNMAT/OSC/tree/master/Applications/PD

Everything works wonders and is really stable; however I run into an issue when a serial connection is lost, for instance when we I reset one of the sensors for calibration purposes. The patch is running headless on a RPI4 and the idea is "never" have to ssh in order to reload the Pd as this is running on a permanent sound installation.

I have created bind USB address on linux using the deviceID and vendorID of my sensors therefore naming on /dev/ is static (/dev/sensor_1, /dev/sensor_2, etc ...). I have also specified a large amount of retries on the [comport] object to allow the sensor to show up /dev/. But when I unplug one of the sensor, I can see [comport] loosing the connection and listing the retries:

error: [comport]: lost connection to port 9999 (/dev/sensor_1), retrying...
errors: retrying 45

I have also made sure that /dev/sensor_1 is back up on /dev/ while I can see [comport] endlessly trying to connect to it.

I think I'm running out of ideas here ... and would be grateful if someone could give me some pointers on how to either fix this issue; or finding another way around in order to ensure a dropped device will reconnect to my patch.

Thank you

@wazounet Pretty sure you will have to route the error message (assuming it arrives on the rightmost outlet of [comport]....?) and when it reaches a set integer (say 45) send comport a [close, open x ( message.
Disconnecting a usb device will break the connection and it will not be automatically "remade" for [comport] because the usb device creates an emulated port and the driver is unloaded on disconnect. A non-usb port would not suffer from a disconnect as the driver would still be running.
David..

Hi David, thank you for your answer and yes this was my worries about the simlink to serial.

I'll be trying your solution this evening, but is there a more elegant way to do this, rather than counting the retries ?