Talk MQTT to Me

MQTT is one of those acronyms that can make a perfectly normal product conversation sound like it is about to become homework. I promise this is not a packet-size seminar.

The question I care about is simpler: why did we choose it, and why should anyone managing printers care?

After about 15 years working in EMM and MDM, I have learned that "just build one more integration" is rarely just one more anything. It becomes design, testing, deployment, scale planning, support, and something you now get to maintain for years.

The connector treadmill

Connectors solve real compatibility problems. I spent Episode 2 calling them the boogeyman, but I also explained why they still matter for long-lived printer fleets.

The problem is repetition. Every new manufacturer can begin to feel like its own small product: understand the interface, build the bridge, test it, deploy it, work out how it scales, and then support it for as long as those printers remain in the field.

Then do it again.

Do that often enough and the integration method starts choosing the roadmap for you. I would rather the customer problem choose the roadmap.

MQTT gives a supported device and the management platform a common way to exchange messages. It lets us begin with a better question: does this device support the communication model we have standardized on?

That does not eliminate the engineering. It just means we do not have to introduce ourselves to every new device by rebuilding the plumbing from zero.

MQTT is not magic dust

A device does not become manageable simply because it can say hello over MQTT.

The protocol does not decide which capabilities the device exposes, what its telemetry means, which commands are safe, who is allowed to send them, or what should happen when something fails. Device models, permissions, security, lifecycle behavior, errors, and sometimes translation or APIs above the protocol still need real product work.

The whiteboard version is wonderfully simple: the platform publishes a message and the device responds. Two boxes, a couple of arrows, everyone goes home happy.

The actual product begins after those arrows.

MQTT can remove one repeated layer of integration work. It cannot decide what every printer, sensor, display, access-control device, or RFID reader should be able to do.

Printers have to prove it first

Printers are the immediate job. Before this foundation earns us a conversation about anything broader, it has to be useful for real printer fleets.

I use RFID sleds in the episode as one example of what could sit nearby. Sensors, displays, and access-control hardware raise the same possibility: perhaps we can examine another frontline category without inventing an entirely separate communication path first.

That is a direction, not a support claim. An MQTT radio or client does not turn a device into a shipping Workspace ONE integration. Current product and manufacturer documentation still decides what is actually supported.

Exact scale limits also depend on the product version and deployment. My broader concern is what happens when a connector instance becomes the unit of scale. Its ceiling eventually becomes the administrator's problem, which is architecture showing up in somebody else's workday.

MQTT is not the product. If we do this well, most administrators should rarely need to say MQTT. They should be able to say: the printer enrolled, the data arrived, and the action worked.

Plumbing should be boring. Rebuilding it for every manufacturer is not.

Until we talk again, take care.