I’m a technical kinda guy, doing technical kinda stuff.
It was probably a marginal product deliberately overdriven beyond “good design norms” to make it look good for the currently-missing data sheet.
Put it on a variable voltage power supply, run it at 6v to 12v in one volt steps, and measure its output volume for ten seconds at each step.
You might find that you still have adequate flow for your situation at a lower, cooler, voltage.
Hmm I’m not sure of the pin drive currents on the Pico, but can you power the sensors off a pin? At least then you can programmatically power cycle them if you need to.
The Pico also has a watchdog, you could set it up to give it a reboot if things don’t respond in time. It doesn’t solve the issues of course but at least it gets it back to a workable state. And if the watchdog fails, or it works but there’s still no USB serial, then that would point towards power instabilities or somesuch.
Perhaps slightly adjust your logic a little and see what it does.
Read from the sensors first, then enable and connect to wifi, send the data, then disconnect. That would reduce the maximum power draw as only one function is active at once.
Small edit: I have a MagTag ESP32 board with circuitpython that can’t read onewire devices while the wifi is active. Whether that’s because of supply instabilities when wifi is transmitting, or interrupt conflicts, or just plain poor programming in the onewire drivers or the wifi drivers, I don’t know. But reading the devices first and then connecting to wifi and sending the data afterwards works.
Could be. The way the voltage sags at the end of the cable with the blueretro connected suggests that someone skimped on copper in the wires.
If you can figure out a way to measure the voltage at the port with the cable attached and powering the blueretro, do that. If it is mostly the same whether the blueretro is connected or not, yep, it’s the cable.