Configuring Siemens LOGO! 8.4 AWS IoT Cloud Connection

Overview

Siemens LOGO! 8.4 (series 0BA8, base units 6ED1052-1MD08-0BA1, 6ED1052-1HB08-0BA1, 6ED1052-1FB08-0BA1) publishes variables from the LOGO! Soft Comfort (LSC) project directly to AWS IoT Core over MQTT 3.1.1 / TLS 1.2 using a 4-byte MQTT header plus a JSON shadow payload. The "LWE" pages you build in the LOGO! Web Editor are stored on the LOGO! microSD card and rendered by the LOGO! onboard web server; the cloud publishing channel runs in parallel and does not require the LOGO! CMR2020 cellular router module. This guide replaces the retired 2018 Siemens "LOGO! goes cloud" video and the older LOGO! CMR setup wizard (deprecated with CMR firmware 2.1.x).

The total configuration is split between two consoles: AWS IoT Core (IAM user, thing, certificate, policy, endpoint) and the LOGO! Web Editor / LSC project (network, DNS, thing name, certificate files on SD). When the SD is inserted into the LOGO! base unit and the network is online, the LOGO! performs an MQTT CONNECT with the thing's X.509 client certificate, subscribes to $aws/things/<thingname>/shadow/update/accepted and publishes state changes to $aws/things/<thingname>/shadow/update. The AWS IoT MQTT test client must see messages on this topic for the configuration to be considered valid.

Prerequisites

LOGO! 8.4 Hardware Identification and Firmware Verification

Before touching AWS, confirm the LOGO! 8.4 is on a firmware that contains the MQTT 3.1.1 cloud client. Connect to the LOGO! onboard web server at http://<logo-ip>, log in with the Web Server password (default: LOGO; change it on first login), and open Tools > Device Information. The reported firmware string must read V9.0.x or higher. If the string is V8.4.x, download the ES 9 firmware update package from the Siemens Industry Online Support portal and apply it before continuing. The update is staged through the LSC Tools > Firmware Update menu and requires the LOGO! to reboot twice; allow 90 seconds for the full process.

Downgrades below ES 9 are not supported and will brick the cloud channel until the upgrade is re-applied. The 0BA8 hardware revision printed on the base unit nameplate must be at least FS03; FS01 and FS02 do not have the cryptographic accelerator needed for the TLS 1.2 handshake with the ATS root CA at the required sub-300 ms latency.

AWS IAM User and Policy Setup

Sign in to the AWS Management Console as an IAM administrator and open the IAM console. Create a new user named logo-cloud-operator with Programmatic access and an initial password. In the Set permissions step, choose Attach existing policies directly and add the four managed policies below. Skip the group, tags and review steps until the policies are listed in the user summary.

After creation, copy the Access Key ID and Secret Access Key into a password manager. The user only needs these for the one-time provisioning script in the next section; the LOGO! itself authenticates with the X.509 thing certificate, not the IAM user.

AWS IoT Core Thing and Certificate Creation

1. Open the AWS IoT console in the target region. From the left navigation, choose Manage > All devices > Things, then Create things.
2. Select Create single thing. Enter a Thing name that matches the LOGO! project (e.g. LOGO8_PlantA_Line3). Thing types are optional, but if you intend to use AWS IoT Fleet Indexing later, create a thing type now and attach it. Click Next.
3. On the Device certificate step, choose Auto-generate a new certificate (recommended). Click Next.
4. On the Policies step, click Create new policy. Name it LOGO8_PublishSubscribe and paste the JSON document from the next section. Attach the policy to the certificate. Click Create thing.
5. On the final confirmation page, download all four artefacts: the device certificate (xxx-certificate.pem.crt), the private key (xxx-private.pem.key), the public key (xxx-public.pem.key) and the Amazon Root CA 1. The Root CA is also available at amazontrust.com/repository/AmazonRootCA1.pem. Store these files in a safe directory — the private key is shown only once and cannot be re-downloaded.

