I’ve always hated standing at a bus stop without knowing when the next one was coming.

Years ago, I solved that problem for myself by building an iPhone widget that displayed real-time SEPTA bus times right on my home screen (writeup here). It worked perfectly, but unfortunately the App Store fees weren’t worth keeping it alive.

DIY IoT Solution

An ESP32 with a built-in LCD pulling real-time SEPTA bus data.

Figure: An ESP32 with a built-in LCD pulling real-time SEPTA bus data

Fast forward to today: I discovered the ESP32, a low-cost Wi-Fi/Bluetooth-enabled SoC that’s perfect for small connected projects. Even better, Adafruit’s version includes a built-in LCD display. At just 240x135 pixels, it’s tiny—but exactly what I needed, and it sips only 3.7v to run 24/7.

With this little board, I wrote a lightweight program that:

  • Pulls data from a web API (via SEPTA Developer program)
  • Parses and formats the response
  • Displays real-time bus times in a simple, readable format

Now I’ve got a dedicated device on my desk that solves the exact problem I set out to fix years ago without relying on the App Store. The best part? It costs about $0.25 per year to run continuously.

Connectivity & Network Reliability

Here’s where it gets interesting.

This program is simple, but it makes some big assumptions:

  • What if the 2.4GHz Wi-Fi network goes down?
  • What if the SEPTA API can’t be reached—or changes completely?
  • What gets displayed when something breaks?

When everything works, the program works. But if just one thing fails, the device becomes useless until I intervene.

And that’s exactly the kind of problem endpoint engineers need to think about every day: what’s the backup plan when things don’t go as expected?

For example:

  • What if a laptop can’t connect to the VPN?
  • What if an endpoint management agent silently fails?
  • What if an app assumes connectivity that isn’t there?

Endpoint Lessons from a Tiny Gadget

To be fair, this is just a fun side project for me—it works fine right now, and it’s not worth engineering all the edge cases. But in the enterprise, these fallback methods are critical. Here’s how they’d translate:

  • Communication: The most important thing for user-facing endpoints is clarity. If something fails, explain in plain language what happened, what the system is doing to fix it, and what the user should do next if it can’t self-heal. (In my project, the device could display an error message instead of going blank.)

  • Retries: Don’t fail once and give up. Endpoints should retry automatically, often with backoff timers. Many transient issues resolve on their own. (My ESP32 could simply retry fetching bus data if the API timed out, without needing me to reboot it.)

  • Redundancy: Have a backup plan. This could mean falling back to cached data, using a secondary network, or offering reduced functionality until full service is restored.

  • Monitoring: Keep an eye out for issues. Create a dashboard where I can see all of my IoT devices in one spot with their status’. This would make it easier to spot trends, preemptively solve problems that weren’t anticipated, and administer fixes before they create roadblocks for users.

  • Fallback: Give users alternative ways to get what they need. If the device can’t fetch data, it could at least display “Check SEPTA app” instead of showing nothing, or give directions on where to find a paper copy of the schedule.

The Bigger Picture

In a perfect world, uptime is 100% and nothing breaks. But reality is messy and even the best-designed systems eventually fail.

Whether it’s a tiny IoT gadget on my desk or a fleet of thousands of enterprise laptops, failing to plan for failure is planning to fail.