Configuring Siemens LOGO! 8 S7 Output Control in Node-RED

Problem Statement: Node-RED Cannot Drive LOGO! 8 Outputs via S7

When integrating a Siemens LOGO! 8 (order code 6ED1052-1xxx08-0BA8, including the 1FB08 Ethernet variant) with Node-RED over the S7 protocol (ISO-on-TCP, port 102), the controller appears to accept write commands from the SCADA/HMI side, but the physical output relays do not change state. Writing to addresses such as DB data blocks, QX.X (Q0.0, Q0.1, Q0.2), or even unused outputs like Q20 with the correct TSAP combination produces no electrical action at the terminals.

The Node-RED flow reports a successful S7 write, the LOGO! 0BA8 acknowledges the telegram, but the output stays at its program-driven state. Voice-command pipelines built on Android Tasker → MQTT → Node-RED therefore appear to "work" at the data layer yet fail at the actuator layer.

Root Cause: Cyclic Overwrite of Physical Outputs by the LOGO! Program

The Siemens LOGO! executes its user program cyclically, typically every 20–50 ms depending on program length and 0BA8 firmware. On every cycle, the LOGO!Soft Comfort (LSC) FBD/LD program writes the result of its logic network directly to the left side of the Q (output) operand.

When an external S7 client attempts to write to a Q bit, that write is valid only for the very brief window before the next LOGO! cycle overwrites it. The user program has higher priority than the S7 write image. This is by design: outputs are the result of the program, not an independent memory area that the program samples.

The same logic applies to the four cursor/display flags (M25..M28) and special flags. Any memory cell that is assigned to the left side of a coil in the LSC diagram will be reset by the next cycle.

Solution Architecture: Virtual Memory Bit + OR Block

The correct integration pattern is:

1. Reserve one or more flag bits (M1..M64) or network inputs (NI1..NI64, exposed in S7 as the V area) as a command channel.
2. Have Node-RED write to that M bit over S7. Flag bits are not owned by the user program unless explicitly assigned, so the write persists until the program clears them.
3. In the LOGO! program, OR the flag bit with the local logic that would otherwise drive the output. The output coil (Q1) is then energized whenever either the local logic or the external Node-RED command is true.

This pattern respects the LOGO! 0BA8 ownership model: the program still owns the output coil, but it now also listens to an external "virtual input".

Step 1 — Configure the LOGO!Soft Comfort Program

Open the existing program in LOGO!Soft Comfort (LSC) V8.x or later, which is the official Siemens engineering tool for the 0BA8 series (download via the LOGO! 8 System Manual entry in the Siemens Industry Online Support).

For each output that should be externally controllable:

1. Insert an OR block (function block B01 in the LSC toolbox).
2. Connect the existing program branch to input 1 of the OR block.
3. Connect a flag bit — for example M1 for Q1, M2 for Q2, M3 for Q3 — to input 2 of the OR block.
4. Wire the OR output to the Q1, Q2, Q3 coils as before.

The resulting FBD rung should look conceptually like this:

            +-------+
[Local I1]-+       |
            |  OR   +----[ Q1 ]
[Flag M1 ]--+       |
            +-------+

Repeat for each output. The flag bit Mx is now the "command register" for that output. The local program logic can still force the output low by simply not energizing input 1 of the OR — useful for safety interlocks.

Step 2 — Configure the Node-RED S7 Connection

Install the node-red-contrib-s7 package (v2.x for current Node-RED LTS). This node implements the S7 client role using the nodes7 library and supports the ISO-on-TCP transport the LOGO! 0BA8 expects.

Drag an s7 endpoint configuration node onto the flow and configure it as follows for a typical LOGO! 8 on a /24 private LAN:

The remote TSAP 02.00 corresponds to the LOGO!'s S7 server slot 2, which is the default S7 connection for the 0BA8. If the LOGO! project defines additional server connections, the TSAP pair becomes 03.00, 04.00, and so on. Refer to the LOGO! 0BA8 System Manual chapter on Ethernet connections for the full table.

Step 3 — Define Variable Addressing in the s7 Node

Open the s7 in and out configuration node (double-click the s7 endpoint to reveal the variable table) and enter the items below. The address format follows S7 conventions: area letter + byte.bit.

The mapping Q0.0 → Q1 through Q0.7 → Q8 and Q1.0 → Q9 through Q1.3 → Q12 is documented in the LOGO! 0BA8 System Manual, section "Address areas in S7 communication". The 0BA8 base unit supports up to 20 outputs depending on the model variant (e.g., LOGO! 8.3 with relay outputs 6ED1052-1MD08-0BA8 = 4 outputs; 6ED1052-1CC08-0BA8 = 8 outputs; 6ED1052-2MD08-0BA8 = 4 outputs, etc.). The Q2.x byte covers Q17..Q20 on 20-output models.

Step 4 — Build the Node-RED Flow

