Choose the direct PLC path deliberately
This lesson covers the direct S7-1500 → MQTT broker path using Siemens’ LMQTT_Client application example. The next bridge lesson covers publishing through an OPC UA edge client instead. Keep the existing WinCC-to-PLC display connection independent of MQTT publishing.
Download the Siemens example version compatible with your CPU, firmware and TIA Portal. Follow its included requirements, library types and sample project; do not assume a block call copied from another release has the same pins, limits or supported QoS.
Lab scope: use an isolated training CPU/network, TIA Portal compatible with its firmware and a supported WinCC Classic release where required. Check the exact CPU order number, firmware, license and installed software before following configuration steps. Examples use read-only telemetry; no example writes a motor command. The addresses, tag names and values are teaching choices.
Prepare a broker and an independent MQTT subscriber before editing PLC code. Configure its listening endpoint, topic permissions and, for the TLS exercise, certificate trust and a correct CPU clock. Siemens specifically identifies broker certificate handling and CPU time validity as TLS prerequisites.
Define the topic and payload first
Use the exact training topic factory/lab/unit101/telemetry. Keep the topic stable and put values in the JSON body. This original payload has explicit units, quality and sequence:
{
"schema": "unit101.v1",
"source": "s7-1500-lab",
"seq": 42,
"level_pct": 50.0,
"flow_m3h": 12.0,
"pump_running": true,
"quality": "good"
}Generate JSON with correct decimal points, Boolean spelling and length. If you include a timestamp, define whether it is PLC sample time or gateway collection time and ensure its clock is meaningful. A valid JSON document can still contain stale process data.
Configure the library example in TIA Portal
- Import/open the compatible Siemens LMQTT example and its dependent types in a separate training project. Compare the documented requirements with your actual CPU.
- Use the example’s connection configuration for broker address/hostname, port and network interface. The common ports 1883 and 8883 are conventions; use the broker’s configured listener.
- Set a unique MQTT client ID. Configure authentication and TLS material using the example’s supported fields.
- Create the required block instance and call it cyclically as described by that library. Keep its connection processing running while waiting for events.
- Prepare a publish buffer for the JSON payload and set the actual payload length. Respect the version’s buffer and message-size limits.
- Use a deliberate sampling interval, such as one second for the slow lab data. Trigger a publish according to the example’s request/handshake mechanism rather than issuing a new job on every PLC scan.
- Observe completion/error and diagnostic outputs. Clear or re-arm a request according to the documented interface; retain failed sample identity if your retry design needs it.
Pin names and supported QoS differ by example version, so use the imported block interface as the authority. The following state sequence is design pseudocode, not a compilable Siemens FB call.
DISCONNECTED → CONNECTING → CONNECTED
CONNECTED + sample_due → prepare payload → request publish
publish_complete → advance sample counter → wait for next sample
publish_error → record status → bounded retry/reconnectCheck the broker with a separate subscriber
- Connect the subscriber with a permitted account to the same listener.
- Subscribe to the exact topic or a permitted test filter.
- Observe seq 42 and the known values, then change only level in the training PLC.
- Confirm topic, JSON type, value and sequence at the subscriber.
- Restart the subscriber and then the broker in the lab; record how the selected session/reconnect configuration behaves.
QoS is a delivery setting, not proof of application freshness. Select only a QoS supported by your library and broker. Retained messages may deliver an older sample to a new subscriber; apply age/sequence checks. The detailed delivery and retained-message rules are defined in the linked OASIS specification.
Test failures that look like success
| Observation | Check |
|---|---|
| Connected, no messages | Topic spelling, ACL, publish request and payload length |
| TLS connection fails | CPU time, trust chain, broker identity and library diagnostics |
| Repeated disconnects | Duplicate client ID, keepalive, network and broker logs |
| Old value after reconnect | Retained/session behavior and application freshness rule |
| JSON rejected | Encoding, number formatting, escaping and buffer truncation |
Deliver: library version, endpoint/topic settings, one captured payload, PLC status observations and reconnect test results. If direct PLC publishing is unsuitable for your hardware or maintenance approach, use the OPC UA gateway lesson.
Official technical references
The workflows use these references for the named software/protocol features. Unit 101 data, diagrams, payloads and acceptance criteria are original training examples. Confirm release-specific settings in the matching Siemens documentation.
Connect the data to your factory screen
Use the five P&ID lessons to create the tank, pump and valve display, then apply the tested controller connection.
Factory screen learning seriesOPC UA manualDiscuss practical training