When USB device is disconnected, /dev/hidraw0 is created by the integration

[andyboeh]

Sometimes, I have to disconnect the USB cable. Whenever this happens, the integration still tries to read/write from the hidraw device, resulting in a new file being created (hidraw1 in this case):

crw------- 1 root root 246, 0 Oct  5 00:24 /dev/hidraw0
-rw-r--r-- 1 root root      9 Oct  7 01:09 /dev/hidraw1

When the device is reconnected, the kernel assigns hidraw1 again, but the node can't be created due to the existing file and I'm stuck with a non-working integration until I manually delete the file.

Any chance this can be fixed?

[kukulich]

You can disable the integration just before you disconnect the cable.

I thnk it’s not the right solution to add another check to integretion because it can slow down the communication.

[andyboeh]

Seems like I have to explain my setup better: I use USB/IP to connect to the control panel. Sometimes, I have to restart (planned or unplanned) the machine connected to the control panel. I have scripts in place that reconnect to the USB/IP server and an automation to reload the integration when it's disconnected. This is all working fine, if there wasn't the wrongly created device file.

I had a quick look at the code: Given that there is a 100ms sleep before closing the stream, the penalty of doing a simple if not os.path.exists() is way less. But the more interesting question is: Why is the stream closed and reopened at all and not kept open?

[kukulich]

Why is the stream closed and reopened at all and not kept open?

It does not work without closing the stream.