The afternoon rule: if the ESP32 build doesn’t fix something by tonight, don’t build it

Most hardware projects die of ambition, not difficulty

Look in any maker’s drawer and you’ll find the fossils: the ambitious build that was going to do everything, got 70% finished over three weekends, and now powers nothing. The lesson I’ve slowly accepted — and that a lovely XDA piece on afternoon-scale ESP32 builds states better than I have — is that the projects which survive aren’t the cleverest. They’re the ones that fix a real annoyance before bed.

Call it the afternoon rule: if a build can’t remove a genuine, current annoyance by tonight, it’s a solution to a hypothetical problem, and hypothetical problems are how drawers fill up.

What struck me reading that piece wasn’t the five builds themselves — a knock sensor identifying which door, a reed switch on the garage, a vibration sensor announcing the laundry, Bluetooth proxies locating lost headphones, a particulate sensor driving an air purifier. It’s that all five reduce to the same three-stage pattern, and the pattern is the part worth stealing:

• Sense. One cheap sensor on one cheap board, reporting one fact.
• Threshold. A rule that turns the raw reading into an event worth knowing about.
• Notify. A push to the phone of whoever is actually bothered by the problem.

That’s it. No dashboard redesign, no “platform play”, no graphing every metric because the graphing library looks nice. One annoyance, one signal, one notification.

The quality lives in the threshold

Here’s the detail that separates a build you forget about from a build you turn off in week two: the debounce. The laundry example is perfect — a vibration sensor taped to a washing machine can’t just alert “no vibration”, because washers go quiet between spin and fill. Alert fires mid-cycle, everyone learns to ignore it, the build is dead. A three-minute quiet buffer changes it from noise into signal.

The same thinking applies everywhere:

• A garage door sensor that alerts instantly will nag during a two-minute unloading. Alert on open for more than five minutes.
• A door sensor that triggers on any vibration will fire in a storm. Require a pattern, or a sustained event.
• A temperature alarm needs hysteresis, or it flaps around the threshold all afternoon.

In Home Assistant the whole pattern is a few lines, which is precisely why it clears the afternoon bar:

automation:
  - alias: "Washer finished"
    trigger:
      - platform: state
        entity_id: binary_sensor.washer_vibration
        to: "off"
        for: "00:03:00"
    action:
      - service: notify.mobile_app_garys_phone
        data:
          message: "Washer's done — go rescue the laundry"

And the sensor side is an ESPHome config file, not firmware development — YAML you can keep in git next to your compose files, redeploy onto a replacement board in minutes when one eventually dies.

The rule works double duty in a lab or small business

The pattern scales past the house. The same sense → threshold → notify shape, pointed at infrastructure instead of appliances, is most of what a small operation needs from monitoring:

• A reed switch on the server room or comms-closet door, alerting on open-for-more-than-a-minute. Cheap, dumb, and it will catch the contractor who “just checked something” at 6pm.
• A water sensor under the rack or the air-con drip tray. One of the least glamorous boards you’ll ever flash, and one of the few that can pay for the entire drawer.
• A temperature sensor near the switch stack in the cupboard with the closing door and no ventilation, alerting before the gear throttles rather than after it reboots.

None of these need dashboards on a wall. They need a push notification at the moment a fact changes, which is what the afternoon pattern delivers.

Know when to break the rule

Two honest caveats. First, anything involving mains wiring — doorbell circuits, HVAC control, the purifier’s power — moves out of “afternoon” territory the moment you open the case. A relay on the bench is a learning project; a relay inside a machine that’s plugged into the wall is an electrical decision. Use proper isolation, or stay on the sensing side and let the notification land with a human.

Second, safety-critical is out of scope entirely. The rule is for annoyances, and it works because annoyances are cheap to be wrong about. A false “garage open” is a shrug; a sensor trusted to fire a safety alert is a different class of engineering. Keep the two firmly separate.

But within those limits, the rule is the best scope-creep defence I know. The board costs five dollars, the sensor costs two, and the question isn’t “what could this become?” — it’s “what annoyance does this kill by tonight?” Answer the second question first, and the drawer stays a toolbox instead of a museum.