A minimal control flow uses an MQTT input (from the voice pipeline) and a function node that maps topic names to M flag writes. A complete example flow exists at flows.nodered.org — Siemens Logo8 + Node-RED Q1..Q10 read, M1 write and an adapter example at flows.nodered.org — Adapt s7 node to LOGO.

A reference flow skeleton that performs the M-flag write is:

[{"id":"mqtt_in","type":"mqtt in","z":"flow1","name":"Voice Cmd","topic":"logo/cmd/#","broker":"broker1","x":140,"y":120,"wires":[["parse_cmd"]]},
{"id":"parse_cmd","type":"function","z":"flow1","name":"Map topic to M flag","func":"var t = msg.topic;\nvar v = (msg.payload == 'on' || msg.payload === true);\nvar out = {};\nif (t === 'logo/cmd/q1') out.M1_cmd = v;\nelse if (t === 'logo/cmd/q2') out.M2_cmd = v;\nelse if (t === 'logo/cmd/q3') out.M3_cmd = v;\nelse return null;\nmsg.payload = out;\nreturn msg;","x":340,"y":120,"wires":[["s7_out"]]},
{"id":"s7_out","type":"s7 out","z":"flow1","endpoint":"LOGO8_OB08","variable":"M1_cmd","x":540,"y":120,"wires":[]}]

When MQTT receives logo/cmd/q1 = on, the function emits {M1_cmd:true}, and the s7-out node writes true to M0.0 in the LOGO!. Because the LSC program ORs M1 with the local logic, Q1 energizes.

For debouncing voice commands (Tasker can fire the same intent twice within ~300 ms), place a delay node or a distinct node in front of the s7-out node.

Step 5 — Verification Procedure

1. Confirm S7 connectivity. Deploy the flow and open the s7 endpoint node. The status indicator should be solid green. A yellow/gray indicator means the TCP socket or TSAP is wrong — re-check the values in Step 2.
2. Confirm payload delivery. Connect a debug node to the s7-out node's input. The debug sidebar should show {M1_cmd:true} when the MQTT topic fires.
3. Confirm flag write. Inject a Boolean value into the s7-out node and then read back MB0 on the s7-in node. If MB0 reflects the write, the addressing is correct.
4. Confirm output energization. Physically observe the relay LED for Q1 on the LOGO! 0BA8 housing. If it does not light, the LSC program is not actually OR-ing the flag. Re-check the rung wiring.
5. Confirm local logic still wins. Toggle a local input (I1) that drives Q1 in the original program. The output should still respond. If the output now ignores local input, the OR block has been wired backwards.
6. Confirm no cyclic flicker. With Node-RED writing M1 = true continuously, monitor Q0.0 on the s7-in node. The value must be a stable true, not a 1-Hz blink. A blink indicates the LSC program is clearing the flag at the end of each cycle — move the flag into a "latch" or OR-pattern as described.

LOGO! 0BA8 S7 Memory Map Reference

Troubleshooting Matrix

Advanced: Bi-Directional State Feedback and Latching

For installations that require the LOGO! to know the actual state of each output (useful when the output is wired to a latching contactor), publish the read-back Q0.0..Q0.2 bytes to MQTT in a 2-second cycle. The state can then be consumed by Home Assistant, a Node-RED dashboard, or a Tasker variable.

To implement a software latch in the LOGO!, use the SR (Set/Reset) flip-flop block (B03 in LSC) with the M-flag as the Set input and a separate "release" flag as the Reset input. This pattern is preferred over relying on Node-RED to maintain the ON state across reboots of the Node-RED host — the LOGO! remains the authority even if Node-RED restarts.

Security and Hardening Notes

The 0BA8 S7 server does not support TLS or user authentication. Restrict S7 access at the network layer:

• Place the LOGO! on an isolated VLAN with the Node-RED host and any other authorized clients only.
• Disable the LOGO!'s web server and remote S7 access from the WAN side of any router.
• Configure the LOGO!'s built-in firewall (Tools → Security → Firewall) to block all inbound connections not originating from the Node-RED host's IP.
• If exposing Node-RED via MQTT to the internet (for Tasker from outside the LAN), require TLS and a username/password on the broker, and never expose the LOGO! S7 port (102/TCP) to the internet.

Reference Field-Tested Patterns

For projects that go beyond three outputs, the same OR-block pattern scales: a single MB0 byte gives eight M-flag command channels, mapped to M0.0..M0.7 in S7, corresponding to LOGO! M1..M8. For voice pipelines that need natural-language mapping ("turn on the kitchen lights"), add a Node-RED function node with a synonym dictionary before the s7-out node. The function translates textual intents into the appropriate M-flag write.

Industrial practitioners integrating LOGO! 8 with higher-level systems such as MQTT brokers, Node-RED dashboards, or third-party SCADA packages should always model the LOGO! as a "command-receiving actuator" and never as a "directly writeable output". The OR-block + flag-bit pattern is the only architecturally sound way to achieve external control without breaking the PLC program's logic authority.