- Most USB hub chips can be strapped/hard wired configured, or controllable by i2c already directly. Funnily enough this chip isn't, but is extremely cheap (less than 24 cents!).
- The "port enable" feature on this design only controls VBUS (power pin of each connector), not the hub itself, so on a self-powered device it may not actually disconnect the device if it doesn't need VBUS to operate.
Very good points - have you made an Issue on their repo to report these points? As they are currently doing a new revision, it would be good to see these sticking points submitted and get addressed by the devs, if they're not aware of them already.
I do a lot of firmware development and am constantly having to unplug/replug devices during the process .. for this reason I have an I-Tec 16-port Charging Hub, which has individual switches for each port - and this works fine, as long as I get the druthers to launch out of my chair and turn things off and on again... however being able to do all of this remotely, with software, would mean I could a) automate the hell out of a lot of things that requires monkey-tapping, and b) put the whole mess in a closet where it belongs, away from my coffee cup.
So I'm quite eager to see this project proceed - especially if there is a way the port capacities can be expanded (16-port would be ideal) .. so please consider officially reporting any issues in the design that you see!
Don't commercially available software controlled USB hubs exist already? The Yepkit YKUSH 3 came to mind immediately (https://www.yepkit.com/product/300110/YKUSH3) and is the only device I've seen that explicitly says that it disconnects both the data lines and power lines when switching. A casual search also finds https://www.usbgear.com/managed-hubs.html
I don't really see those as issues... The hub chip is cheap and doesn't directly do i2c, but, so ? Controlling VBus seems to be by design, exactly for devices that are separately powered to still work: see author's other project https://github.com/JimHeaney/usb-toggle . There should be a way to block further communication at the software level if that matters to one's use case. You can expand this, just plug a bunch of them into another hub...
I wonder if it supports software control? I haven’t messed with this in a long long time, but here’s a C program for controlling USB port power via software.
It works on a pretty limited set of hubs, because most cheap out on including the switches.
Hub chips often already have pins for per port VBUS control, and you just need to wire P-channel mosfets to them (hub manufacturers often cheap out on this). You can then control port power through sysfs.
In my experience this support was rare. I had an issue a few years ago with multiple USB 3 cameras (Intel Realsense) on a mobile robot that would periodically freeze up and need to be hard-reset, and a power-controllable hub seemed like the least-bad way to hack around it. I found my way to this tool, with its convenient list of compatible hardware:
Of the USB 3 options on the list, several were EOL or impossible to find, and when I ordered one each of the remainder, there was only one I could get working, and it wasn't reliable about being able to reset a device that had frozen to the point where Linux no longer had sysfs entries for it.
We ended up instead using a hub with an internal jumper to disable bus power, and then putting the self power line through a separately-controllable relay.
- Most USB hub chips can be strapped/hard wired configured, or controllable by i2c already directly. Funnily enough this chip isn't, but is extremely cheap (less than 24 cents!).
- The "port enable" feature on this design only controls VBUS (power pin of each connector), not the hub itself, so on a self-powered device it may not actually disconnect the device if it doesn't need VBUS to operate.
[1]: https://www.lcsc.com/product-detail/USB-ICs_CoreChips-SL2-1A...