If the certificates are not visible on the final page, navigate to Manage > All devices > Certificates, find the certificate ARN matching the thing, and verify the certificate status is Active. The LOGO! TLS handshake fails with CONNACK 0x04 ("Credential Error") if the certificate is in the PENDING_ACTIVATION state. The certificate must also be attached to the thing; if the policy is on the IAM user but not on the certificate, the data plane rejects every MQTT packet with CONNACK 0x05.

AWS IoT Policy (Certificate-Attached)

This policy is attached to the thing's X.509 certificate. It is NOT the same as the IAM user policy. The LOGO! authenticates only with the certificate; the IAM user exists only to call the AWS IoT control plane during setup. Refer to the AWS IoT security and identity documentation for the full set of IAM actions and resources.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "iot:Connect",
        "iot:Publish",
        "iot:Subscribe",
        "iot:Receive",
        "iot:UpdateThingShadow",
        "iot:GetThingShadow"
      ],
      "Resource": [
        "arn:aws:iot:eu-central-1:123456789012:client/LOGO8_*",
        "arn:aws:iot:eu-central-1:123456789012:topic/$aws/things/LOGO8_*/shadow/*",
        "arn:aws:iot:eu-central-1:123456789012:topic/$aws/things/LOGO8_*/shadow"
      ]
    }
  ]
}

Replace eu-central-1 with the AWS region hosting the thing (for example eu-central-1, us-east-1, ap-northeast-1) and 123456789012 with the 12-digit account ID. The wildcard on the client ID is intentional; the LOGO! client ID is its serial number prefixed with the thing name. The wildcard on the topic ARN is intentional; it allows the LOGO! to publish to any shadow sub-topic without an extra policy edit.

AWS IoT Endpoint Discovery

Open the AWS IoT console, choose Settings in the lower-left, and copy the Device data endpoint. It will look like xxxxxxxxxxxx-ats.iot.eu-central-1.amazonaws.com. The -ats (Amazon Trust Services) suffix is mandatory for LOGO! firmware ES 9 — the legacy *.iot.<region>.amazonaws.com endpoint uses the VeriSign root and is rejected by the LOGO! TLS stack with CONNACK 0x01. See the AWS IoT endpoint configuration reference for the full list of regional endpoints.

Record four values for the LWE configuration: the endpoint, the thing name, the certificate ARN (visible under Manage > All devices > Certificates), and the AWS region string. The endpoint string must be copied exactly, including the -ats prefix; a single missing character causes the TLS handshake to fail with no log message on the LOGO! side.

LOGO! Web Editor (LWE) Project Setup

1. Open LOGO! Soft Comfort, open the existing .lsc project, and choose Tools > Web Editor. LWE opens as a separate application window docked to the LSC editor.
2. In the LWE project tree, add a new Web Variable for every LSC tag you intend to publish. The supported tags are: digital inputs I1–I24, digital outputs Q1–Q20, analog inputs AI1–AI8, analog outputs AQ1–AQ8, marker bytes M1–M64, network inputs NI1–NI64, and network outputs NQ1–NQ64. The web variable's address field is the LSC tag reference (e.g. AI1, Q1, VW0).
3. Drag the variables onto a page and bind them to widgets. Widgets that support cloud publishing carry a Cloud checkbox in the property pane; only widgets with the checkbox enabled are published. Boolean tags must use a Toggle or Indicator widget; analog tags must use a Numeric widget with the data type set to "Float" for AQ/AI, otherwise the JSON payload shows null.
4. Save the LWE project. LSC will copy the LWE files into the project's webpages/ directory. The Publish to LOGO! button transfers the LWE tree to the SD card if the card is mounted in the PC's SD reader; otherwise copy the directory manually.

SD Card Layout and config.json

The microSD card must contain two separate directory trees. The on-board web server reads /webpages/ for LWE rendering; the cloud client reads /cloud/ for certificates and configuration. Both directories are case-sensitive and must reside at the root of the FAT32 partition. The FAT32 allocation unit size must be 32 KB; the default Windows formatter selects 4 KB which causes an SD card wear fault after ~200 write cycles on consumer-grade media.

