Siemens LOGO! 8.4 Home Assistant Physical Button Wiring

Architecture Overview

This reference covers integration of a Siemens LOGO! 8.4 logic module with Home Assistant using Modbus TCP for bidirectional lighting control where the same lights must be operable from a physical wall push-button and from Home Assistant switch entities. The setup uses the LOGO! 8.4 onboard Ethernet interface (LOGO! 8 generation, firmware 1.82.x and later support the 8.4 hardware revision) to expose internal markers, digital inputs, and digital outputs as Modbus holding and input registers. Home Assistant reads those registers through the official modbus integration and exposes them as switch or light entities.

The architecture is intentionally simple: physical push-buttons are wired into LOGO! digital inputs; a latching (pulse) relay block inside the LOGO! program toggles an output that drives a 230 V lighting load through the onboard relay; the same internal marker that feeds the output is mapped to a Modbus holding register, which Home Assistant polls and reflects as a switch state. Writing back to that register from Home Assistant toggles the LOGO! marker, so both the button and the HA entity drive the same coil.

Prerequisites and Hardware Requirements

• LOGO! 8.4 base module with Ethernet (order numbers 6ED1052-1xxx08-0BA1 family; the "8" digit in the 3rd group identifies the LOGO! 8 generation). Variants with relay outputs support 8 DI / 4 DO; the 24 V variant supports 8 DI / 4 DO plus 4 AI; transistor variants carry 8 DI / 4 DO solid-state.
• LOGO! Soft Comfort V8.4 or later, matching the firmware revision of the controller.
• Home Assistant OS, Supervised, or Container (Core) on a host with reliable Ethernet to the LOGO!. HA version 2024.1 or later is recommended for current Modbus integration features.
• Static IP assigned to the LOGO! (or DHCP reservation). The LOGO! does not have a hostname-based discovery helper for HA out of the box.
• Physical push-buttons rated for the LOGO! input voltage (typically 24 V DC or 230 V AC depending on the LOGO! variant). Dry-contact momentary switches are preferred.
• Ethernet switch on the same L2 segment. Both HA and LOGO! must reach each other on TCP port 502 (Modbus) without firewall interference.

LOGO! 8.4 Modbus Register Map

The LOGO! 8 generation implements a Modbus TCP server on port 502. The following process image mapping is stable across LOGO! 8 firmware versions 1.82.x and 2.x. Always validate against the LOGO! 8 system manual on Siemens Industry Online Support before commissioning.

The most reliable pattern for this application is to expose each light's state through a VM bit (one of the user markers M1..M28), then read and write that coil address from Home Assistant. The VM area is also visible from the LOGO! program as a regular marker, so wiring the output to it is straightforward.

Home Assistant Modbus Integration Configuration

Configure the HA Modbus integration in configuration.yaml or through the UI. For low-latency status feedback set a fast scan interval — the LOGO! can comfortably answer 5–10 polls per second without saturating its internal stack.

modbus:
  - name: logo84
    type: tcp
    host: 192.168.1.50
    port: 502
    delay: 0
    timeout: 2
    switches:
      - name: Living Room Light
        unique_id: logo_living_room
        slave: 255
        address: 841            # coil 841 = M1
        scan_interval: 2        # seconds; reduce to 1 for snappier UI
        command_type: coil
        verify:
          input: 29             # mirror of Q1 (or use coil 833)
          delay: 0
      - name: Kitchen Light
        unique_id: logo_kitchen
        slave: 255
        address: 842
        scan_interval: 2
        command_type: coil

Notes on the parameters:

• slave: 255 matches the LOGO! default Modbus unit identifier (the LOGO! ignores the slave byte when addressed via TCP and always replies, but HA requires a value).
• scan_interval: 2 (default 15) is the single most important knob for fixing the "indicator lags a couple of seconds" symptom. Going below 1 second risks Modbus request collisions.
• verify.input tells HA to re-read a register after a write and confirm the state, which prevents the "button toggled twice in HA when it shouldn't" effect common with bidirectional setups.

Physical Button Wiring Topology

Wire the push-button to a free digital input on the LOGO!. Each button becomes an "I" block in the FBD/LAD program. Feed that input into a latching relay block (the LOGO! "RS" or "SR" flip-flop, or the dedicated Current impulse relay from the Special functions library). The output of the flip-flop drives both the physical Q output and a marker that is mapped to a Modbus coil.

Pulse Relay (Latching Relay) Implementation in LOGO! Soft Comfort

The simplest circuit for each light is a self-latching flip-flop. In LOGO! Soft Comfort:

1. Place an I block (digital input) representing the push-button (e.g., I1).
2. Place a RS flip-flop block from the "Special functions" library.
3. Wire the push-button to the S (set) input of the flip-flop.
4. Wire the same push-button through a Pulse generator (positive edge detector) to the R (reset) input — this toggles the state on every press.
5. Take the flip-flop output to a Q block (physical output) and to a Marker M1 block.

An alternative compact form uses the dedicated Latching relay block (current impulse relay) from the Special functions palette, which combines the toggle behavior internally. This is the recommended approach because it is a single block with one boolean input and one boolean output.

// Pseudocode ladder (FBD-equivalent):
// Network 1:
//   I1 ──┬── [Pulse edge positive-edge] ──┐
//        │                                  │
//        └── [Latching relay B001] ─────────┤
//                                              B001.Q ── Q1 (physical output)
//                                              B001.Q ── M1 (Modbus coil 841)
//
// Network 2 (HA → LOGO! sync):
//   VM word 0 bit 0 (written by HA via FC5 to coil 841)
//       ── OR ── (with B001.Q) ── B001.S

Status Feedback Latency — Root Cause Analysis

