Boards That Stay Connected
Two fixes for the same nagging complaint — a board that quietly stops talking to the cloud and never quite comes back.
You might have noticed a board that ran beautifully for a day or two and then just... stopped. Scripts that quit mid-run for no reason anyone could name. A device that looked online but wasn't. We chased that one for a while, and the culprit turned out to be embarrassingly small: every time the board checked in with the cloud, it built a brand-new network connection handler instead of reusing the one it already had. Those handlers hold onto system resources, and on a board with a flaky link they didn't let go. A few hundred check-ins later, the board simply ran out of room to open anything at all — no new connections, no name lookups, nothing.
What made it so slippery is that it never announced itself. It looked like a Wi-Fi problem. Then a DNS problem. Then a version mismatch. Testing from a shell on the same board always came back healthy in a quarter of a second, because that's a separate process with its own budget. We went ahead and built those connection handlers once and shared them for the life of the process, which is how they were meant to be used anyway. On the same board that had been hovering right at its ceiling, resource usage dropped to a couple dozen — and stayed there. Connections get reused now too, so check-ins are a little quicker as a bonus.
With that out of the way, a second problem got much easier to see. When a board drops off, it saves up messages so nothing gets lost — good idea, mostly. But motion sensor readings stream at five per second, so a three-minute dropout filled that buffer completely. The moment the board reconnected, it dumped a thousand stale sensor readings onto the weakest possible link at the worst possible moment, which often knocked it right back offline. Classic loop. So we stopped saving sensor readings during an outage, the same way we already skip old heartbeats and log lines — a three-minute-old accelerometer number isn't worth the bandwidth, and the board takes a fresh reading within a fifth of a second of reconnecting anyway. Everything you'd actually miss — command results, events, script output, update status — still queues up and arrives in order.
Together these mean reconnects are quiet and quick, and a board on a marginal signal recovers instead of spiraling. If you've been power-cycling a device now and then to bring it back to life, that habit should be safe to drop.
If you've been babysitting a board on a weak signal, give it a few days on this build — we think you'll stop thinking about it. As always, tell us what you see.