LOGO! 8 MQTT: Publishing to Q Outputs That Don't Update

1. Overview: LOGO! 8 MQTT Client and Data Transfer

The Siemens LOGO! 8 Base Module (BM) and LOGO!Soft Comfort 8.4 (LSC8.4) ship with an integrated MQTT client that runs over the same Ethernet interface used for the LOGO! web server and S7 communication. The MQTT binding is configured inside LOGO!Soft Comfort under Tools → Data Transfer Settings and is stored in the project file. After transfer to the BM, the LOGO! connects to a broker (on-premise Mosquitto, cloud broker, or the embedded broker of an HMI), publishes its process state, and accepts inbound commands.

Six logical address spaces participate in the data transfer:

The most common field symptom is the following: the engineer enables the Writable checkbox on a Q bit in Data Transfer Settings, publishes a JSON payload from an external tool, the broker confirms delivery, the LOGO! web server shows the topic has been received, but the physical relay does not change state. The same payload targeting a free M bit updates the bit instantly, and the change is visible in Tools → I/O Status. This article explains the scan-cycle mechanics behind the symptom, shows three engineering remedies, and provides a verification procedure and diagnostic matrix for the commissioning engineer.

2. Problem Statement: Publish to Q Output Has No Effect

A typical JSON payload sent from a Node-RED flow, a Python paho-mqtt script, or a cloud MQTT client to a LOGO! 8 looks like the example below. The target is a digital Q coil that drives a light in a building-automation cabinet.

{
  "topic": "logo/cm/8AQ0/Q1",
  "value": 1
}

The corresponding entry in Data Transfer Settings shows the Writable checkbox enabled, the Direction set to Subscribe, and the Access Mode set to Read/Write. The MQTT broker confirms delivery at QoS 1, the LOGO! diagnostic page in the web server registers an inbound message, but the actual Q1 relay contact does not close. The same payload, retargeted to M20, updates the M flag immediately and the change is visible in Tools → I/O Status and on the web server.

This rules out network, broker, and authentication problems. The fault lies inside the LOGO! program and the way the controller executes a scan cycle.

3. Root Cause: Output Coil Is Consumed by Program Scan

LOGO! 8 executes a deterministic cyclic scan: read inputs → evaluate function-block program in compiled order → write outputs. The cycle period depends on program size and is typically 5–40 ms for a small FBD. During the output write phase, every Q coil that has logic connected to its input side is overwritten with the result of that logic. Any write performed by the MQTT client earlier in the cycle is therefore lost within one scan.

The official LOGO! 8 documentation states the rule in two parts:

1. Physical digital inputs (I) can never be written remotely. They are hard-wired to the process.
2. Physical digital outputs (Q) and memory flags (M) can be written remotely only when nothing is connected to their input side in the LOGO! program. If any block, contact, or reference writes to the Q or M, the program scan takes precedence on every cycle and the remote value is overwritten within milliseconds.

This is why M bits that are not referenced anywhere in the ladder/FBD update correctly, while Q outputs that are wired (for example, I1 AND I2 → Q1) cannot be controlled from the broker. The Writable flag in Data Transfer Settings is necessary but not sufficient; the program must be silent on that address.

A second, less obvious reason for failure is a self-latching output or a flip-flop that drives the Q coil every scan. The latch reasserts the previous state immediately after the MQTT write, and the operator sees no change even though the Q bit flipped briefly. A third, rarer cause is a retentive M flag used as a remote command: if the program uses M as a state bit in another branch, the MQTT write and the program write race, and the operator sees flicker.

4. Solution A: Subscribe to a Network Input (NI) and OR It Locally

The cleanest, most idiomatic Siemens solution is to leave Q1 to its existing program logic and to inject the remote command through a Network Input (NI) that is OR-ed with the local condition. The LOGO! program never overwrites NI, because NI is driven exclusively by the broker (or by a peer LOGO! through NQ/NI cross-link).

Procedure:

