I could use some people who wouldn't mind testing this on their own setups, noting that this is not intended for anything other than a Raspberry Pi 3B.
Preferably, I would welcome anyone who has had past experience using uhubctl, knows how it works and has perhaps used it before to control something from the Pi. If you're testing this, you should be comfortable remoting into your Pi, for example. And most importantly, you should to read documentation (all eleventy-hundred pages of it).
The four ganged (Type-A) style of ports are 2-5. The remaining one ("1") is the micro USB port that you usually use to power the board. The author of uhubctl indicates that the Raspberry Pi Foundation have USB Port 1 hub control managing the power for network communications. So toggling power to the 1-1 hub should turn off networking, in theory.
It is what uhubctl is, basically. Indeed, it should only affect the 5V power line on a per-port basis.
In reality, I've seen that it sometimes has difficulty in those cases where an ID isn't reported back from the downstream device. I'll eventually deep-dive his code to see exactly how it behaves and fork it if I'm not in love with the error logic.
Hmm... I thought there were two UARTs on the Pi rather than USARTs... unless you're talking about the controller board or you did a typo there. Color me "confused"...
In conversation with the author of uhubctl, he believes that the USB hub inside the Raspberry Pi 2B/3B does not support individual selection which doesn't seem to be what I'm finding in tests.
His documentation suggests that the 3B+ has better control over these.
Great idea!
You could add the device name as reported by uhubctl next to the switches. Some have a recognizable name, some unfortunately not:
Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports]
Port 1: 0503 power highspeed enable connect [0424:7800]
Port 2: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero] (closed loop stepper #1)
Port 3: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero] (closed loop stepper #2)
Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports]
Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports]
Port 2: 0103 power enable connect [2341:0042 Arduino (www.arduino.cc) 85334333931351612251] (MEGA2560)
Port 3: 0503 power highspeed enable connect [046d:0825 13DECCE0 (a webcam)
Port 4: 0100 power
Yes, the Pi has two UARTs (one good, one cheap). In the case where you're trying to GPIO something serially, doing serial-over-console or Bluetooth it's bound to a question of "are you feeling lucky, punk?" on the two available UARTs.
I've heard some strong opinion that none of the serial-over-USB ports as seen here use either UART.
The next version will attempt to determine the state and IDs of the four ports and to present this in some way in the Settings menu. At this point, you could then offer options which stop saying "port 3" and just say "the port with the Mega 2560 on it" in some way.
I'll also do some work by plugging in an external USB hub and then see what the interface looks like. In theory, you can toggle ON/OFF those as well if it's a smart hub.
Bummer. He's got a couple of issues on his repository in which he's indicating that the 2B/3B have internal problems that prevent the ports from being toggled individually. Technically, the 3B+ can be individually toggled but there's like two internal buses or something like that.
In order for this to truly be useful, you'd need to attach an external smart USB hub and then toggle things that are attached to that. But as we've heard, external USB buses cause latency problems on the serial printer communications.
@OutsourcedGuru Tried your plugin on RPI 3B+. Works as advertised, but I got one strange side-effect, which took me quite some time to link to USBControl. When plugin is enabled Feed rate and Flow rate sliders move to the top-left corner of the window. When I disable or uninstall the plugin, they return to their original place. Observed this behavior on 2 different RPIs under OctoPrint 1.3.10 running on OctoPi 0.15.1.
I tested with Klipper on RPI 3B+ and observed the following behavior:
USB2 - switches on and off LCD.
USB5 - switches on and off serial connection between OctoPrint and Klipper.
Considering this, would be nice to have some kind of grouping option and in one click be able to switch on/off pre-configured set of 2 or more ports. Also, my personal preference would prefer to have USB controls somewhere "closer" - in navbar drop-down menu, or under Control tab.
Since I don't have a Raspi3B+ at the moment, what I could use from you is the output of sudo lsusb -t and a quick analysis from you which port you'd guess your printer and LCD are plugged into.
The author of uhubctl suggests that The Raspi3B+ has some sort of odd-yet-possibly-functional split hub thing going on.
I'll get the CSS sorted out this evening.
By the way, I've included the REST API in the instructions. Once we get your 3B+ working from the Settings screen, it should be easy enough to add custom controls which talk to the API.
I'm having a different experience with the Pi 3B+. The only odd behavior happens when I disable Port 2 on 1-1, which switches off all 4 USB ports (they're not powered anymore, without showing up as off with uhubctl). The other ports can be switched off individually (0 bold in the table; 1 means ON and functional; 0 unexpectedly OFF)
NZS1
NZS2
Arduino
Webcam
1-1.1 port 2
1-1.1 port 3
1-1 Port 2
1-1 port 3
NZS1
1-1.1 port 2
0
1
1
1
NZS2
1-1.1 port 3
1
0
1
1
Arduino
1-1 Port 2
0
0
0
0
Webcam
1-1 port 3
1
1
1
0
My peripherals as reported by sudo uhubctl:
Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports]
Port 1: 0503 power highspeed enable connect [0424:7800]
Port 2: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero]
Port 3: 0103 power enable connect [1209:8087 MisfitTech.net Nano Zero]
Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports]
Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports]
Port 2: 0103 power enable connect [2341:0042 Arduino (www.arduino.cc) 85334333931351612251]
Port 3: 0503 power highspeed enable connect [046d:0825 13DECCE0]
Port 4: 0100 power
What happens when disabling Port 2 on 1-1 with sudo uhubctl -a 0 -p 2 -l 1-1
Current status for hub 1-1.1 [0424:2514, USB 2.00, 3 ports]
Port 1: 0503 power highspeed enable connect [0424:7800]
Port 2: 0100 power
Port 3: 0100 power
Current status for hub 1-1 [0424:2514, USB 2.00, 4 ports]
Port 1: 0503 power highspeed enable connect [0424:2514, USB 2.00, 3 ports]
Port 2: 0000 off
Port 3: 0100 power
Port 4: 0100 power
That's a very cool table but I'm missing the which-slider-did-you-exercise.
For your Raspi3B+, your screen should be different. It should allow all four ports to be exercised. If this is not the case, let me know.
Big caveat: The uhubctl program (on the Raspi3B) is guilty of what are called "false positives". It will lie to me and suggest that Port 5 is toggled OFF, for example, but there will be no affect whatsoever; the Raspi3B can't individually control the ports. If I were the author, I would detect that the hardware returns "ganged" for the type and then simply do nothing for any port other than one or two. What he's doing is sending the command to the USB hub, it's toggling the state and yet not adjusting the power. It then (earlier) gave me a false sense that I was actually doing something.
Behind-the-scenes, the current plugin runs commands like:
USB2:
sudo ./uhubctl --loc=1-1 --ports=2 --action=on
The remaining USB3, USB4, USB5 then would directly change that argument to ports. What this means for me is that I'd need to know what location decoration is required for a Raspi3B+ in order to make this happy.
If you're suggesting that the plugin for you toggles OFF all four ports when sliding USB2, that means—I'd guess—that the location of 1-1 is too promiscuous and needs to be brought down to the 1-1.1 level.
It's entirely possible that the chipset on your hub 1-1 is the "ganged" variety like on the Raspi3B and then the hub 1-1.1 is the better variety that allows control.
If you're patient, I can order a Raspi3B+ and do the analysis locally.