Skip to content
Meddle Docs

Router Connector

Overview

Section titled “Overview”

The Router connector evaluates a list of MXL conditions against each incoming payload and emits the payload tagged with the first matching route. Use it to split a single stream into multiple logical channels that downstream connectors can branch on.

Connector Type: MeddleRouter

Configuration

Section titled “Configuration”
{
  "type": "MeddleRouter",
  "config": {
    "routes": [
      { "condition": "temperature > 80", "tag": "critical" },
      { "condition": "temperature > 50", "tag": "warning" },
      { "condition": "temperature <= 50", "tag": "normal" }
    ],
    "defaultTag": "unknown"
  }
}

The connector evaluates routes top-to-bottom. The first one whose condition evaluates to true wins; its tag is written to the payload under the reserved key _route.

Output

Section titled “Output”

Every matched payload is augmented with a _route field:

{
  "temperature": 92.5,
  "sensor_id": "S-01",
  "_route": "critical"
}

Downstream connectors (Filter, Trigger, Notification, etc.) can branch on _route to send each tag to a different destination.

Configuration Parameters

Section titled “Configuration Parameters”
  • routes (required, min 1): Ordered array of route definitions. Each route has:
    • condition (required): An MXL expression evaluated against the payload
    • tag (required): String written to _route when the condition matches
  • defaultTag: Optional tag applied when no route matches. If unset and no route matches, the payload is dropped and an error is emitted.

MXL Expressions

Section titled “MXL Expressions”

Routes use MXL (Meddle Expression Language) — the same expression syntax used by Trigger and Alert.

temperature > 80
status == "active" && pressure < 10
humidity >= 60 || temperature > 25
count != 0

Conditions are parsed at startup; invalid MXL prevents the connector from starting.

Use Cases

Section titled “Use Cases”
  1. Severity-based routing — split telemetry into normal / warning / critical streams
  2. Multi-tenant fan-out — tag payloads by site, customer, or device class
  3. Workflow branching — direct different payload shapes to different downstream pipelines
  4. A/B routing — send a subset of traffic to an experimental processor

Example: Multi-Site Routing

Section titled “Example: Multi-Site Routing”
{
  "type": "MeddleRouter",
  "config": {
    "routes": [
      { "condition": "site_id == \"plant-a\"", "tag": "plant_a" },
      { "condition": "site_id == \"plant-b\"", "tag": "plant_b" },
      { "condition": "site_id == \"plant-c\"", "tag": "plant_c" }
    ],
    "defaultTag": "unassigned"
  }
}

Each payload is tagged with its origin site, and any payload without a recognised site_id falls into the unassigned channel.

Example: Severity Triage

Section titled “Example: Severity Triage”
{
  "type": "MeddleRouter",
  "config": {
    "routes": [
      { "condition": "vibration > 5.0 || temperature > 100", "tag": "critical" },
      { "condition": "vibration > 2.0 || temperature > 70",  "tag": "warning" },
      { "condition": "true",                                  "tag": "normal" }
    ]
  }
}

A true condition as the last entry acts as an implicit default. The _route field can then drive Notification (critical -> Slack, warning -> email) or Filter (normal -> drop).

Best Practices

Section titled “Best Practices”
  • Order routes from most specific to most general; only the first match wins
  • Use defaultTag to guarantee every payload exits the connector — otherwise unmatched payloads become errors
  • Keep MXL conditions side-effect free and based on payload fields the upstream is guaranteed to populate
  • Avoid overlapping routes that depend on order alone — explicit conditions are easier to maintain
  • Downstream Filter or Trigger connectors should branch on _route rather than re-evaluating the same MXL
Section titled “Related Connectors”