A connected worker is an operator, technician or supervisor whose devices receive the right information at the moment it matters: the next work instruction, a machine alarm, a quality hold or a request for help. This article covers the connected worker use cases that deliver value on the shop floor, how to structure the MQTT topics behind them, and a working browser client that receives tasks and sends acknowledgements over secure WebSocket.
What a Connected Worker Solution Actually Does
Most frontline workers in manufacturing still learn about problems by walking past them. A machine waits for material until someone notices, a maintenance technician is called by radio, and work instructions live in a binder at the station. Connected worker solutions close that gap by bringing live plant data to people instead of people to the data.
Typical capabilities:
- Digital work instructions that change automatically with the active order or variant.
- Targeted alerts: a machine stop goes to the responsible technician's watch, not to everyone.
- Help requests and escalation: an operator taps "need material" and the request escalates if nobody accepts it within a few minutes.
- Checklists and sign-offs: start-up checks, quality checks and changeovers recorded with who and when.
- Two-way feedback: workers add reason codes, photo references or comments that flow back into the data.
The key word is real-time. A task list that refreshes every few minutes is not enough when a line stops; events must arrive within seconds.
Connected Worker Use Cases on the Shop Floor
| Use case | Event source | Who receives it | Response captured |
|---|---|---|---|
| Machine stop call | PLC state change | Line technician | Accepted, arrived, resolved |
| Material replenishment | Operator button or low-level sensor | Logistics | Accepted, delivered |
| Quality hold | Test station failure pattern | Quality engineer, line lead | Hold confirmed, released |
| Changeover instructions | MES order change | Operator at station | Each step confirmed |
| Safety or environment alert | Gas sensor, temperature limit | Everyone in an area | Acknowledged |
| Shift handover | Supervisor app | Next shift supervisor | Read confirmation |
Many of these overlap with a digital andon system; the difference is that a connected worker setup routes events to individual devices and records each person's response.
Why MQTT Fits Connected Worker Apps
Frontline devices are mobile, battery-powered and frequently on patchy Wi-Fi. MQTT's design matches that environment:
- Push, not poll. Devices hold one lightweight connection and receive events instantly, which saves battery and network compared with polling an API.
- Works in the browser. Over MQTT over WebSocket, a plain web app on a tablet can subscribe without installing anything.
- Retained messages give a device the current state (active order, open calls) the moment it reconnects.
- Persistent sessions with session expiry let a device that walks through a dead zone receive QoS 1 messages queued while it was away.
- MQTT 5 request/response with response topics and correlation data maps naturally to "task sent, task accepted".
Topic Design
Organize topics by plant area for broadcast events and by role or person for targeted tasks:
acme/plant1/assembly/line2/calls/open/<callId> retained, cleared when resolved
acme/plant1/assembly/line2/instructions/station4 retained, current instruction
acme/plant1/workers/role/maintenance/tasks tasks for anyone in a role
acme/plant1/workers/user/u1042/tasks tasks for one person
acme/plant1/workers/responses accept, arrive, resolve events
A technician's tablet subscribes to its role, its own user topic and the open calls of its area. Clearing a retained call is done by publishing an empty retained message to the same topic, which removes it from every device at once.
A Browser Client over Secure WebSocket
The example below is a minimal connected worker client with MQTT.js v5. It connects over secure WebSocket on port 8084, subscribes to open calls and personal tasks, and publishes an acceptance with the worker's ID. It runs in any modern browser bundle (Vite, webpack) after npm install mqtt.
import mqtt from "mqtt";
const prefix = "connectmq/demo/cw-4f19"; // use your own random id
const workerId = "u1042";
const clientId = `cw-${workerId}-${Math.random().toString(16).slice(2, 8)}`;
const client = mqtt.connect("wss://broker.connectmq.com:8084/mqtt", {
clientId,
protocolVersion: 5,
clean: false,
properties: { sessionExpiryInterval: 1800 }, // keep queued QoS 1 messages for 30 minutes
reconnectPeriod: 2000,
});
const openCalls = new Map();
client.on("connect", () => {
client.subscribe(
[`${prefix}/line2/calls/open/+`, `${prefix}/workers/user/${workerId}/tasks`],
{ qos: 1 }
);
});
client.on("message", (topic, payload) => {
if (topic.includes("/calls/open/")) {
const callId = topic.split("/").pop();
if (payload.length === 0) {
openCalls.delete(callId); // call resolved, retained message cleared
} else {
openCalls.set(callId, JSON.parse(payload.toString()));
}
render();
} else {
const task = JSON.parse(payload.toString());
navigator.vibrate?.(300);
console.log("New task:", task);
}
});
export function acceptCall(callId) {
client.publish(
`${prefix}/workers/responses`,
JSON.stringify({ callId, workerId, action: "ACCEPTED", ts: Date.now() }),
{ qos: 1 }
);
}
function render() {
console.table([...openCalls.entries()].map(([id, c]) => ({ id, ...c })));
}
Raise a test call from the command line and watch it appear on the device; then clear it with an empty retained message:
mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 \
-t "connectmq/demo/cw-4f19/line2/calls/open/C-001" \
-m '{"type":"MACHINE_STOP","station":"press2","reason":"jam"}'
mosquitto_pub -h broker.connectmq.com -p 1883 -i cw-plc-4f19 -r -q 1 -n \
-t "connectmq/demo/cw-4f19/line2/calls/open/C-001"
The public MQTT test broker supports QoS 0 to 2 and session expiry up to 30 minutes, which is enough to try reconnect behaviour. Remember that its public area is readable by everyone, so never send real names or plant data there.
Rollout Checklist for Connected Worker Projects
- Start with one painful process, usually machine stop calls or material calls, and measure response time before and after.
- Involve operators early. If an alert is noise to them, it will be ignored or muted.
- Route by role and area, not to everybody. Broadcasts create alert fatigue fast.
- Design escalation: if nobody accepts a call within a defined time, send it to the next level.
- Make devices recover silently. Use retained state and persistent sessions so a reconnect needs no user action.
- Use unique credentials per device or per app instance, over TLS or secure WebSocket only.
- Record responses in a database for response-time analysis and continuous improvement.
- Plan for shared devices: a shift login decides which user topic a station tablet subscribes to.
Measuring Whether It Works
A connected worker project should prove its value with numbers the plant already cares about. Because every call and response is an MQTT event, you can measure without extra effort:
- Time to accept: from the call being raised to a person accepting it.
- Time to arrive: from acceptance to the technician confirming arrival at the station.
- Time to resolve: from the call to the line running again, which ties directly to downtime.
- Escalation rate: how often calls go unanswered at the first level, a sign of under-staffing or poor routing.
- Calls per shift and per station: a recurring call at the same station is a problem to fix, not just to respond to.
Review these with the team every week during the pilot. The goal is not faster running between fires but fewer fires, so feed recurring causes into your improvement process.
Scaling Connected Worker Apps on ConnectMQ
Every tablet, watch and line display holds its own connection, so connection count grows quickly. ConnectMQ is a fully managed MQTT service that provides secure WebSocket on port 8084 with a Let's Encrypt certificate, so browser apps connect without certificate workarounds. The free Serverless plan covers a pilot of up to 25 connections, the paid Serverless plan scales to 1,000 connections with QoS 2 and shared subscriptions, and Dedicated clusters isolate larger deployments. Escalation logic and response logging run in your own services, such as a Node-RED flow or a small Node.js worker, connected as ordinary clients.
For the full plant context, see the smart manufacturing guide, and the cloud MQTT broker overview explains how a hosted broker connects plant and mobile devices securely.
Connect Your Workers with ConnectMQ
Create a free Serverless broker at app.connectmq.com with no credit card, copy the generated username, password and client ID into the browser client above and push your first live call to a tablet today.
Frequently Asked Questions
What devices can act as connected worker devices?
Tablets, smartphones, smartwatches, rugged handhelds and large line displays all work. Anything with a modern browser can use MQTT over secure WebSocket; native apps can use an MQTT library directly.
How do workers receive messages they missed while offline?
Use a persistent session with a session expiry interval and QoS 1 subscriptions, so the broker queues messages while the device is disconnected. Retained messages provide the current state on reconnect.
Should every device have its own credentials?
Yes. Unique credentials and client IDs per device or app instance make it possible to revoke a lost tablet without affecting others and to trace who sent which response.
Is a connected worker platform the same as an andon system?
They overlap. Andon makes problems visible on the line; a connected worker solution also routes tasks to specific people and records their responses.
