Every plant network has an MQTT broker. Maybe Mosquitto on a Linux server in the rack, maybe HiveMQ Enterprise on dedicated hardware, maybe a managed broker like AWS IoT Core or HiveMQ Cloud. The broker is the backbone of every IIoT, SCADA, and MES integration on the floor. The OPC-UA gateway publishes there. The motor drives publish there. The Andon HMIs subscribe. The MES writes back to plant/line-3/cmd/*.
If the broker is the backbone, the label printer needs to be on it. The LabelInn Edge Server publishes print job events and printer telemetry to your broker, and subscribes to a small set of command topics that let any MES, SCADA, or ERP trigger a label without touching our REST or gRPC surfaces. Pure pub-sub. Standard QoS. TLS. Same broker you already run.
The topic catalog
Under a configurable prefix (default labelinn/), the edge node uses these topics:
Outbound — events you subscribe to
labelinn/print/job_submitted— a job has been accepted; payload includes job id, printer id, template id, copies, operator identitylabelinn/print/job_completed— the job finished printing; payload adds duration, label count actually printed, the verification verdict if applicablelabelinn/print/job_failed— the job failed; payload adds the failure reason and the printer state at the time of failurelabelinn/printer/online— a printer came online (boot, reconnection)labelinn/printer/offline— a printer went offlinelabelinn/printer/error— a printer reports an error (head open, label out, ribbon out, mechanical fault); payload includes the error code from the printer's native protocollabelinn/printer/supply— a printer's supply level changed (ribbon %, labels %); rate-limited to avoid topic spamlabelinn/verify/passed— a scan-to-verify operation succeeded; payload includes the job id and the scanned barcodelabelinn/verify/failed— a scan-to-verify operation failed; payload includes the expected vs. observed barcode
Inbound — commands the edge node listens for
labelinn/cmd/print— submit a print job by publishing a typed payload; receive the resulting job id on a correlated response topiclabelinn/cmd/cancel— cancel a queued or in-progress joblabelinn/cmd/status— request the current status of a job
Choosing QoS — the three trade-offs that actually matter
The MQTT QoS levels (0, 1, 2) trade delivery guarantees for broker overhead. The defaults we recommend per topic class:
| Topic class | Recommended QoS | Why |
|---|---|---|
| Printer supply / telemetry | 0 (at most once) | The next reading supersedes it. Losing one update is fine. |
| Job submitted / completed / failed | 1 (at least once) | Idempotent on the consumer (deduplicate by job id). One duplicate is cheap; missing an event is expensive. |
Compliance-critical: verify/passed, verify/failed | 2 (exactly once) | The Quality system must record this once and only once. Worth the broker round trips. |
Inbound commands cmd/print | 1 (at least once) | The edge node deduplicates by idempotency key in the payload. |
Two worked examples
SCADA dashboard subscribes to printer/error
The plant has six packaging lines, each with a thermal printer. The SCADA HMI (Ignition Perspective in this example) displays a live tile per line: green when the printer is online and healthy, amber on a soft warning (low ribbon, low labels), red on a hard error (head open, no media). Each tile subscribes to labelinn/printer/error/line-N and labelinn/printer/supply/line-N via the Ignition MQTT Engine module. Tile color is a tag binding on the latest payload's severity field. The operator on line 3 sees the indicator turn amber when ribbon drops below 15% and replaces it during the next pallet swap, not at the next jam.
MES publishes to cmd/print
The MES executes a work order step that says "print 240 unit-level UDI labels on line 5's primary printer." The MES publishes a single payload to labelinn/cmd/print containing the design id, the data source (a list of 240 serial numbers from the serialization pool), the target printer id, and an idempotency key derived from the work-order-step id. The edge node receives, validates, queues, prints, and publishes 240 job_completed events back. The MES subscribes and reconciles against the work order. The work-order step closes when the MES has counted 240 completions tagged with its idempotency key. A network hiccup that causes the inbound command to be republished does not produce 480 labels: the idempotency key dedupes at the edge node.
TLS, authentication, broker portability
For brokers running TLS, the edge node trusts the customer's CA chain and authenticates with a client certificate or a username/password pair scoped to the LabelInn topic prefix. Connection parameters (broker host, port, client id, last-will topic, keepalive) are configured per tenant. The same edge node can connect to a different broker after a configuration push without a reinstall — useful during a migration from on-prem Mosquitto to a managed HiveMQ instance.
Topic prefix is configurable so multiple LabelInn deployments on the same broker (multi-tenant brokers, shared customer environments) don't collide. Each tenant's events live under their own prefix; the broker's ACL list enforces isolation.
What this saves you
If your plant already has an MQTT broker, integrating label printing is a configuration exercise on the broker side and a topic subscription on the consumer side. There is no new transport to introduce to your security review. There is no new authentication scheme to add to your IdP. There is no new firewall rule for a new port — the edge node makes an outbound TCP connection to the broker the same way every other publisher on the plant does.
The integration goes from "specify a REST integration, write a polling loop, debug auth, get sign-off from security" to "subscribe to labelinn/print/job_completed in your existing MQTT client and you're done."
Put Label Printing on the Bus You Already Run
Request the full topic catalog and a sample broker config (Mosquitto, HiveMQ, AWS IoT Core) tuned to your plant's segmentation.
Request the topic catalog →