Building a Digital Andon System with MQTT: Calls, Escalation and Display Boards

A digital andon system turns the classic cord or lamp into a tracked, escalating call for help that reaches the right person and leaves a record of how fast the line got support. This article designs one on MQTT: how operators and machines raise calls, how call states are modelled with retained messages, how time-based escalation works, and how response-time breaches become alerts and KPIs.

What an Andon Must Do

The lean principle behind andon is simple: when a problem occurs, stop and ask for help immediately, and make the request visible so help comes quickly. A paper-and-lamp andon does the visible part. A digital andon system adds what lamps cannot:

1. Routing: a material call goes to logistics, a quality call to the quality engineer, a machine fault to maintenance.
2. Escalation: if nobody acknowledges within a set time, the call goes to the next level, such as the team leader, then the shift manager.
3. Measurement: time to acknowledge and time to resolve per call type, station and shift.
4. Visibility everywhere: line boards, supervisor tablets, the maintenance workshop and phones all show the same open calls.

Call Types and the Lifecycle

Start with a short list of call types that match your support functions:

Each call goes through the same lifecycle: open (raised), acknowledged (someone is on the way), resolved (problem fixed, line running), with an optional cancelled for mistaken calls. Escalation level increases while a call stays open or acknowledged for too long.

Designing the Digital Andon System on MQTT

MQTT suits andon well because every participant is a lightweight client: buttons, machine gateways, displays, phones and the escalation service. The broker distributes each change to everyone who needs it. If you are new to the concept, start with what an MQTT broker does.

Topic structure

connectmq/plant1/assembly/line1/st-30/andon/material      retained: current call state for this type
connectmq/plant1/assembly/line1/st-30/andon/maintenance   retained
connectmq/plant1/assembly/line1/st-30/andon/events        not retained: every transition
connectmq/plant1/assembly/line1/andon/summary             retained: open calls on the line

One retained topic per station and call type means a display that powers on mid-shift immediately shows every open call. An empty or resolved payload means no active call.

Call payload

{
  "id": "st30-mat-1760600000",
  "type": "material",
  "state": "open",
  "level": 0,
  "opened": 1760600000,
  "acknowledged": null,
  "resolved": null,
  "by": "operator-panel-st30",
  "note": "Screws M4x10"
}

Timestamps for each transition make response times trivial to compute later, and level tells boards how to colour the call.

Raising, Acknowledging and Resolving Calls

Call sources publish the retained state. Operator buttons can be ESP32 boards with large illuminated push buttons, an HMI screen or a tablet web app; machines raise maintenance calls automatically from fault states in machine status monitoring. The examples below simulate the three steps from a terminal on the public test broker:

T=connectmq/demo/andon-6h4v/line1/st-30/andon/material
OPENED=$(date +%s)

# Operator raises a call
mosquitto_pub -h broker.connectmq.com -p 1883 -i andon-op-$RANDOM -q 1 -r -t $T \
  -m "{\"id\":\"st30-mat-1\",\"type\":\"material\",\"state\":\"open\",\"level\":0,\"opened\":$OPENED}"

# Material handler acknowledges
mosquitto_pub -h broker.connectmq.com -p 1883 -i andon-ack-$RANDOM -q 1 -r -t $T \
  -m "{\"id\":\"st30-mat-1\",\"type\":\"material\",\"state\":\"acknowledged\",\"level\":0,\"opened\":$OPENED,\"acknowledged\":$(date +%s)}"

# Call resolved
mosquitto_pub -h broker.connectmq.com -p 1883 -i andon-res-$RANDOM -q 1 -r -t $T \
  -m "{\"id\":\"st30-mat-1\",\"type\":\"material\",\"state\":\"resolved\",\"opened\":$OPENED,\"resolved\":$(date +%s)}"

A real responder app reads the retained call, updates the fields and republishes the complete object. Because the topic is per station and type, concurrent calls of different types never overwrite each other.

The Escalation Service

Escalation is a small service that subscribes to all andon topics, tracks open calls, raises the level when time limits pass, and publishes the open duration so alerts can fire. Here it is with MQTT.js and MQTT 5:

// andon-escalation.mjs  -  npm install mqtt
import mqtt from "mqtt";

const prefix = "connectmq/demo/andon-6h4v/line1";
const limits = {                        // seconds until next level, per call type
  material:    [180, 600, 1200],
  maintenance: [300, 900, 1800],
  quality:     [300, 900],
  help:        [120, 600],
  safety:      [0, 60],
};

const client = mqtt.connect("mqtts://broker.connectmq.com:8883", {
  clientId: "andon-esc-6h4v",
  protocolVersion: 5,
});
const calls = new Map();                // topic -> call object

client.on("connect", () => client.subscribe(`${prefix}/+/andon/+`, { qos: 1 }));

