Skip to content
Proxus 2.0.0 Proxus 2.0: the largest release in Proxus history Release notes
Try free Book a demo

Integrations · MQTT & Sparkplug B

MQTT in both directions, Sparkplug B included.

Proxus uses MQTT three ways. Each gateway runs a built-in broker that publishes the Unified Namespace as topics, in JSON or Sparkplug B 3.0, for your applications to subscribe to. Devices can publish their own values to that broker. And an outbound target publishes readings to the broker you already run, in plain MQTT or Sparkplug B.

Book a demo All integrations Setup guide
Equipment to MQTT & Sparkplug B MQTT
Model once, deliver to your systems Equipment sends data through an edge gateway to Unified Namespace, then to MQTT & Sparkplug B. This integration can also act as a source. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals 02 / EDGE Proxus Edge Collect / evaluate / buffer 03 / PLATFORM Unified Namespace Modelled industrial signals MQTT & Sparkplug B Source + destination 01 / PLANT FLOOR04 / CONSUMERS Model once, deliver to your systems Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Unified Namespace, then to MQTT & Sparkplug B. This integration can also act as a source. 01 Plant floor PLCs / CNCs / robots 02 Proxus Edge Collect / evaluate /buffer 03 Unified Namespace Modelled industrialsignals 04 MQTT & Sparkplug B Source + destination
Subscribe
Each gateway’s built-in broker publishes the namespace as topics, each value with its unit and read time
Publish
To your broker: the MQTT target (one topic you choose) or the Sparkplug B target
Collect
Devices publish JSON to the built-in broker, signed in with their device token
Reliability
Edge buffering when your broker is unavailable

Data path

What actually moves, and where it stops.

Also works in reverse: devices publish to the gateway’s built-in broker as a source

Model once, deliver to your systems Equipment sends data through an edge gateway to Unified Namespace, then to MQTT & Sparkplug B. This integration can also act as a source. Controllers S7 / CIP / MELSEC Machines & robots FOCAS / MTConnect Meters & SCADA Modbus / OPC UA Modelled signals 02 / EDGE Proxus Edge Collect / evaluate / buffer 03 / PLATFORM Unified Namespace Modelled industrial signals MQTT & Sparkplug B Source + destination 01 / PLANT FLOOR04 / CONSUMERS Model once, deliver to your systems Read from bottom to top. Field equipment is at the bottom and data travels upward. Equipment sends data through an edge gateway to Unified Namespace, then to MQTT & Sparkplug B. This integration can also act as a source. 01 Plant floor PLCs / CNCs / robots 02 Proxus Edge Collect / evaluate /buffer 03 Unified Namespace Modelled industrialsignals 04 MQTT & Sparkplug B Source + destination

Field

  • PLCs, CNCs, robots
  • OPC UA servers
  • Meters and SCADA

Proxus

  • Collect at the line
  • Model into the namespace
  • Buffer and forward

MQTT & Sparkplug B

MQTT
  • topic namespace
  • Sparkplug B payload
  • existing subscribers

How it works

From the machine to MQTT & Sparkplug B, in four steps.

  1. 01

    Bring MQTT devices in

    A device signs in to the gateway’s built-in broker with its device token and publishes JSON to the telemetry topic; each field becomes a tag.

  2. 02

    Collect the rest

    Equipment that speaks other protocols is read with native drivers and placed in the same namespace.

  3. 03

    Subscribe to the namespace

    Applications subscribe to v1/# on the built-in broker, or to one site or device, in JSON or Sparkplug B 3.0.

  4. 04

    Publish outward

    An MQTT target sends each reading to one topic you choose on your broker; a Sparkplug B target publishes under your Group ID and Edge Node ID.

What you get

Why teams route MQTT & Sparkplug B through Proxus.

  • Works with what you have

    Your existing broker keeps its place in the architecture, as the target Proxus publishes to.

  • Topics that mean something

    On the built-in broker, topics follow the namespace: enterprise, site, area, line or cell, equipment, device, tag.

  • Bridge two worlds

    MQTT-native equipment and polled controllers end up in the same namespace.

  • Retained state topics

    Every new subscriber learns each device’s status (Online, Offline or Timeout) at once.

Where it is used

Typical deployments.

  • Unified Namespace over MQTT

    Let other applications subscribe to the namespace on the gateway’s built-in broker.

  • Sparkplug B for consumers

    Switch the built-in broker to Sparkplug B 3.0, or publish to your own broker with the Sparkplug B target.

  • Bridging sites

    Send readings from site to centre over MQTT, buffered at the gateway while the link is down.

Roles
Built-in broker (subscribe to the namespace; devices publish their own values) and target (publish to your broker)
Payloads
Built-in broker: JSON or Sparkplug B 3.0. MQTT target: each reading as JSON to one topic (proxus_device_data by default). Sparkplug B target: under the Group ID and Edge Node ID you set
Topics
Built-in broker: v1/<Enterprise>/<Site>/…/<Device>/telemetry/<tag>, plus a retained state/_status per device
Security
TLS on the built-in broker (port 8883); clients sign in with the gateway’s master token or a device token. The broker has no per-topic rights
You configure
MQTT: BrokerHost, BrokerPort, Topic, Username, Password, UseTls. SparkplugB: BrokerHost, GroupId, EdgeNodeId. Test Connection checks the address and credentials from the hub or from a gateway you choose, without writing data.
Setup guide All target parameters

Proven in production

Running in production at these plants.

All deployments

Questions

Before you wire it up.

Can Proxus both read from and write to MQTT?
Yes. Devices can publish their own values to the broker built into each gateway, and your applications can subscribe there to the namespace. As a target, Proxus publishes readings to your broker in plain MQTT or Sparkplug B. Devices publish JSON; Proxus does not read Sparkplug B from them.
Do we need to restructure our existing topics?
Devices publish JSON to the gateway’s built-in broker on the telemetry topic, signed in with their device token; each field becomes a tag. Proxus does not subscribe to an external broker in this release, so devices that publish elsewhere today are pointed at the gateway’s broker.
Which broker do we use?
For delivery, yours: Proxus publishes to the broker you already run. For collecting from devices and subscribing to the namespace, the broker built into each gateway.
Is Sparkplug B required for a Unified Namespace?
No. The built-in broker publishes the namespace as JSON by default; Sparkplug B 3.0 is a setting on the gateway. The namespace model matters more than the payload format.

Other integrations

Connection guides

Set it up step by step.

All connection guides

Next step

See it delivering into your own MQTT & Sparkplug B.

Bring one machine and your broker. We connect the machine, show its values on the gateway’s built-in broker, and publish them to yours in plain MQTT or Sparkplug B.

Book a demo Talk to an engineer
  1. 01

    Scoping call

    Equipment, protocols, sites and the systems the data has to reach.

  2. 02

    Technical walkthrough

    A working demo against a scenario that resembles your plant, not a generic tour.

  3. 03

    Pilot plan

    A defined first line or site, with the deployment and security questions answered up front.

  4. 04

    Roll-out

    The same templates bring the next lines and sites online.