Fixing Siemens CMK2000 LOGO! KNX Gateway Errors 5 and 3

Fixing Siemens CMK2000 LOGO! KNX Gateway: Errors 5 and 3

The Siemens CMK2000 communications module integrates the LOGO! 8 logic module family into a KNX TP1 building system bus. When the gateway's web diagnostic page reports Device Status = ERROR (5) and LOGO! Connection Status = ERROR (3) while KNX still shows CONNECTED (1), the gateway is signaling a problem on the Ethernet/IP path between the CMK2000 and the LOGO! 8 CPU — not on the KNX bus itself. This article gives engineers a field-proven procedure to isolate the cause and restore the link without a full reflash, and documents the firmware-update path that Siemens publishes for the module.

1. Problem Description

The CMK2000 is configured via its built-in web server. After assigning an IP address and opening the diagnostic page in a browser, three states are displayed:

2. CMK2000 Hardware and Reference Topology

The CMK2000 mounts on a DIN rail beside the LOGO! 8 base module (6ED1052-xxx08-0BA0 variants). It exposes two physical interfaces:

• KNX TP1 — red/black push-in terminal, top of the module; carries the building bus segment.
• Ethernet RJ45 — 10/100 Mbit/s; connects to the LOGO! 8 CPU on the left side and to the IT/LAN on the right side.

Refer to the Siemens press release: More automation with LOGO! and the KNX building system bus for the official product positioning and the supported LOGO! 8 BM variants. The integration schematic and KNX object mapping are documented in the LOGO! 8 Gate Circuit for KNX application note (PDF).

2.1 Inline topology diagram

3. Decoding the Web Interface Status Codes

The CMK2000 exposes three independent state machines. Each one carries a numeric code that the gateway publishes on the diagnostic page and (when polled by LOGO! Soft Comfort) on its internal tags:

4. Root Cause Analysis

When KNX stays CONNECTED (1) but Device Status is ERROR (5) and LOGO! Connection Status is ERROR (3), the failure domain is the Ethernet segment between the CMK2000 and the LOGO! 8 module. The three causes most commonly reported in the field are:

4.1 Cause A — Dynamic Server IP Filter blocking the LOGO! 8 request

The CMK2000 enforces a per-interface access control list. The default policy denies any connection originating from an IP that is not on an explicit allow-list. When the LOGO! 8 CPU initiates an S7/LOGO! request toward the CMK2000 — for example after a power-up, after an IP change, or when the LOGO! 8 DHCP lease rotates — the gateway sees a "new" source IP and drops the session. The gateway then publishes Device Status = ERROR (5) because its self-test loses contact with its supervisor, and LOGO! Connection Status = ERROR (3) because the upstream LOGO! 8 is no longer reachable on the configured port.

4.2 Cause B — Layer-2/3 interruption after a 2-hour timeout

A second, well-documented symptom is that the CMK2000 disconnects from the network approximately every two hours. This timeout aligns with the gateway's default internal supervision/keep-alive cycle. When the cycle expires, the gateway tears down its open sockets and re-establishes them — and if the re-establishment fails (because of Cause A above, or because of an upstream switch port that has aged out the ARP entry, or because of an IGMP/MLD snooping entry that has expired), the connection does not come back until the CMK2000 is power-cycled. Engineers report that direct Ethernet connection between the CMK2000 and the LOGO! 8 — i.e., no switch in between — eliminates the timeout entirely.

4.3 Cause C — VLAN segmentation mismatch

Where the CMK2000 and the LOGO! 8 live on the same physical switch but in different VLANs (for example because IT places the gateway in a "managed devices" VLAN and the LOGO! 8 stays in the OT VLAN), the broadcast/multicast traffic generated by the CMK2000's discovery protocol never reaches the LOGO! 8 CPU. The CMK2000 times out and reports the same ERROR (5) / ERROR (3) pattern. A dedicated VLAN containing only the CMK2000 and the LOGO! 8 — or routing the two endpoints into the same Layer-2 broadcast domain — restores the link.

5. Solution: Step-by-Step Recovery Procedure

Work the steps in order. Each step has an explicit verification check before moving to the next one. This procedure assumes you can reach the CMK2000's diagnostic web page at http://<CMK2000-IP>/.

5.1 Prerequisites

• A PC with a modern browser (Chrome, Edge, Firefox) on a subnet that can reach the CMK2000.
• Read/write access to the CMK2000 web interface (default credentials are documented in the device manual; change them at commissioning).
• Physical access to the LOGO! 8 base module (to read its IP from the display or via LOGO! Soft Comfort).
• A spare Ethernet cable for the direct-connect test in step 5.6.