/<sd-root>/
├── webpages/
│   ├── index.htm
│   ├── logo_logo.gif
│   ├── logo_func.xml
│   └── ... (other LWE output)
└── cloud/
    ├── config.json
    ├── AmazonRootCA1.pem
    ├── <thingname>-certificate.pem.crt
    ├── <thingname>-private.pem.key
    └── update.json

Create config.json with the following content, replacing the placeholders with the values from the AWS IoT console. The JSON must use LF line endings; CRLF causes the LOGO! parser to reject the file silently.

{
  "endpoint": "xxxxxxxxxxxx-ats.iot.eu-central-1.amazonaws.com",
  "port": 8883,
  "clientId": "LOGO8_PlantA_Line3",
  "thingName": "LOGO8_PlantA_Line3",
  "publishTopic": "$aws/things/LOGO8_PlantA_Line3/shadow/update",
  "subscribeTopic": "$aws/things/LOGO8_PlantA_Line3/shadow/update/accepted",
  "keepAliveSec": 60,
  "qos": 1,
  "tls": {
    "rootCA": "AmazonRootCA1.pem",
    "cert": "LOGO8_PlantA_Line3-certificate.pem.crt",
    "key": "LOGO8_PlantA_Line3-private.pem.key"
  }
}

The update.json file is the cloud client state file; do not edit it manually. The LOGO! rewrites it on every successful publish and on every TLS handshake to record the last CONNACK code and the last successful publish timestamp. If update.json is missing, the cloud client falls back to a clean state on next boot.

Network and DNS Configuration on the LOGO!

On the LOGO! onboard web UI, open Network > Ethernet and confirm a static IPv4 address (DHCP works but is not recommended for the cloud client because IP changes drop the MQTT session and trigger a 30-second re-handshake window during which state updates are lost). Open Network > DNS and set the primary DNS to 8.8.8.8 and the secondary to 1.1.1.1. The LOGO! will only resolve the AWS endpoint hostname if the DNS server can reach the public internet; an internal-only DNS that cannot recurse to the root will cause the MQTT CONNECT to time out at 30 seconds with no error message in the LOGO! status page.

Open Network > Cloud and verify the four cloud parameters are read from the SD card (they appear in green when parsed correctly, red when a field is missing). If Network > Cloud is not visible, the firmware is below ES 9 — revisit the firmware step. The Network > Cloud page also reports the last 10 MQTT CONNACK codes; a code of 0x00 indicates success, any other code indicates a specific failure mode covered in the troubleshooting matrix below.

Verification

1. Insert the SD card into the LOGO! and power-cycle the base unit. Wait 30 seconds for the cloud client to negotiate TLS and complete the MQTT handshake.
2. Open the AWS IoT console in the same region, choose Test > MQTT test client, subscribe to $aws/things/LOGO8_PlantA_Line3/shadow/update/accepted with QoS 0, and watch the message list. The LOGO! publishes a retained shadow {"state":{"reported":{...}}} JSON within 10 seconds of the first successful publish. See the AWS IoT Device Shadows developer guide for the full shadow document schema.
3. In the LOGO! onboard web UI, open Diagnostics > Cloud Status. The "Last MQTT CONNACK" field must read 0x00 Connection Accepted and the "Last Publish" timestamp must be within the keepAliveSec window.
4. To verify bi-directional flow, change a state via the MQTT test client (publish to $aws/things/LOGO8_PlantA_Line3/shadow/update with {"state":{"desired":{"Q1":true}}}). Within 2 seconds, the LOGO! output Q1 must energise, and the LOGO! will publish a reported shadow back to the same topic.
5. To verify CloudWatch logging, open the CloudWatch console, choose Log groups, and look for a log group named /aws/iot/<thingname>. MQTT connect, disconnect and error events appear within 30 seconds of the corresponding MQTT packet.

