Why your IoT debounce is solving the wrong problem

If you've ever built anything on top of MQTT or any event-driven IoT protocol, you've added a debounce. Probably somewhere between 3 and 10 seconds. You added it because you were getting ghost offline events — devices that appeared to drop and immediately reconnect, firing alerts that paged someone at 2am for no reason. The debounce fixed the alerts. It did not fix the problem. Here's the distinction that matters: Debounce asks: did the state change persist long enough to be real? Arbitration asks: given everything I know about this event — the timestamp, the signal quality, the sequence number, the reconnect window, the arrival order — was this state change real at all? Those are different questions. Debounce is temporal. Arbitration is logical. The failure mode debounce can't catch A device running at -89 dBm fires a state change. The reading is probably real. It might be a transmission artifact — at that signal level, a meaningful percentage of readings are noise. Your debounce wait