1. Open Data Transfer Settings in LSC8.4 and click Add. Set the address to a free NI bit, for example NI1. Enable Writable, choose the direction Subscribe (broker → LOGO!), and bind a topic such as logo/cm/8AQ0/light/cmd.
2. Confirm the broker connection under Tools → Ethernet → MQTT: broker IP, port (default 1883, 8883 for TLS), client ID, username, password, and the keep-alive interval (default 60 s).
3. In the FBD program, open the branch that drives Q1. Insert an OR block whose two inputs are the existing logic chain and NI1. Wire the OR output to Q1.
4. Save the project, click Transfer → PC → LOGO!, and wait for the success dialog.
5. From the MQTT client, publish {"value":1} to the bound topic. Refresh the LOGO! web server; NI1 reads 1 and Q1 follows.

FBD pattern for the light logic:

   I1 (wall switch)  ──┐
                        ├──[ OR ]── Q1 (lamp relay)
   NI1 (MQTT command) ──┘

The advantage of this pattern is that the local logic still works (a wall switch can override the remote command, or a safety interlock can drop the output regardless of MQTT), and the MQTT broker is treated as just another input source. The disadvantage is that you consume one NI per remote command; LOGO! 8.4 provides NI1 through NI64, which is more than enough for typical building-automation use cases.

For toggle behavior, wrap NI1 in a flip-flop:

   NI1 ──[ RS flip-flop ]── Q1 (lamp relay)
       ↑            ↑
       S            R ← I1 (off button)

5. Solution B: Write a Free M Flag and Latch Through the Program

If the program already uses every NI bit or you want to retain a familiar topic address, subscribe to a free M flag and let the program transfer the value to Q. This pattern is documented in the LOGO!Soft Comfort online help under the VM Mapping examples.

1. Reserve an M bit that is not used by any other block. M20 through M27 are typically free in a default program. Enable it as a writable Subscribe entry in Data Transfer Settings and bind a topic, for example logo/cm/8AQ0/cmd/light.
2. Add a small FBD branch: Q1 = M20 OR (existing_logic). The simplest implementation is an OR block whose inputs are M20 and the existing condition, with the output driving Q1.
3. Publish to the topic bound to M20. The flag flips, the OR passes the value to Q1, and the relay closes.
4. Document the M bit as "MQTT command" in the program comments to prevent accidental re-use. If M20 is ever referenced from another block, the same overwrite problem returns.

The trade-off is that you are now writing a "command" into program memory that the program itself consumes on every scan. This is acceptable for level-style commands (a light on, a pump run, a valve open) but problematic for pulse-style commands (a one-shot trigger), because the M bit will stay latched in the program after the broker has long since sent {"value":0}. For pulse commands, prefer Solution A with NI + flip-flop, or use Solution C with VM mapping to a one-shot timer preset.

6. Solution C: Map a Remote Bit to a Block Parameter via VM

The Variable Memory (VM) area in LOGO! 8 is a flat byte-addressable region that can be mapped to function-block parameters. Each VM word (VW) is two bytes and can be referenced as a bit inside a word. The mapping window is configured under Tools → VM Mapping in LSC8.4.

Use this pattern when the remote command must drive a parameter of an analog block (a setpoint, a threshold, a timer preset, a counter preset) rather than a digital output, or when you want to send a numeric value such as a dim level, a target temperature, or a fan speed.

1. Enable a writable VM word in Data Transfer Settings, for example VW100, and bind an MQTT topic to it.
2. In VM Mapping, drag the parameter of the target block onto VW100. The dialog displays the bit offset, for example VW100.0 for the least significant bit, VW100.7 for the most significant bit, and the byte order for 16-bit values.
3. Publish the bit pattern from the broker as a 16-bit signed integer. The block parameter updates on the next scan, and any Q output driven by the block follows.

VM mapping is the documented method for sending numeric values to a LOGO! over MQTT. It does not bypass the program; it feeds parameters that the program already consumes. The complete VM area is reserved in the BM RAM and is not affected by power-cycle, but it is reset by a factory reset.

7. LOGO! 8 MQTT Topic Structure and Payload Format

The LOGO! 8 MQTT client uses a structured topic namespace. The exact root depends on the firmware version and the Device name configured in Tools → Ethernet → Device Name, but the conventional layout is:

logo/<device-name>/<data-block-name>/<address>

Example for a controller named "8AQ0" with the data block "cm" (control & monitoring):

