FireSight docs

FireSight OT OT remote access

MQTT bridge: plant data to your MQTT broker, one way

New in 0.4.0 (beta). Included in the base licence. Lab-tested end to end; not yet run at a customer site.

The MQTT bridge carries data from machines on plant networks to a company's upstream MQTT broker or application: HiveMQ, EMQX, Mosquitto, AWS IoT Core, Azure Event Grid, an Ignition or Unified Namespace broker.

  • The data path: machines publish to the Cloud Connector on the machine network. The Cloud Hub forwards the allowed topics to the upstream broker over TLS.

  • One way, plant to upstream:

    • devices can't subscribe on the Cloud Connector (every subscription is refused);
    • the Hub never subscribes upstream;
    • so the bridge can't carry commands (e.g. Sparkplug NCMD/DCMD) into the plant.
PLCs / edge devices ──publish──► Cloud Connector ══(outbound TLS tunnel)══► Cloud Hub ──mqtts──► upstream broker
      (machine network only)        (no subscriptions)                          (no subscriptions)

This follows the joint NCSC / CISA / ASD / BSI Secure connectivity principles for OT:

  • connections are initiated outbound from OT;

  • data exchange is brokered (the Hub acts as the DMZ broker);

  • the protocol is MQTT over TLS;

  • inputs are checked at the boundary;

  • data flows one way.

It is logically one-way, not a hardware data diode. Sites that require hardware-enforced unidirectionality need a diode.

What it checks on the Cloud Connector

  • Machine side only: the bridge listens on the machine port and VLANs (TCP 1883, and 8883 with TLS), never on the uplink.

  • Which devices may publish:

    • Resources allowed to publish: each chosen resource only from its own address and VLAN. A network resource allows its whole subnet.
    • Other addresses allowed to publish: typed by hand; these apply on any machine network.
    • With neither set, any machine on the machine side may publish.

  • Sign-in (optional): user mqtt and a Hub-generated password that only works on that Cloud Connector.

  • Topics: only the topic filters you list, e.g. plant/# or line1/+/temperature. $-topics never pass. Publishing elsewhere is refused (an MQTT 5 device gets "not authorized"; an MQTT 3.1.1 device is disconnected for QoS 1).

  • Size and rate: payload up to 256 KB by default (up to 4 MB), 100 messages a second per device by default. Optionally JSON only.

  • Retained messages and wills: the retain flag is passed upstream if the upstream keeps retain flags, but nothing is retained on the Cloud Connector. Last-will messages (e.g. Sparkplug NDEATH) are forwarded when their topic is allowed.

  • No internet or Hub: messages are kept on the Cloud Connector's disk (100 MB by default; the oldest go first when it's full) and sent when the link is back. On mobile data, set Collect for up to (e.g. 300 s) to send in one go every few minutes.

  • Site opt-out: the site can refuse the bridge on the device: untick Allow the MQTT bridge on its setup page, or put mqtt_bridge=off in firesight.txt on the SD card.

On the Hub

  • Upstream brokers belong to a company. Each has:

    • Address: mqtts://host:8883. mqtt:// is for a private network only, and then without a password.
    • Sign-in: a user name and password, and/or a client certificate for mutual TLS (AWS IoT Core, Azure Event Grid).
    • Trust: an optional extra CA for private brokers.
    • Client ID: optional.
    • Topics start with: e.g. {company}/{site}/, with the company and site filled in. plant/line1/temp from Store 12 then arrives as acme-foods/store-12/plant/line1/temp. Leave it empty to keep topics as they are, for Sparkplug B (spBv1.0/…); then limit each Cloud Connector's topics carefully.
    • Highest QoS: 0 or 1. Delivery is at least once.
    • Keep retain flags.

  • Delivery:

    • The Hub keeps messages on disk per upstream (up to 500 MB, oldest first when full).
    • It publishes them in order and retries with back-off while the broker is unreachable.
    • The Test button connects and publishes …/firesight-ot/test.

  • Events (category connectors):

    • mqtt_upstream_down when the broker can't be reached;
    • mqtt_upstream_up when it's back.

    Individual messages aren't logged in the audit log (volume). The page shows counts: sent, waiting, dropped.

Set it up

  1. MQTT bridge → Upstream brokers → Add upstream broker: the company, the broker address, its sign-in or certificate, and the topic prefix. Use Test.
  2. Cloud Connector → MQTT bridge (or MQTT bridge → Cloud Connectors):
    • switch it on and choose the upstream;
    • choose the ports and list the topics devices may publish to;
    • tick the devices' resources, or type their addresses;
    • optionally require the sign-in or JSON.
  3. Configure the devices:
    • Broker: the Cloud Connector's machine-side address, port 1883 (or 8883 with TLS).
    • Sign-in: the user and password shown on the page.
    • Topics: publish to the allowed topics.
    • Don't subscribe: subscriptions are refused.
    • TLS: the Cloud Connector's certificate is self-signed, so tell the device to accept it or not to verify it. This hop never leaves the plant network.

Sparkplug B

Sparkplug B payloads pass through unchanged. Leave the upstream's topic prefix empty, so topics stay spBv1.0/<group>/…, and allow spBv1.0/#. Births, data and deaths (including NDEATH as the last will) reach the host application. Commands (NCMD / DCMD) and host STATE messages don't come back, because the bridge is one way. Edge nodes that wait for the host's STATE before publishing need that check switched off.

← API and integrations Security and audit →