Building a $35 Network Watchdog: Dead Man’s Switch for Your Internet Connection
Hook
Your router crashes at 3 AM. Again. By the time you wake up, you’ve missed alerts, deployments have stalled, and your smart home is dumb. What if a $35 microcontroller could fix this while you sleep?
Context
Internet service reliability remains frustratingly inconsistent, even in 2024. While ISPs tout 99.9% uptime SLAs, the reality for many users—especially those on cable or DSL connections—involves weekly modem freezes, router memory leaks, and inexplicable connectivity drops that resolve with the age-old IT solution: turning it off and on again. For remote workers, home lab enthusiasts, or anyone managing IoT devices, these failures aren’t just inconvenient—they’re costly.
Traditional solutions fall short. Consumer smart plugs require cloud services that may be unreachable during network failures. Enterprise-grade power distribution units cost hundreds or thousands of dollars. Writing scripts on a Raspberry Pi works but requires a separate always-on computer and manual wiring of relay modules. Dead Man’s Internet bridges this gap: a purpose-built embedded device that combines connectivity monitoring, power control, and status reporting in a single package smaller than a deck of cards. It’s the kind of unsexy infrastructure tool that you set up once and forget about—until you check your uptime logs and realize you haven’t manually rebooted your router in months.
Technical Insight
Dead Man’s Internet runs on the M5Stack AtomS3, an ESP32-S3-based microcontroller with built-in WiFi, a 0.85-inch color LCD, and GPIO pins for hardware control. The architecture is refreshingly straightforward: the main loop pings a target IP address (defaulting to Google’s 8.8.8.8 DNS server) at regular intervals, tracks success/failure counts, and triggers relay-controlled power cycles when thresholds are exceeded.
The core monitoring logic uses ESP32’s built-in ping functionality wrapped in a state machine. Here’s the essential pattern from the codebase:
void checkConnection() {
bool success = Ping.ping("8.8.8.8", 3);
if (success) {
consecutiveFailures = 0;
totalSuccesses++;
lastSuccessTime = millis();
updateDisplay("Online", GREEN);
} else {
consecutiveFailures++;
totalFailures++;
if (consecutiveFailures >= FAILURE_THRESHOLD) {
logEvent("Connection failed - initiating power cycle");
powerCycleModem();
consecutiveFailures = 0;
}
updateDisplay("Offline", RED);
}
// Auto-reboot if offline for 60+ minutes
if (millis() - lastSuccessTime > 3600000) {
ESP.restart();
}
}The relay control implementation is equally pragmatic. The AtomS3 drives a 4-channel relay board through GPIO pins, allowing independent control of multiple devices (ONT, router, switches). The power cycle sequence introduces deliberate delays to allow capacitors to discharge and devices to fully power down:
void powerCycleModem() {
digitalWrite(RELAY_PIN_MODEM, HIGH); // Cut power
delay(10000); // 10 second power-off
digitalWrite(RELAY_PIN_MODEM, LOW); // Restore power
delay(60000); // 60 second boot wait
// Reset failure counters after intervention
consecutiveFailures = 0;
}What makes this implementation clever is the web interface layer. The ESP32 runs an async web server that serves both human-readable HTML and a JSON API endpoint. This dual interface means you can check status from a browser on your phone or integrate it into monitoring systems like Prometheus or Home Assistant:
server.on("/data", HTTP_GET, [](AsyncWebServerRequest *request){
StaticJsonDocument<512> doc;
doc["status"] = isOnline ? "online" : "offline";
doc["uptime"] = millis() / 1000;
doc["totalFailures"] = totalFailures;
doc["totalSuccesses"] = totalSuccesses;
doc["lastReboot"] = lastRebootTimestamp;
doc["consecutiveFailures"] = consecutiveFailures;
String response;
serializeJson(doc, response);
request->send(200, "application/json", response);
});The M5Stack’s built-in display provides at-a-glance status even when the network is down—a critical feature often overlooked in network monitoring tools. When your internet is dead, you can’t reach a web dashboard, but you can glance at the device itself to see if it’s detected the failure and is actively working on recovery. The device also implements mDNS discovery, allowing you to access it via deadman.local instead of remembering IP addresses.
One particularly thoughtful design decision is the 60-minute auto-reboot timeout. If the device has been pinging unsuccessfully for an hour despite power cycling the modem, it assumes something is wrong with its own state and restarts itself. This prevents scenarios where the watchdog itself becomes the point of failure—a true dead man’s switch philosophy applied to the dead man’s switch itself.
Gotcha
The single-target ping strategy is Dead Man’s Internet’s Achilles heel. Relying solely on 8.8.8.8 reachability means you can’t distinguish between ‘my ISP is down,’ ‘Google’s DNS is under attack,’ ‘my router’s DNS resolution is broken but HTTP works,’ or ‘my ISP is blocking ICMP packets.’ A more robust implementation would ping multiple targets (8.8.8.8, 1.1.1.1, the router’s gateway IP), attempt DNS resolution, and perhaps even make HTTP requests to verify layer-7 connectivity. As it stands, you might power-cycle your equipment unnecessarily if Google’s infrastructure has a regional hiccup, or miss actual connectivity issues if ping works but DNS or HTTP don’t.
Security is essentially non-existent. The web interface has no authentication, the JSON API is completely open, and there’s no HTTPS support. If you expose this device on a network segment accessible to untrusted users, they can view your uptime statistics, force reboots, or even put your connection into a forced-offline state. For most home deployments behind a NAT router, this is acceptable risk. But if you’re considering this for a small business or anywhere with multiple users, you’d need to isolate it on a management VLAN or add authentication layers the codebase doesn’t currently provide. The ESP32 has enough horsepower for basic auth or even certificate-based TLS, but implementing it would require non-trivial code changes.
Verdict
Use if: You have genuinely flaky internet service that requires manual router reboots more than once a month, you’re managing remote equipment (vacation property, elderly parents’ house, remote office) where physical access is impractical, or you’re running critical home services (security cameras, home automation, remote work infrastructure) where connectivity gaps are costly. The $35 investment pays for itself the first time it saves you a two-hour drive to power-cycle a router. Skip if: Your internet is already reliable (you’re solving a problem you don’t have), you need detailed failure diagnostics and root cause analysis (this is a blunt instrument, not a precision tool), you require authenticated secure access, or you’re running enterprise equipment that already has IPMI/out-of-band management. For developers, this project is also worth studying as a template for ESP32-based monitoring tools—the code is clean, well-structured, and easily adaptable to monitor other services beyond internet connectivity.