logo/8AQ0/cm/I1
logo/8AQ0/cm/Q1
logo/8AQ0/cm/M20
logo/8AQ0/cm/NI1
logo/8AQ0/cm/VW100

Payload formats supported by LOGO!Soft Comfort 8.4 are summarized below.

8. Data Transfer Settings: Writable Flag and Direction

The Writable checkbox in Data Transfer Settings governs whether the LOGO! accepts inbound writes for that address. It is independent of the program and independent of the broker credentials. Common configuration errors that lead to silent failure:

• Writable is unchecked. The broker delivers the message, but the LOGO! discards it. No error is shown in the web server.
• Direction is set to Publish instead of Subscribe. The LOGO! pushes the current value to the broker on change and ignores inbound writes.
• Access Mode is Read Only. The Writable checkbox is greyed out for I addresses and for NQ addresses.
• Topic name on the publisher does not match the topic name registered in Data Transfer Settings. The broker may deliver the message, but the LOGO! subscription filter does not match. Enable Wildcard subscription under Tools → Ethernet → MQTT if you want to map multiple publishers to one LOGO! address.
• Username/password or TLS settings on the LOGO! differ from the broker. The connection drops silently within 30 s of transfer; the diagnostic page in the web server shows the last error code.
• The Data Transfer Settings were edited in LSC8.4 but the project was not transferred to the BM. The LSC and the BM are out of sync; the BM is still running the old data block.

Always reload the Data Transfer Settings to the LOGO! after editing; the configuration is part of the LSC project, not the BM firmware. After transfer, restart the BM (Tools → Restart LOGO!) to clear the in-memory subscription table.

9. Verifying the Write Path in LOGO!Soft Comfort

After applying one of the three solutions, run the following end-to-end test:

