ThingLogic — pipelines, rules, and alarms

ThingLogic connects TrustMint data flows to operational decisions. It provides three work areas: Pipelines, Rules, and Alarms.

ThingLogic has one model: a rule watches your data, and when it matches it routes that match to the ThingBand sinks it is bound to (notify, persist, forward, or raise an operator alarm). An alarm is simply a rule bound to the alarm-lifecycle sink — that binding is what gives the match an ack-able operator lifecycle. A rule not bound to it just delivers its match to whatever sinks it has, with no lifecycle.

Pipelines

A pipeline is a directed processing graph. It starts from an actual ThingFeed stream, applies processing nodes, and ends at an active ThingBand sink.

  1. Create the source adapter and stream in ThingFeed.

  2. Create the destination in ThingBand.

  3. In ThingLogic, choose Create pipeline, select the stream and sink, and save the draft graph.

  4. Validate the pipeline. Resolve every validation error before deployment.

  5. Deploy the pipeline. Stop it before making a structural change or deleting it.

Supported topology. Each processor runs as an independent rule against the source stream, so the supported graph is one source → one or more processors in parallel → one sink. Processor-to-processor chains, joins (two inputs into one processor) and processor fan-out (one processor feeding several targets) are refused at validation: the executor would run them as unrelated rules rather than the composition the graph appears to describe.

Rules

Rules can be enabled independently from a larger pipeline. Two kinds are available:

  • Threshold rule — watches a metric for a condition. Define the metric, operator, value, scope target, severity, cooldown, and auto-clear behavior.

  • Deadman (silence) rule — watches for missing data. It matches when no telemetry arrives in the target scope for a chosen number of seconds, and clears when telemetry resumes. Use it to catch a device that has gone quiet.

For each rule, choose the sinks its matches are delivered to. Bind the alarm-lifecycle sink when the match should raise an ack-able operator alarm (see below); bind a notification, persistence, or forwarding sink to route the match elsewhere instead of, or in addition to, an alarm.

Delete only rules that are no longer needed; deleting a rule does not erase its historical alarms.

Alarm operations

Alarms are produced by rules bound to the alarm-lifecycle sink and are managed in the Alarms tab. The alarm list shows the rule, device, severity, measured value, state, and event times. Depending on the current state, an authorized operator can:

  • Acknowledge — record that an operator owns the response.

  • Shelve — temporarily suppress active handling.

  • Resolve — close the alarm after the condition or incident is addressed.

Each transition is audited. Review the device, current state, requested action, and optional note before confirming.