A discrete input is supposed to be a clean on-or-off signal, but in the field it often is not. A limit switch can bounce as its contacts close, a vibration sensor can chatter around its threshold, and a marginal wire can flicker with electrical noise, turning what should be one transition into a burst of dozens. If the gateway forwards every one of those flips, the cloud sees a storm of state changes that means nothing. Edge tag debouncing suppresses that storm by requiring a signal to hold its new state for a short time before the change is believed. This guide explains what debouncing is for discrete signals, how on-delay and off-delay filtering work, and why doing it at the edge protects the whole system.
Edge Tag Debouncing in one line: Edge tag debouncing is on-delay and off-delay filtering applied to a discrete input at the gateway so that a state change is only accepted after the signal has held its new value for a set period. It stops a chattering switch, bouncing contact, or noisy digital input from generating a flood of false transitions upstream, so the cloud receives one clean change instead of many spurious ones.
A discrete or digital input reports a binary condition: a valve is open or closed, a level is above or below a float, a door is shut or ajar. In theory it changes cleanly from one state to the other. In practice the physical world is messier. When a mechanical contact closes, its metal surfaces can bounce apart and together several times in a few milliseconds before settling, so a single closure looks electrically like a rapid series of opens and closes. This is contact bounce, and it is inherent to switches and relays.
Other sources produce the same effect over longer timescales. A limit switch mounted where a machine vibrates can be nudged repeatedly across its actuation point, flickering on and off as the equipment shakes. A sensor whose measured quantity sits right at its threshold will toggle as noise pushes the reading back and forth across the trip point. A corroded terminal or a marginal cable can inject transients that briefly pull an input to the wrong state. All of these turn one meaningful event, or no event at all, into a burst of transitions.
The trouble is that each of those transitions looks, to the acquisition system, like a real change of state worth recording and reporting. A door that was opened once can register as opened, closed, opened, closed a dozen times. A pump that started can appear to start and stop repeatedly in the moment its contactor engaged. Without filtering, every bounce becomes a data point, an event log entry, and possibly an alarm, none of which reflect what actually happened in the field.
Debouncing solves this by insisting that a new state prove itself before it is accepted. The core idea is a delay: when the input changes, the gateway does not immediately declare the change, but starts a timer and watches. Only if the signal stays in the new state for the whole delay does the gateway accept the transition and report it. If the signal flips back before the timer expires, the gateway treats the excursion as noise and discards it, so the bounces vanish and only a settled change survives.
The delay is often split into two independent values, an on-delay and an off-delay, because the two directions can warrant different treatment. The on-delay is how long the signal must stay in the active state before an off-to-on transition is believed, and the off-delay is how long it must stay inactive before an on-to-off transition is believed. Making these separately adjustable lets an engineer, for instance, confirm a running state quickly but require a longer, steadier absence of the signal before declaring the equipment stopped, which suppresses momentary dropouts.
Choosing the delays is a balance. Too short and the filter fails to catch the bounces it was meant to remove, so noise still leaks through. Too long and the system becomes sluggish, ignoring genuine changes that happen to be brief and delaying the reporting of real events. The right value is comfortably longer than the bounce or chatter being filtered but comfortably shorter than the fastest real change that must still be captured, and it is usually tuned per signal because a heavy contactor and a fast optical sensor bounce on very different timescales.
Doing this filtering at the gateway, close to the signal, is what keeps the rest of the system clean. A bounce that is suppressed at the edge never becomes a message on the network, never lands in the historian, and never raises an alarm, so the noise is stopped at its source rather than propagated and then cleaned up later. If the same chattering input were forwarded raw and filtered only in the cloud, every bounce would still consume bandwidth, storage, and event-log space on its way there, and any local logic at the site would still see the noise.
This is particularly important for event-driven telemetry and alarming. Many field systems report discrete changes as events and evaluate alarms on them, so an undebounced chattering input can generate a relentless stream of alarm and clear pairs, burying operators and desensitizing them to real trips, the classic problem of a nuisance alarm. Debouncing at the edge means an alarm is raised only when the underlying condition has genuinely and steadily changed, restoring meaning to each event that does make it upstream.
It is worth being clear that this is discrete-signal filtering, not the analog deadband used to suppress small numeric wiggles on a continuous measurement. Deadband asks whether an analog value has moved far enough to be worth reporting; debouncing asks whether a binary signal has settled long enough to be believed. In a cloud SCADA context both belong at the edge, and a platform such as Merobix is well served when its gateways debounce discrete inputs before publishing, so that the state changes reaching the cloud reflect real field events and the event history and alarm log stay trustworthy.
No. A deadband applies to a continuous analog measurement and suppresses reporting until the value has moved by more than a set amount. Debouncing applies to a discrete on-or-off signal and suppresses a state change until the signal has held its new value for a set time. One filters by magnitude of change on an analog signal, the other by duration of stability on a digital signal.
On-delay is how long a discrete input must remain in the active state before an off-to-on transition is accepted, and off-delay is how long it must remain inactive before an on-to-off transition is accepted. Splitting them lets you treat the two directions differently, for example confirming that equipment has started quickly while requiring a longer steady absence before declaring it stopped, which suppresses momentary dropouts.
Set the delay longer than the bounce or chatter you want to remove but shorter than the fastest real change you must still capture. Contact bounce settles in milliseconds, while mechanical chatter from vibration can persist longer, so the right value depends on the signal. Debounce times are usually tuned per input, because a heavy contactor and a fast sensor bounce on very different timescales.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.