The reported symptom — "the indicators sometimes needed a couple of seconds to show the actual status of the lamp" — is fundamentally a polling-interval problem, not a logic error. The contributing factors are:

The dominant contributor is the HA scan_interval. With the default of 15 s, the indicator can lag up to 15 s behind a button press. Reducing scan_interval to 1–2 s brings the worst-case latency down to a level the user perceives as "instant".

Reducing Polling Latency

Apply the following tuning steps in order. Each step is independent and can be reverted if it causes side effects.

1. Set scan_interval: 2 on every Modbus switch and light entity in configuration.yaml. The LOGO! answers a 1-byte Modbus read in < 3 ms, so the bottleneck is purely the HA scheduler.
2. Use coil FC5 / holding-register FC6 instead of FC15 / FC16 for single-entity writes. FC5 (Write Single Coil) returns the same echo immediately and avoids the overhead of multiple register writes.
3. Disable verify reads only if you have measured the LOGO! to be reliable on your network. The verify re-read adds one extra RTT after every toggle.
4. Place HA and LOGO! on the same L2 broadcast domain with no firewall in between. Modbus has no authentication and no retries; packet loss translates directly into missing state updates.
5. Disable other heavy Modbus scanners (e.g., secondary HA instances or pymodbus scripts) on the same host so the polling lock is uncontested.

Edge-Detection Toggle Logic for Bidirectional Sync

When the same marker M1 can be toggled by a button and by a Home Assistant write, a race condition appears: if the button toggles M1 exactly while HA is writing coil 841, one of the two events is lost. Solve this by separating the command channel from the state channel.

1. Reserve M1 as the state (read by HA, written by the LOGO! program only).
2. Reserve M2 as a separate command toggle (written by HA, read by the LOGO! program as an "any change" trigger).
3. In the LOGO! program, detect rising and falling edges of M2 and apply them as a toggle on M1.

// Equivalent in FBD-style:
// -- VM bit M2 toggle channel (HA writes coil 842) --
//   [M2] ── [Positive edge] ── [B002.SET]   // forces M1 = 1
//   [M2] ── [Negative edge] ── [B002.RESET] // forces M1 = 0
//
// -- VM bit M1 state channel (HA reads coil 841) --
//   [B002.Q] ── M1
//   [M1]     ── Q1 (lamp)
//
// -- Button input --
//   [I1] ── [Positive edge] ── M1 toggle via XOR

For a true toggle on every button press without an XOR block, the cleanest LOGO! pattern is to use a dedicated Current impulse relay block where the single input is wired to the OR-combination of "edge of I1" and "edge of M2", and the output is both M1 and Q1.

Using light Instead of switch in HA

The original setup used HA switch entities. Switching to light entities brings three concrete benefits:

• The HA frontend shows a bulb icon and supports brightness / color_temperature even if you do not use those features today.
• The light.turn_on and light.turn_off services are idempotent: calling turn_on on an already-on light does nothing, while a switch toggle flips state. This eliminates the "double press" effect.
• HA exposes a light entity's state through the same Modbus coil, so no extra register map is required.

modbus:
  - name: logo84
    type: tcp
    host: 192.168.1.50
    port: 502
    lights:
      - name: Living Room Light
        unique_id: logo_living_room_light
        slave: 255
        address: 841
        scan_interval: 2
        command_type: coil
        verify:
          input: 29
          delay: 0

Alternative Architecture: S7-1200 / S7-1500 Upgrade

If button-press latency and bidirectional sync become a recurring limitation, the next step is replacing the LOGO! 8.4 with an S7-1200 (CPU 1211C/1212C/1214C/1215C) or S7-1500 (CPU 1511-1 PN through 1518-4 PN/DP). These support the S7 communication protocol natively on port 102 (ISO-on-TCP), and Home Assistant can reach them via Python integrations that use pys7. The S7-1200/1500 also publishes real change-of-state events rather than relying on HA polling, which removes the polling-latency problem at its root.

However, this upgrade is not free:

• S7-1200/1500 programming requires TIA Portal (paid license or trial).
• Hardware cost per I/O point is roughly 3× that of LOGO! 8.
• The S7 protocol is not officially supported by HA; only third-party integrations exist and they break when Siemens changes internal tags.

For a 4–8 light residential setup, the LOGO! 8.4 + Modbus approach described in this article is the most cost-effective and stable choice.

Troubleshooting Matrix

Verification Checklist After Configuration

1. Press the physical button. The lamp should toggle within ~100 ms (LOGO! scan + relay).
2. Within 2 s (one HA scan interval), the HA switch entity should reflect the new state.
3. Toggle the HA switch entity. The lamp should toggle within ~50 ms (Modbus write + LOGO! scan + relay).
4. Press the physical button rapidly 5 times. The lamp should toggle 5 times; HA state should converge within 2 s of the last press.
5. Disconnect the LAN cable between HA and the LOGO!. The physical button should still control the lamp. Reconnect the cable; HA should resync within 2 s.
6. Power-cycle the LOGO!. HA entities should become "unavailable" within the configured timeout, then return to the correct state once the LOGO! is back online.

Safety and Wiring Caveats

• Never connect 230 V AC inputs and 24 V DC inputs to the same LOGO! 8 base module unless the datasheet explicitly states it is supported for your variant.
• When using the relay-output variants (RCE), the onboard relays are rated for 10 A at 230 V AC resistive. For inductive loads (motors, transformers), derate by 50 % and add an RC snubber across the load.
• The LOGO! 8.4 Ethernet port does not support Modbus over TLS. Modbus TCP is plaintext and unauthenticated — isolate the device on a VLAN with no internet exposure.
• When the LOGO! is in STOP mode (programming error or firmware update), Modbus still answers but registers may freeze. HA will report stale state until the LOGO! returns to RUN.

FAQ