Skip to content
Meddle Docs

On Change Connector

Overview

Section titled “Overview”

The On Change connector forwards a payload only when at least one of its monitored fields differs from the last observed value. It is the standard tool for collapsing chatty streams that repeat the same readings unchanged.

Connector Type: MeddleOnChange

Any Mode

Section titled “Any Mode”

Emit when any monitored key changes since the previous payload.

{
  "type": "MeddleOnChange",
  "config": {
    "keys": ["temperature", "pressure"],
    "mode": "any",
    "tolerance": 0.1,
    "emitFirst": true
  }
}

If either temperature or pressure differs by more than 0.1, the payload is emitted.

All Mode

Section titled “All Mode”

Emit only when every monitored key is present in the payload and every one of them has changed.

{
  "type": "MeddleOnChange",
  "config": {
    "keys": ["x", "y", "z"],
    "mode": "all",
    "tolerance": 0,
    "emitFirst": false
  }
}

Useful when payloads carry an atomic snapshot and a partial change should not propagate.

Configuration Parameters

Section titled “Configuration Parameters”
  • keys (required, unique): Array of payload keys to monitor
  • mode (required): any (emit when at least one key changes) or all (emit only when all keys change)
  • tolerance: Absolute tolerance for numeric comparisons (default 0). Two numbers are considered equal when |a - b| <= tolerance.
  • emitFirst: When true, the first observed payload is emitted (and seeds the baseline). When false, the first payload is consumed silently.

Comparison Semantics

Section titled “Comparison Semantics”
  • Numeric values are coerced to float64 and compared with the configured tolerance
  • Non-numeric values use strict equality
  • Keys absent from a payload do not count as changes and do not update the baseline
  • The baseline is updated for every key present in the incoming payload, regardless of whether it caused an emission

Use Cases

Section titled “Use Cases”
  1. Reduce MQTT/Kafka traffic by dropping repeated identical telemetry
  2. Edge-of-state detection for status fields (e.g. only forward when status flips)
  3. Throttle storage writes to a time-series database
  4. Tolerance-based debouncing of noisy analog readings

Example: Status Change Forwarding

Section titled “Example: Status Change Forwarding”
{
  "type": "MeddleOnChange",
  "config": {
    "keys": ["status"],
    "mode": "any",
    "tolerance": 0,
    "emitFirst": true
  }
}

Only payloads where status differs from the previous observation propagate downstream, regardless of how often the source publishes.

Example: Tolerance on Analog Sensors

Section titled “Example: Tolerance on Analog Sensors”
{
  "type": "MeddleOnChange",
  "config": {
    "keys": ["temperature"],
    "mode": "any",
    "tolerance": 0.5,
    "emitFirst": true
  }
}

Sensor noise within ±0.5 is ignored; only real movement triggers a downstream emission.

Best Practices

Section titled “Best Practices”
  • Set tolerance slightly above the sensor’s known jitter to suppress noise without missing real transitions
  • Use mode: "all" only when payloads truly contain coherent snapshots; otherwise any is the safer default
  • Combine with Aggregation when you also need periodic summaries of the deduplicated stream
  • Keep the keys list small — every monitored key costs one comparison per payload
Section titled “Related Connectors”