I had a need to test the insert/remove a whole bunch for a while. Because the timing worked out, I ended up getting a programmable USB hub [1]. It worked well for my needs, but I'm not sure I'd trust it enough for a really inaccessible location.

I do wish I could find a not stupid priced version of this concept that does USB 3.1

[1] https://capablerobot.com/products/programmable-usb-hub/

Checkout this Hub Control library for C. https://github.com/codazoda/hub-ctrl.c

I'm the maintainer, but I can only take credit for updating a single line, uploading to GitHub, and doing PR's (mostly to the README) every once in a while.

This brings back memories from about a year ago when i was doing robotics.

Azure Kinect DK depth cameras had a firmware/hardware issue that would let it get stuck every now and then, and it would have to be power cycled. You'd imagine it'd be easy, but it was surprisingly hard. Ended up getting a new usb hub that supports power cycle...

If the system is well designed, this power cycle should be a rare event (ie. maybe once per year).

For that rare event, it doesn't seem worth writing code to power cycle a single USB peripheral (and then write and test all the code to clear the error states at each level of the stack and bring that peripheral back up again).

Instead, power cycle the entire system. Have a small hardware watchdog which, when not being tickled, will power off the whole system for 5 seconds and power everything back on.

Write code to periodically tickle the hardware watchdog when everything is 100% healthy, or when 3 reboots have happened in short succession (you'd prefer the system up with 90% of the hardware working than bootlooping).

Have a mosfet between the 5 volt regulator and the device. At 20 milliohm, drawing .1 amp, that's only 2 millivolt drop. Or, since it's a low volume design, just throw a relay in there.

I have a buggy flashing tool that often ends up needing a hard power cycle, and I wish this were easier just to prevent wear on the physical port...