1. Open the LOGO! web server (default http://<logo-ip>) and log in. The I/O status page reflects the live state of every I, Q, M, NI, NQ, and VM address.
2. From your MQTT client, publish {"value":1} to the bound topic. Use a tool such as mosquitto_pub to keep the test independent of your application code:

   
   mosquitto_pub -h broker.local -t logo/8AQ0/cm/NI1 -m '{"value":1}' -u logo -P secret -q 1 -r
       

3. Refresh the web server page. NI1 should read 1 and, if the program wires NI1 to Q1, Q1 should also read 1 and the relay should click. Listen for the relay with a multimeter on the contact if the cabinet is closed.
4. Open LSC8.4 in online mode, Tools → I/O Status. The same addresses should show the updated values. This confirms both the inbound write and the program propagation.
5. Repeat with {"value":0} to confirm the reset path. Watch the web server for at least 2 s after the publish to ensure the value sticks (i.e. the program does not reassert a latch).
6. Restart the BM and re-publish. The retained message from the broker should restore the last state within 1 s of reconnection.

10. Diagnostic and Error Matrix

11. Best Practices for LOGO! 8 MQTT Deployments

• Treat the broker as an input source, not as a controller. The LOGO! should always retain the last valid command in a retentive M flag, NI register, or VM word so that a broker outage does not black out the lights or freeze a valve.
• Use NI for digital commands, VW for setpoints. Reserve M flags for program-internal use only; do not mix MQTT commands and program state in the same M bit.
• Document the topic layout in the LSC project comments. A spreadsheet of topic → address → function → owner will save hours during commissioning and HMI handover.
• Enable retained messages on the broker for the last-known state of every writable address. The LOGO! re-subscribes on connect and pulls the last value, so the process returns to the correct state after a maintenance window.
• Separate read-only telemetry (I, Q, M status, VM read-back) from writable commands onto different MQTT topics. This lets you apply different ACLs and QoS levels on the broker and prevents an over-privileged client from accidentally toggling outputs.
• Use TLS and broker authentication for any deployment that crosses a network boundary. LOGO! 8 supports username/password and broker certificates; configure them under Ethernet → MQTT and rotate the password on the same schedule as the rest of the OT network.
• Disable the LOGO! web server on internet-facing deployments, or restrict it to the local subnet via the firewall on the BM. The web server exposes the same I/O view as the MQTT client and is a common attack surface.
• Periodically back up the LSC project to the source control used for the rest of the automation code. The Data Transfer Settings are part of the project file and are easy to lose during a hardware swap.

12. Ladder/FBD Code Snippets for the Three Patterns

All three patterns below are LSC8.4 FBD blocks. The same logic can be expressed in Ladder Diagram (LD) by replacing each OR with parallel contacts and each RS with a latching relay.

Pattern A (NI parallel):

[ I1 ]──┐
         ├──[ OR ]──[ Q1 ]
[ NI1 ]──┘

Pattern B (M flag with latch):

[ M20 ]──┐
         ├──[ OR ]──[ Q1 ]
[ I1  ]──┘

Pattern C (VM mapping to PI controller setpoint):

[ VW100 ] ─── mapped to SP of [ PI Controller ] ─── output to [ AQ1 ]

For Pattern C, the broker publishes a 16-bit signed integer scaled to the engineering range of the process variable (e.g. 0–1000 for 0.0–100.0 °C, scaling factor 10). The PI controller receives the setpoint, the AO block drives the analog output, and the Q outputs driven by the comparator logic follow automatically.

13. Edge Cases and Field-Proven Caveats

• Retentive M flags (M1–M8): survive a power-cycle and are commonly used as "last command" latches. They are not consumed by the program if no other block references them, which makes them acceptable for MQTT commands, but they are scarce (only 8 in LOGO! 8.4). Use NI or VM for everything else.
• Inputs I1–I24 (digital) and IA1–IA4 (analog): can never be written remotely. Attempting to bind an MQTT topic to an I address and enabling Writable is silently rejected by LSC8.4.
• AQ1–AQ2 (analog outputs): can be written remotely only by mapping a VW word to the analog block parameter, never directly. The Writable flag is disabled for AQ in Data Transfer Settings.
• LOGO! 8 BM variants: the 0BA8 standard BM supports MQTT from firmware 1.80.x onward. The 0BA7 (LOGO! 7) and 0BA6 (LOGO! 6) families do not support MQTT. The 0BA8 with the LOGO! CMR2020 / CMR2040 communication module supports MQTT over the cellular link with the same payload format.
• LOGO! 8.3 vs 8.4 syntax: the JSON payload format {"value":x} is the canonical form on 8.4. On 8.3, plain integer payloads are accepted for bit addresses. If you maintain a fleet with mixed firmware, use the JSON form everywhere to avoid silent failures.
• Broker keep-alive: the LOGO! sends a PINGREQ every 60 s by default. Some cloud brokers (AWS IoT Core, Azure IoT Hub) drop the connection after 90 s of silence; reduce the keep-alive to 30 s in the LOGO! MQTT settings if you see random disconnects.
• Concurrent S7 and MQTT traffic: the LOGO! 8 BM has a single Ethernet interface. Heavy S7 polling from a TIA Portal or HMI can starve the MQTT client. Set the S7 connection to "Read only" when not in commissioning to free the TCP stack.

14. Migration Path: From Direct Q Write to NI Pattern

If you have an existing fleet that already uses direct Q write, plan the migration in three steps:

1. Inventory: list every Q bit that has a Data Transfer entry. For each, decide whether the command should be level (light, fan, valve) or pulse (one-shot trigger, door release).
2. Refactor: in LSC8.4, replace the Q coil with an OR whose inputs are the local logic and a new NI bit. Add a new Data Transfer entry for the NI, enable Writable, and bind a new topic (e.g. add the suffix /cmd to the old topic for clarity).
3. Cut over: deploy the new program and update the publisher. Keep the old Q entry as a one-cycle monitor for the first 24 h to confirm that no client is still publishing to the old topic.

The migration is non-breaking: the program keeps working throughout because the local logic still drives Q, and the MQTT command is additive. Once the dashboards and SCADA have been updated, the old Q entry can be removed.

15. Reference Documentation

• LOGO! 8 System Manual – primary reference for data transfer, MQTT, and VM mapping.
• Siemens LOGO! product page – firmware downloads, module catalog numbers (6ED1052-xxx08-0BA1 for the standard BM), and compatibility matrix.
• Siemens Industry Online Support – search for "LOGO! 8 MQTT" and "LOGO! 8 Data Transfer" for the latest FAQ and firmware release notes.

FAQ