5.2 Procedure

1. Confirm KNX health. Open the CMK2000 diagnostic page and verify KNX Connection Status = CONNECTED (1). If it is not, stop — the problem is on the KNX side and is outside the scope of this article.
2. Read the LOGO! 8 IP. On the LOGO! 8 display, navigate to Setup → Network → IP Address and note the IPv4 address and subnet mask. If the LOGO! 8 uses DHCP, reserve the address at the DHCP server so it does not rotate.
3. Ping the LOGO! 8 from the CMK2000 subnet. From the engineering PC, ping the LOGO! 8 address. A successful ping rules out cabling and confirms that the LOGO! 8 S7/LOGO! server is up.
4. Disable the Dynamic Server IP Filter. In the CMK2000 web interface, locate the security or filter menu. Find the Dynamic Server IP Filter setting and change it from the default restrictive mode to Accept all connection requests. Save and apply the change. This is the field-proven fix that resolves the ERROR (5) / ERROR (3) pattern for installations where the LOGO! 8 is the client.
5. Reload the CMK2000. Power-cycle the CMK2000 so the new filter policy is enforced from a clean state. Wait ~60 s for the gateway to finish its boot and self-test.
6. Direct-connect test. If the diagnostic page still shows ERROR (5) / ERROR (3), connect the CMK2000 directly to the LOGO! 8 with a single patch cable (no switch, no VLAN trunk in between). Repeat step 4. If the link comes up in this configuration, the original failure is a Layer-2 / VLAN / switch timeout problem — see section 6.
7. Place both endpoints in a private VLAN. Configure a dedicated VLAN on the access switch (recommended: VLAN ID outside the IT range, e.g., VLAN 900) and assign only the CMK2000 port and the LOGO! 8 port as untagged members. Disable IGMP/MLD snooping on that VLAN to prevent premature pruning of the CMK2000 multicast traffic.
8. Verify with section 7.

6. Network Architecture: VLAN and Direct-Connect Trade-offs

The CMK2000 and the LOGO! 8 communicate using a Siemens-proprietary discovery + S7/LOGO! transport. The protocol relies on broadcast/multicast for the initial discovery phase and on TCP for the steady-state session. The two architectures observed in production are summarized below.

7. Verification and Commissioning Tests

After the recovery procedure, validate that the gateway is healthy. Each check has a pass criterion.

1. Diagnostic web page. Open the CMK2000 page. All three states should report CONNECTED (1). Device Status = ERROR (5) and LOGO! Connection Status = ERROR (3) must be gone.
2. LOGO! Soft Comfort online view. In LOGO! Soft Comfort, open the online connection to the LOGO! 8 CPU and verify that the CMK2000 appears in the Ethernet nodes list with a steady green state.
3. ETS group object traffic. From ETS (Engineering Tool Software), download the project and watch the KNX group objects associated with the LOGO! 8 inputs/outputs. Toggle a LOGO! 8 input from the LOGO! display and confirm the corresponding KNX group object updates inside one second.
4. Soak test. Leave the link running for at least 4 hours (longer than the documented 2-hour timeout). If the gateway survives 24 h without re-reporting ERROR (5) / ERROR (3), the timeout symptom is resolved.

8. Firmware Update Path

Siemens publishes firmware for the LOGO! 8 communications modules through the official product support portal. The CMK2000 firmware is delivered as a signed image that the module's own web interface can apply via the Firmware Update page.

1. Identify the current firmware on the CMK2000 web page (typically reported under Device Information).
2. Open the Siemens Industry Online Support portal and search for the CMK2000 article entry. Download the firmware package that matches the module's hardware revision.
3. From the web UI, navigate to the firmware update page and upload the image.
4. Wait for the gateway to reboot and verify against section 7.

9. Troubleshooting Matrix

10. Safety and Operational Notes

• Always power-cycle the CMK2000 after a configuration change. Some settings (notably the Dynamic Server IP Filter) only take effect on a clean boot.
• Document the LOGO! 8 IP, the CMK2000 IP, and the VLAN ID on the cabinet drawing. Future maintenance will rely on this.
• If the gateway is part of a life-safety or smoke-control KNX segment, perform the firmware update and the filter change during a planned maintenance window. The CMK2000 reboot will interrupt the LOGO! 8 ↔ KNX bridge for ~30 s.
• Keep a console cable or a laptop with a static IP in the same subnet as the CMK2000 for emergency recovery. If the IP filter policy is changed to a restrictive mode after the fact, the diagnostic web page may become unreachable.

11. Frequently Asked Questions