client.on("message", (topic, buf) => {
  if (topic.endsWith("/events")) return;
  const text = buf.toString();
  if (!text) { calls.delete(topic); return; }
  const call = JSON.parse(text);
  if (call.state === "resolved" || call.state === "cancelled") {
    if (!calls.delete(topic)) return;      // ignore stale retained resolutions
    const station = topic.split("/").at(-3);
    client.publish(topic.replace(/[^/]+$/, "events"), JSON.stringify({ ...call, station }), { qos: 1 });
  } else {
    calls.set(topic, call);
  }
  publishSummary();
});

function publishSummary() {
  const open = [...calls.entries()].map(([t, c]) => ({
    station: t.split("/").at(-3), type: c.type, state: c.state, level: c.level ?? 0,
    open_s: Math.round(Date.now() / 1000 - c.opened),
  }));
  const maxOpen = open.reduce((m, c) => Math.max(m, c.open_s), 0);
  client.publish(`${prefix}/andon/summary`,
    JSON.stringify({ ts: Math.round(Date.now() / 1000), open_calls: open.length, max_open_s: maxOpen, calls: open }),
    { qos: 1, retain: true });
}

setInterval(() => {
  const now = Date.now() / 1000;
  for (const [topic, call] of calls) {
    const steps = limits[call.type] ?? [300];
    const age = now - call.opened;
    const level = steps.filter((s) => age >= s).length;
    if (level > (call.level ?? 0)) {
      call.level = level;
      client.publish(topic, JSON.stringify(call), { qos: 1, retain: true });
      console.log(`escalated ${call.type} at ${topic} to level ${level}`);
    }
  }
  publishSummary();
}, 10_000);

The service republishes the retained call with a higher level, so every board changes colour at the same time, and it publishes a retained line summary with max_open_s, the age of the oldest open call. Resolved calls are copied to the events topic, where a historian picks them up for reporting. When a resolved message arrives, the service stops tracking the call so the summary drops back, and it ignores old retained resolutions it receives after a restart.

Run it close to the line or in the cloud; it only needs network access to the broker. For redundancy, two instances can share the work using MQTT 5 shared subscriptions, which are available on ConnectMQ's paid Serverless and higher plans.

Response-Time Alerts

The summary topic makes response-time breaches easy to catch without more code. In the ConnectMQ portal, create a threshold alert rule on the max_open_s field of .../andon/summary, for example "greater than 900", and every breach lands in the alerts log with its time and value. Supervisors can review the log at the end of each shift. To push notifications to phones, chat or a siren, connect Node-RED or another small subscriber to the broker and forward the events; the MQTT threshold alerts guide walks through that pattern.

Display Boards

Andon boards are simply subscribers. A browser on a wall-mounted screen connects over secure WebSocket (wss://broker.connectmq.com:8084/mqtt), subscribes to the line's andon topics and the summary, and renders stations as tiles: green when no call, yellow for an open call, orange for acknowledged, red when escalated. Because all states are retained, a board that reboots recovers its full picture within a second. The same data can be one panel of a broader production line monitoring dashboard.

Andon KPIs Worth Tracking

Link andon events with downtime reason codes so that the time a station waited for material is classified consistently in availability losses.

Rollout Checklist

1. Agree call types, responders and escalation times with production, logistics, maintenance and quality.
2. Pilot on one line with simple buttons and one board.
3. Make acknowledging easy: a single tap on a phone or a button at the responder's location.
4. Review KPIs weekly and adjust escalation times to realistic targets.
5. Expand to other lines with the same topic structure; boards and services work unchanged.

Infrastructure for a Plant-Wide Andon

An andon that goes silent erodes trust quickly, so the broker must be available every shift. A managed MQTT broker removes server maintenance from the picture, and a cloud MQTT broker lets supervisors receive calls on mobile devices outside the plant network without opening firewall ports. For the wider context, see the smart manufacturing guide.

Build Your Andon on ConnectMQ

ConnectMQ provides MQTT 5 over TLS and secure WebSocket, retained messages, a live topic explorer, threshold alert rules with an alerts log, and an ISA-95 devices view. Create a free Serverless broker, no credit card needed, and pilot your digital andon system on one line this week.

Frequently Asked Questions

What is a digital andon system?

It is an electronic version of the lean andon that lets operators and machines raise calls for help, routes them to the right responders, escalates them when unanswered and records response and resolution times.

Why use MQTT for andon?

MQTT delivers state changes instantly to every display, phone and service, works with low-power buttons and browsers alike, and retained messages let any screen recover the current open calls immediately after starting.

How does escalation work without a rule engine in the broker?

A small service subscribes to call topics, compares call age with escalation limits and republishes calls with a higher level. ConnectMQ threshold alerts then record breaches of the overall response-time limit.

Can andon calls be raised automatically by machines?

Yes. An edge gateway that monitors machine faults can publish a maintenance call to the station's andon topic when a machine goes down, using the same payload as a manual call.