Hi @marcmerlin ,
I’m out of town, getting some much needed sun, so late to reply.
Some quick info: Yes you can connect to the PB expansion header pins and get serial console output. No, USB data pins are dead, just for power, no on board USB serial converter since PB is all done over wifi. You can get uptime and reset causes from the websocket status messages.
Tracking uptime might be useful because if PB is resetting frequently it will eventually go into fail safe modes and eventually stop driving LEDs and can drop off the network after many resets. More info here.
I don’t know what would be causing what you are seeing, it’s not something I’ve seen/heard a lot of. Power is often a potential issue when people have issues with a PB going unresponsive. It’s entirely possible that there’s a bug somewhere in the networking stack that is locking things up. For example, a long time ago, in an older version, there was a certain router that would crash a PB in AP mode.
There is a wifi health check in PB in that if it detects problems it will try to reconnect. If it doesn’t have an IP address or wifi isn’t connected it will attempt to stop and start wifi again once a minute. You’d see a message like main reconnect <counter> done, result=<wl_status_t> in the serial output. This attempts to restart the wifi network stack, but if something is very wrong, like a network task is hung or crashed or something, it might not be able to recover from that.
I know some PB users also have Ubiquiti equipment, and we’ve used it for some mission critical events (though for short periods of time). That said, there’s a million variables with settings and versions that could come into play.
If you want to attempt to manually reboot it, you can send an HTTP POST to /reboot. This of course would only work if enough of the network stack and main task was working to properly handle it.