MQTT Sparkplug B: why I stopped writing point-to-point integrations

Point-to-point integrations scale quadratically. With six sources and four consumers, one PLC change becomes an afternoon spread across several teams.

What Sparkplug B actually solves

Over plain MQTT, Sparkplug B solves two concrete things:

• It defines the payload format. No more one bespoke JSON per integrator. Typed metrics, with timestamps and aliases.
• It defines device lifecycle. With NBIRTH / DBIRTH and the last will message, the consumer stops guessing whether silence means "no change" or "the gateway died".

That second point has saved more shifts than the first. A historian that cannot tell "steady" from "disconnected" produces averages that lie very convincingly.

The migration

The migration was not big bang. I published in parallel for six weeks, compared both paths, and only then turned the old one off. That overlap is non-negotiable in production.

The cutover criterion was measurable: zero divergence between both paths across two full weeks, including a planned maintenance window and a real network outage.

What it does not solve

Sparkplug does not give you a business data model. It gives you an orderly transport. Line, shift, order and product are still your work — and still the part that decides whether the project is useful.