MQTT · SPARKPLUG B · S7-1500 LMQTT · EDGE GATEWAY · PYTHON & SQL
The course for engineers who have to get plant values onto a broker and keep them arriving. Start with the publish and subscribe model, topic design, QoS, retained messages and the JSON or Sparkplug B payload contract. Publish from an S7-1500 with LMQTT blocks and from an OPC UA edge gateway, then build the consumer side in Python with reconnection, storage in SQL Server and a dashboard — finishing with broker security and packet-level diagnosis when a connection silently drops.
Classroom day batches · Online 7:30 PM–9:00 PM · Sunday 11:00 AM–5:00 PM
See the broker tooling, controller features and practical topics used at each stage of the MQTT path. Select a module to view exactly what you will work with.
Training progression: Module 01 sets up the broker and the payload contract, Module 02 gets plant data publishing from the controller and the edge gateway, Module 03 builds the consumer side that survives a dropped connection, and Module 04 delivers dashboards, broker security and the diagnosis method for when messages stop arriving.
View Detailed MQTT Training Contents →The course is organised as four practical modules covering 15 hands-on topics. Every topic below is a written guide with working code you can open before or after the session — from broker setup and payload design through S7-1500 publishing to Python subscribers, SQL storage and dashboards.
Start with the publish and subscribe model, the broker in the middle, and the payload contract everything downstream depends on — plus a working Python environment to test against.
Install Python, VS Code and paho-mqtt so every broker exercise in the course can be run and debugged on your own machine.
View training topic →02Keep the MQTT client isolated in its own environment and reproduce it on the plant edge PC from requirements.txt.
View training topic →03Decide the JSON contract before writing a publisher: field names, units, timestamp format and how nulls and decimals are handled.
View training topic →Two ways plant data reaches the broker: the PLC publishing directly with the LMQTT client, or an edge gateway bridging OPC UA to MQTT — both built and compared in the sessions.
Publish directly from the controller with the LMQTT client, connect to the broker, and work with topics, QoS and retained messages.
View training topic →02The typed, secured source most gateways read from — configured here so the bridge in the next topic has something real to map.
View training topic →03Map OPC UA nodes to MQTT topics through an edge gateway, publish to the broker, and keep the SCADA station reading the same values.
View training topic →Write the consumer side properly: subscribe with paho-mqtt, parse payloads, survive a dropped connection, and land every message in SQL Server where reports can reach it.
Connect, subscribe and publish with paho-mqtt, handle callbacks and reconnection, and parse JSON payloads into usable records.
View training topic →02Broker outages, malformed payloads and database failures handled explicitly, with a log that explains an overnight gap.
View training topic →03Write subscribed messages into the plant database with parameterised inserts, batching and commit control.
View training topic →04Ten working scripts to adapt for the storage side of any broker-based integration.
View training topic →05Query the stored messages back out for analysis, reconciliation and report generation.
View training topic →Finish with what the data is for and what to do when it stops arriving: dashboards, an honest comparison with REST and OPC UA, and packet-level diagnosis of a broker connection.
Turn subscribed telemetry into a dashboard people use — which KPIs, which queries behind them, and refresh behaviour.
View training topic →02The request and response alternative, built in Python so the MQTT versus REST decision comes from having done both.
View training topic →03The companion program for record-style exchange with MES and ERP, where a broker is the wrong tool.
View training topic →04Trace a broker connection: CONNECT and CONNACK, blocked port 1883 or 8883, TLS handshake failure and client ID conflicts.
View training topic →MQTT is a lightweight publish and subscribe protocol. Devices publish values to a broker and any number of consumers subscribe, so the controller is read once instead of being polled by every application. That, plus very low bandwidth use and report by exception, is why it suits plants on shared or cellular links and multi-site groups.
Sparkplug B is a specification on top of MQTT that fixes the topic namespace, adds birth and death certificates so a consumer knows a device's full tag list and online state, and uses a compact binary payload. If your platform supports it, use it; if you are integrating with a simple dashboard or custom application, plain JSON payloads are covered in the course too.
Mosquitto is used for the labs because it installs in minutes and shows every concept clearly. The same configuration approach applies to HiveMQ, EMQX and cloud brokers, and the differences that matter in production — clustering, persistence and access control — are explained.
Yes, using the LMQTT client blocks in TIA Portal, and that lab is part of the course. The alternative route, an edge gateway bridging OPC UA to MQTT, is also built so you can compare controller load, payload flexibility and maintenance effort before deciding.
MQTT for high-rate telemetry to many consumers over an unreliable link, OPC UA for typed and secured access to controller data, REST for request and response record exchange with MES and ERP. Most working architectures use more than one, and this course builds MQTT alongside the other two so the choice is made from experience.
TLS on port 8883 rather than plain 1883, per-device credentials or client certificates, access control lists that limit which client can publish or subscribe to which topic, and no anonymous access. A broker on 1883 with anonymous access is a plant-wide data leak, and the course treats it that way.
Wherever you need it. The course writes subscribed messages into SQL Server with Python, reads them back for reports and dashboards, and shows the same feed serving a live KPI screen. The broker moves data; it is not the place data is stored.
Yes. QoS 0, 1 and 2 with what each costs in traffic and latency, retained messages and last will for device status, clean versus persistent sessions, keep-alive behaviour and the client ID conflicts that cause silent disconnects on a plant network.
Classroom sessions run in the day batches and live online sessions run from 7:30 PM to 9:00 PM on weekdays, with a Sunday batch from 11:00 AM to 5:00 PM. Corporate and in-plant groups can request a different schedule.
Send your requirement for MQTT and Industrial IoT training. Mention your controller, the broker or platform you have to publish to, and whether you need plant-side publishing, the consumer side or both, so the labs match your project. Online batch runs 7:30 PM to 9:00 PM on weekdays and 11:00 AM to 5:00 PM on Sunday.
Explore the four modules, the broker and controller setup used in the labs, the integration targets covered and classroom or online batch options.
Content reviewed: 19 September 2026