@Criggie nah, sounds sensible. That way you don't have to deal with "I forgot my password. Just like every Monday", escalated from tech support because it's a manager.
I still recall at NAB making some poor sysadmin go through paperwork and faffing to red-button a server that I was having problems with. It was quite deliberately an ugly process, specifically to discourage programmers like me from using it as a regular part of our procedures. But we ran Windows, FFS, rebooting is SOP.
The problem turned out to be that someone had supplied us with a library that relied on being restarted every now and then, or it ran out of some kind of managed handle. Coz after all, why would you ever clean up handles, you can have billions of them. Enough, IIRC, for about 8 months.
MY server code, OTOH, sometimes runs for days and days before management demands that a new feature be made available immediately right now this second we promised the users why isn't it up don't worry about testing it will be fine.
@Criggie we have some kind of generic 8 port $10 hub-switch-thing that someone picked up in a dumpster last week. Turns out that saturating a wifi router for the weekend made the dumpster part die in the arse. Not "power cycle it", but serious FoK, only the LEDs still work. We are trying to debug a wifi part, and saturating the link lets us do more cycles per hour...
What's it called when you pull a wheelie and hold it while you ride around on just the back wheel? I learned the term as a kid and I think it started with "c", but I could be wrong or the term could be wrong. It's been bugging me ever since I found this site and went through the glossary and Wi...
Oh, we are grinding through embedded wifi hardware options ATM, hence the interest in how long they can run before needing a reset. Market is running about $2-$3 each, but up to $20 and working out whether we get any benefit from the extra cost is fun. "fun"
@Criggie it depends a lot on exactly that sort of reset is required. We can't power cycle the device that's using the wifi, so having to add a circuit that lets the device power cycle the wifi module would be one option, provided everything can recover from that. A huge PITA option, but an option.
We already have other subsystems that get power cycled, but that's because customers don't want to buy big enough batteries to power everything (and really, battery powering a module that lets them control mains powered devices ... during a power cut... doesn't make a lot of sense :)
But yeah, building distributed systems is challenging, especially when you have encrypted buses and have to re-sync without losing security. But at least we already have that code, and the wifi module is effectively outside the security perimeter so there's less hassle there. And of course, then we store all that sensitive data in the fscking cloud and sometimes I wonder why I even bother.