Your Board Stays Online, Even When a Module Doesn't
One dead sensor on the accessory bus used to be enough to knock a whole board off the network — we tracked it down and fixed it for good.
You might have noticed something strange: a board running perfectly happily, scripts still ticking along locally, network signal fine — and yet it just stops talking to the cloud. No error, no alert, nothing obviously wrong. We chased that one down, and the culprit turned out to be surprisingly small. A single failed accessory module holding the sensor bus low was enough to do it.
Here's what was happening. The bridge sweeps the accessory bus every few seconds to see which modules are plugged in. On a healthy board that sweep takes about three milliseconds. With one bad module on the line, every single address on that bus had to wait out its full timeout — and the sweep ballooned to nearly 35 seconds. Since the sweep holds the bus while it runs, and it kicks off again every three seconds, the board spent essentially all of its time scanning a bus that was never going to answer. The cloud connection, telemetry, the local API, your scripts — all of it queued up behind a loose cable.
So we went ahead and put a ceiling on it. Bus sweeps now run against a time budget rather than running until they're done, and when a sweep runs out of time the board correctly reports a bus fault instead of quietly telling the cloud your modules had vanished. We were careful about the margin here: a healthy sweep finishes roughly 285 times faster than the budget allows, so a working board can't even notice the change. Scripts got the same treatment — a write to a module that isn't responding now gives up cleanly after half a second instead of freezing the whole scripting engine while it waits.
The first pass helped, but when we went back and measured on real hardware we found a second, sneakier offender: the routine that watches for a bus that wasn't ready at startup was doing three separate full scans on every pass, and it was actually the bigger cost of the two. We removed the redundant scans, moved the remaining work off the main loop entirely, and added a backoff so a board with no accessories attached checks once every thirty seconds instead of hammering away every three. Under a sustained bus failure, the board went from spending 100% of its main thread on scanning to about 57%. We also stopped the fault log from repeating itself into oblivion — a forty-minute fault used to produce over three thousand lines and bury the history you'd actually want to read; now it's about one a minute. And because this class of bug is easy to reintroduce, we added a build-time check that fails if new code starts holding the bus for too long without declaring it.
The short version: a dead module is now just a dead module. Your board stays reachable, stays updatable, and stays diagnosable — which, when something has gone wrong on the bench, is exactly when you need it most.
If you've ever had a board go quiet and couldn't figure out why, this is very likely the reason. Update when you get a chance — and thanks to everyone who sent us logs from a board that had gone dark.