Dev Log: July 12 Wrap-up

Overview

Today was all about hardening the connectivity logic for my HomeAlone project. I spent most of my time dealing with that annoying edge case where a device is technically 'connected' to the router, but the actual internet is nowhere to be found.

What I Worked On

Solving the 'Connected but Offline' Trap

I realized that my current setup was a bit too optimistic. It would see a successful WiFi connection and assume everything was fine, only to get stuck when trying to hit the cloud services because the ISP was down or the router was having a moment.

To fix this, I implemented a lightweight internet reachability watchdog. Instead of just checking if the WiFi status is active, I added a quick heartbeat check against a known-good endpoint. I went with the classic generate_204 approach because it's fast and doesn't require the overhead of a full page load or complex TLS handshakes just to see if the lights are on.

The BLE Fail-safe

The real goal here was to make the device smarter about failing. If the internet check fails a certain number of times in a row, the device now gives up on the current credentials, clears the cache, and reboots straight into BLE setup mode. This way, I don't have to manually reset the hardware if the network environment changes; I can just reconfigure it from my phone.

Here’s a sanitized look at how I’m handling the reachability check:

bool is_internet_reachable() {
  if (WiFi.status() != WL_CONNECTED) return false;

  // Use a lightweight HTTP check to verify the outside world is accessible
  HTTPClient client;
  client.begin("http://connectivity-check.example/status");
  client.setTimeout(5000);
  
  int httpCode = client.GET();
  client.end();

  // If we get any valid response code, we're likely online
  return (httpCode > 0);
}

Tuning the Watchdog

I had to be careful with the intervals. Checking every second is overkill and might look like a micro-DDOS if I have multiple devices running, so I settled on a 15-second interval. It’s frequent enough to catch a drop-out quickly but slow enough to stay under the radar. I also added a failure threshold—it takes five consecutive failed attempts before the device triggers the BLE fallback. This prevents accidental reboots during brief blips in the signal.

Wrapping Up

It feels good to have a more resilient connection flow. There’s nothing more frustrating than a 'smart' device that just sits there dumbly because it thinks it’s online when it isn’t. Tomorrow, I might look into optimizing the power consumption during these checks, but for now, I'm just happy it doesn't get stuck in a loop anymore.

Catch you later.