Skip to content

MQTT

Good fit vs bad fit

Good fit Bad fit
brokered fan-out and pub/sub strict register-oriented device control
remote telemetry and event distribution hard real-time same-host coordination
systems with existing broker ACL/TLS policy cases where a direct device protocol already exists

First things to decide

  • what broker boundary is authoritative?
  • what topic names represent input and output clearly?
  • what reconnect/keep-alive policy is acceptable?
  • what TLS/auth requirements apply in this network?

Example and commissioning guide

Communication Example: MQTT

This example shows how to use io.driver = "mqtt" for broker-based I/O exchange.

What you learn

  • topic design for PLC input/output channels
  • reconnect and keep-alive tuning basics
  • why secure broker boundary decisions must be explicit

Files in this folder

  • src/main.st: minimal %IX -> %QX logic (DO0 := DI0)
  • src/config.st: task binding plus VAR_CONFIG mapping (P1.DI0/P1.DO0)
  • io.toml: MQTT backend profile
  • runtime.toml: runtime defaults
  • trust-lsp.toml: project settings

Step 1: Build first

Why: separate compiler issues from transport issues.

cd examples/communication/mqtt
trust-runtime build --project . --sources src

Step 2: Review io.toml

Why: topic and reconnect policy directly shape reliability and security.

[io]
driver = "mqtt"

[io.params]
broker = "127.0.0.1:1883"
topic_in = "trust/examples/mqtt/in"
topic_out = "trust/examples/mqtt/out"
reconnect_ms = 500
keep_alive_s = 5
allow_insecure_remote = false

Field intent:

  • broker: MQTT endpoint.
  • topic_in: messages consumed into %I image.
  • topic_out: messages published from %Q image.
  • reconnect_ms: backoff cadence for broken sessions.
  • keep_alive_s: session liveness interval.
  • allow_insecure_remote: blocks unsafe remote configuration.

Step 3: Validate config

Why: detect missing mandatory fields and invalid values early.

trust-runtime validate --project .

Step 4: Run against a broker

Why: topic contract validation must happen with a real broker path.

  1. Start broker on 127.0.0.1:1883.
  2. Run runtime:
trust-runtime run --project .
  1. In another terminal, inspect I/O:
trust-runtime ctl --project . io-read

Step 5: Production hardening checklist

Why: MQTT deployments often fail at boundary assumptions, not syntax.

  • enforce broker auth/TLS according to site policy
  • keep input/output topics separate and explicit
  • define ACLs for publish/subscribe directions
  • confirm reconnect behavior under broker restart tests

Common mistakes

  • reusing same topic for both topic_in and topic_out
  • leaving broker ACLs open during rollout
  • treating successful validate as proof of runtime connectivity
  • dropping safe_state definitions for output-critical projects

Common MQTT gotchas

  • using the same topic for topic_in and topic_out
  • unclear ACL direction between publish and subscribe
  • testing only against a local open broker and skipping production auth/TLS
  • forgetting safe-state behavior for output-critical projects