Troubleshooting Matrix

Field-Proven Operational Notes

The LOGO! cloud client does not auto-reconnect after a WAN outage longer than the TLS session timeout (default 300 s). When the WAN returns, the LOGO! will perform a fresh CONNECT with the same clientId; the AWS IoT broker will return CONNACK 0x04 because the previous session still holds the clientId. The mitigation is to set the AWS IoT thing's "Device Shadow" client ID to a unique value per power-up — LOGO! does this automatically if the thingName field in config.json matches the serial number. If you changed the thingName to a friendly name, prepend the serial number to avoid session collisions. The LOGO! serial number is printed on the nameplate as a 16-character hex string starting with S.

The microSD card is the single point of failure. Industrial SD cards (Siemens 6ED1057-1AA01-0BA0 or similar) with a wear-leveling controller are recommended; consumer cards from phones will fail within 12-18 months in a 24/7 LOGO! installation due to the constant config.json rewrite during MQTT reconnection storms. The LOGO! does not log SD write errors to the cloud; the only symptom is silent publish gaps in the AWS IoT shadow history.

The cloud publish interval is governed by the LSC program's scan time, not the keepAliveSec. A 400 ms scan time yields 2.5 publishes per second, which is well below the AWS IoT soft limit of 100 publishes per second per thing. For most discrete-control applications the scan time of 50–100 ms is more than enough and the publish rate stays well below 10/s. If you need a higher publish rate, batch the variables in the LWE widget and use a single widget per page; this reduces the JSON encoding overhead per scan cycle.

Migration from LOGO! CMR2020 to Direct Connection

The LOGO! CMR2020 cellular router module and its cloud setup wizard were deprecated with CMR firmware 2.1.4 (released Q1 2023). New installations must use the direct Ethernet path described in this guide. For existing CMR2020 installations, the migration steps are:

1. Remove the CMR2020 from the LOGO! base unit and store it as a spare.
2. Connect the LOGO! Ethernet port directly to the plant LAN.
3. Provision a new AWS IoT thing with a new certificate and a new thingName (e.g. append _direct to the old CMR thingName).
4. Copy the new certificate files and config.json to the SD card's /cloud/ directory.
5. Decommission the old CMR thing by detaching its certificate and policy in the AWS IoT console.

The migration can be performed with zero downtime if the LAN switch supports LACP and the CMR2020 was in a failover role. For primary links, schedule a 15-minute maintenance window. The cellular bill from the mobile operator can be cancelled on the same day.

Security Hardening Checklist

• Rotate the thing certificate annually. The LOGO! supports a second certificate in config.json under the tls.cert2 key; swap the active cert and delete the old one from the AWS IoT console after a 7-day grace period.
• Enable AWS IoT Device Defender to monitor the LOGO! MQTT traffic. Set the alert threshold to 1,000 publishes/min; a stuck LOGO! scan loop will trip the alert within 30 seconds.
• Disable the LOGO! onboard web server from the public internet. Place the LOGO! on a private VLAN and use a jump host for remote access.
• Restrict the certificate policy to the exact thingName ARN, not the wildcard, once the LOGO! fleet is stable. The wildcard is convenient for development but should not ship to production.
• Enable CloudWatch Logs with a 30-day retention on the /aws/iot/<thingname> log group. Export the logs to S3 for long-term archival.

Standards and Protocol References

The LOGO! cloud channel uses MQTT 3.1.1 (OASIS Standard mqtt-v3.1.1-os) over TLS 1.2 (RFC 5246) with ALPN extension x-amzn-mqtt-ca. The certificate chain is X.509 v3 (RFC 5280). The JSON payload follows the AWS IoT Device Shadow document schema (see the AWS IoT Device Shadows developer guide). All policy documents are JSON conforming to IAM policy grammar (see the IAM policy grammar reference).

Comparison: Direct LOGO! Cloud vs LOGO! CMR2020

FAQ