On Change-Konnektor

Übersicht

Der On Change-Konnektor leitet eine Payload nur dann weiter, wenn mindestens eines seiner überwachten Felder vom zuletzt beobachteten Wert abweicht. Es ist das Standardwerkzeug, um geschwätzige Streams zu kollabieren, die dieselben Messwerte unverändert wiederholen.

Konnektor-Typ: MeddleOnChange

Any-Modus

Ausgeben, wenn sich irgendein überwachter Schlüssel seit der vorherigen Payload geändert hat.

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

Wenn entweder temperature oder pressure um mehr als 0.1 abweicht, wird die Payload ausgegeben.

All-Modus

Nur ausgeben, wenn jeder überwachte Schlüssel in der Payload vorhanden ist und sich jeder einzelne von ihnen geändert hat.

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

Nützlich, wenn Payloads einen atomaren Snapshot tragen und eine partielle Änderung sich nicht ausbreiten soll.

Konfigurationsparameter

keys (erforderlich, eindeutig): Array von zu überwachenden Payload-Schlüsseln
mode (erforderlich): any (ausgeben, wenn sich mindestens ein Schlüssel ändert) oder all (nur ausgeben, wenn sich alle Schlüssel ändern)
tolerance: Absolute Toleranz für numerische Vergleiche (Standard 0). Zwei Zahlen gelten als gleich, wenn |a - b| <= tolerance.
emitFirst: Bei true wird die erste beobachtete Payload ausgegeben (und etabliert die Baseline). Bei false wird die erste Payload still konsumiert.

Vergleichssemantik

Numerische Werte werden in float64 konvertiert und mit der konfigurierten Toleranz verglichen
Nicht-numerische Werte verwenden strikte Gleichheit
Schlüssel, die in einer Payload fehlen, zählen nicht als Änderungen und aktualisieren die Baseline nicht
Die Baseline wird für jeden in der eingehenden Payload vorhandenen Schlüssel aktualisiert, unabhängig davon, ob er eine Ausgabe ausgelöst hat

Anwendungsfälle

MQTT-/Kafka-Verkehr reduzieren durch Verwerfen wiederholter identischer Telemetrie
Edge-of-State-Erkennung für Statusfelder (z.B. nur weiterleiten, wenn status umschaltet)
Speicher-Schreibvorgänge in eine Zeitreihendatenbank drosseln
Toleranzbasiertes Debouncing verrauschter analoger Messwerte

Beispiel: Status-Änderungs-Weiterleitung

{
  "type": "MeddleOnChange",
  "config": {
    "keys": ["status"],
    "mode": "any",
    "tolerance": 0,
    "emitFirst": true
  }
}

Nur Payloads, bei denen sich status von der vorherigen Beobachtung unterscheidet, werden nachgelagert weitergegeben, unabhängig davon, wie oft die Quelle veröffentlicht.

Beispiel: Toleranz bei Analogsensoren

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

Sensorrauschen innerhalb von ±0,5 wird ignoriert; nur echte Bewegung löst eine nachgelagerte Ausgabe aus.

Best Practices

Setzen Sie tolerance knapp über dem bekannten Jitter des Sensors, um Rauschen zu unterdrücken, ohne echte Übergänge zu verpassen
Verwenden Sie mode: "all" nur, wenn Payloads wirklich kohärente Snapshots enthalten; andernfalls ist any der sicherere Standard
Kombinieren Sie mit Aggregation, wenn Sie auch periodische Zusammenfassungen des deduplizierten Streams benötigen
Halten Sie die keys-Liste klein — jeder überwachte Schlüssel kostet einen Vergleich pro Payload