Resolving LOGO! 8.3 LWE to AWS Connection Failures

Problem Description: LOGO! 8.3 LWE to AWS Outage

Operators of Siemens LOGO! 8.3 logic modules that publish data through the LOGO! Web Editor (LWE) to Amazon Web Services report that cloud dashboards, push notifications, and remote control functions stop working without any change to on-site hardware or firmware. Typical symptoms include:

• LOGO! Web Editor project loads locally on a PC, but cloud data variables remain OFFLINE.
• LOGO! BM status LED pattern returns to normal (no SF/RDY fault), indicating the base module is healthy.
• AWS IoT Core shadow document or REST endpoint does not receive updates from the LOGO! even though PING from the LOGO! BM to a public DNS server succeeds.
• Web Editor Cloud tab shows a status banner such as "Cloud connection not available", "AWS subscription expired", or "Token rejected".

The failure is not caused by a defect inside the LOGO! 8.3 base module. The fault lies in the cloud-side dependencies that the LWE project binds to when it is published. Three categories of change account for nearly every reported outage: (1) AWS deprecating TLS cipher suites, API versions, or endpoint hostnames, (2) expiration of the IAM access key or X.509 device certificate embedded in the LWE cloud profile, and (3) NTP drift that invalidates the certificate chain on the LOGO!.

LOGO! 8.3 Cloud Architecture Overview

Understanding the data path is essential before changing any parameter. The LWE does not stream variables directly from the LOGO! base module to AWS. Instead, the path is:

1. LOGO! BM runs the user program (circuit diagram) and exposes variables over the integrated Ethernet port using the LOGO! webserver protocol on TCP/80 (HTTP) or TCP/443 (HTTPS).
2. LOGO! Web Editor runtime runs on a Windows PC or on a LOGO! CMR (Communication Module) acting as a host, polls the LOGO! BM using S7-compatible symbols, and republishes the data.
3. The LWE cloud connector forwards those variables to AWS using HTTPS, either through AWS IoT Core (MQTT over WebSockets) or through an Amazon API Gateway REST endpoint configured during project publishing.
4. The AWS backend stores data, triggers Lambda functions, or relays to a customer dashboard.

Any change at the Edge or Cloud layer that is not propagated to the LWE cloud profile produces the "worked until the end of August, now not anymore" failure pattern that operators most often describe. The remaining sections walk through each layer in order.

Root Cause Analysis: Common Failure Modes

Review the matrix below before changing any configuration. Each row describes one root cause, the indicator that distinguishes it, and the corrective action. Match your symptoms to one row first; if multiple apply, fix them in the order listed.

Prerequisites for Reconnection

Before opening the LWE project, gather the following. Without these items, reconnection attempts will fail repeatedly and obscure the true root cause.

1. LOGO! BM access: admin password for the LOGO! 8.3 webserver (the password you set under Tools > Ethernet > Access Control in LOGO! Soft Comfort, or the default if you have not changed it).
2. LOGO! Soft Comfort V8.3 or later installed on the engineering PC, with the matching cloud project (the .lsc file containing the cloud block and the AWS access key).
3. LOGO! Web Editor runtime running on the same PC or on a LOGO! CMR2020/CMR2040 module, version compatible with the LOGO! 8.3 firmware.
4. AWS account access: IAM user with permission to read/write the relevant IoT thing, the certificate, and the policy. Multi-factor authentication token if required.
5. Network reachability: an engineering PC that can reach the LOGO! BM on its IP address, reach the public Internet on TCP/443, and resolve public DNS names.
6. Reference timestamp: a known-good time source (NTP server, smartphone, or time.gov) to validate the LOGO! BM clock after reconnection.

If any prerequisite is missing, resolve it first. A common field mistake is to test cloud connectivity from a PC that cannot itself reach the LOGO! BM — the failure is then attributed to AWS when it is in fact a local routing problem.

Step-by-Step Reconnection Procedure

Execute the steps below in the order shown. Each step includes a verification check before moving to the next.

Step 1 — Verify LOGO! BM health

1. Open a browser and navigate to http://<logo-ip>.
2. Confirm the LOGO! webserver loads and that all variables read as expected.
3. Navigate to Status and record the firmware version, the current date/time, and the active NTP server.
4. If the date/time is off by more than 60 seconds, set a reachable NTP server under Tools > Ethernet > NTP and wait one polling interval before continuing.

Step 2 — Verify network path to AWS

1. From the LWE host, open a command prompt and run nslookup <aws-iot-endpoint>. The endpoint format is <prefix>-ats.iot.<region>.amazonaws.com.
2. Run curl -v --max-time 10 https://<aws-iot-endpoint>/. A TLS alert, a 403, or a redirect is acceptable; a Connection timed out or No route to host indicates a firewall problem on TCP/443.
3. If the LWE host sits behind a corporate proxy, set the proxy in Windows Settings > Network & Internet > Proxy and re-run the test. For cross-checking, the AWS Fix EC2 Connection Errors walkthrough demonstrates the same connection refused vs. connection timed out distinction that applies to any AWS endpoint.

Step 3 — Re-issue or refresh the AWS IoT certificate

1. Open the AWS IoT console and navigate to Manage > Things.
2. Select the thing associated with the LOGO! LWE project.
3. Under Security > Certificates, check the expiration date. If expired or expiring within 30 days, create a new certificate, download the certificate, the private key, and the Amazon Root CA.
4. Replace the certificate, key, and root CA files in the LWE cloud profile directory (default %LOCALAPPDATA%\Siemens\LWE\cloud on Windows, or /var/siemens/lwe/cloud on a LOGO! CMR).
5. Attach the existing IoT policy (or a new one granting iot:Connect, iot:Publish, iot:Subscribe, iot:Receive) to the new certificate.

Step 4 — Refresh the IAM credentials used by the LWE

1. Open the AWS IAM console.
2. Select the IAM user (or role) named in the LWE cloud profile.
3. Generate a new access key; deactivate the old key after the new one is confirmed working to avoid orphan credentials.
4. In LOGO! Soft Comfort, open the cloud project and re-enter the access key ID and secret access key under Cloud > AWS > Credentials. Do not edit the certificate fields — those are separate from the IAM key.
5. Republish the project to the LOGO! BM and the LWE runtime.

Step 5 — Validate the LWE cloud connection

1. Open the LOGO! Web Editor runtime and load the published project.
2. Switch to the Cloud tab.
3. Confirm the status indicator turns green within 30 seconds and that the variable list begins updating.
4. In the AWS IoT console, open Test > MQTT test client, subscribe to the topic pattern configured in the LWE project, and confirm messages are arriving.

If the status indicator does not turn green, capture the LWE runtime log (default location: %LOCALAPPDATA%\Siemens\LWE\logs\lwe-runtime.log) and proceed to the diagnostics section.

AWS Service Health and API Verification

Before changing the LOGO! configuration, verify that the AWS service itself is healthy and that the endpoint you are using is still active. AWS publishes a public health dashboard and an API/service inventory that change without notice.

1. Open the AWS Service Health Dashboard and confirm that AWS IoT Core, Amazon API Gateway, and IAM report No issues in the region hosting your endpoint.
2. Cross-check the AWS Knowledge Center for any active incident affecting the same service in the same region.
3. Confirm the IoT data endpoint format. For shared (multi-tenant) endpoints the format is <prefix>-ats.iot.<region>.amazonaws.com:443/mqtt. For account-specific endpoints the format is <account>-ats.iot.<region>.amazonaws.com:443/mqtt. If the project references an old iot.us-east-1.amazonaws.com style hostname (without the -ats suffix) it must be updated.
4. Confirm the AWS account itself is still active. A suspended account returns 403 on every API call, and the LWE has no way to distinguish a suspended account from a credential failure. Check AWS Account > Alternate contacts > Account status in the AWS console.

Network and DNS Diagnostics

If the AWS service is healthy but the LWE still cannot reach it, the fault is in the network path. The most efficient sequence is to bisect the path with three commands on the LWE host.

1. DNS resolution: nslookup <aws-iot-endpoint>. If this fails, change the DNS server in the LWE host network adapter to a public resolver such as 8.8.8.8 or 1.1.1.1 and retry.
2. TCP reachability: Test-NetConnection <aws-iot-endpoint> -Port 443 on Windows PowerShell, or nc -vz <aws-iot-endpoint> 443 on Linux. A TcpTestSucceeded : True (PowerShell) or succeeded! (nc) confirms the path is open. A timed out indicates a firewall or routing problem.
3. TLS handshake: curl -v --max-time 10 https://<aws-iot-endpoint> -o nul. A successful TLS handshake with an HTTP 403 or 404 response is good — it means the network and TLS are working and the request simply is not authorized. A handshake failure (no HTTP response, error 35 or 60) means TLS configuration is wrong; the most common cause in late 2023 onward is the AWS endpoint requiring TLS 1.2 minimum.

If the diagnostic stops at step 2, open a ticket with the local network administrator and request that TCP/443 outbound to the AWS regional endpoint IP ranges be permitted. The current set of AWS IP ranges is published as a JSON file at AWS IP ranges; download it and filter for the AMAZON, EC2, S3, and ROUTE53 prefixes for the relevant region.

LOGO! 8.3 Configuration Parameters

The LOGO! 8.3 webserver exposes a small set of parameters that affect cloud connectivity. Review them on the BM web UI under Tools > Ethernet and confirm each value.

If any value is missing or empty, the LWE will fall back to defaults that may not match the site network. The most common field mistake is an empty DNS server, which causes the LOGO! to send DNS queries to its own gateway, which often is not a recursive resolver.

Alternative Cloud Connectivity Options

Because AWS endpoints and IAM conditions are outside Siemens control, sites that require long-term stability should evaluate an alternative cloud path. The following options are supported by the LOGO! 8.3 platform without a firmware upgrade.

For new installations, the vendor-neutral MQTT path offers the best ratio of effort to longevity, because the LOGO! BM speaks HTTP natively and an MQTT-over-WebSocket bridge can be implemented on any small Linux host. For existing AWS-bound sites, the OpenVPN path through a LOGO! CMR2020/CMR2040 module preserves the AWS endpoint while removing the LWE as a single point of failure.

Long-Term Reliability Considerations

Cloud connectivity for embedded controllers depends on three contracts that are all outside the controller manufacturer's control:

1. TLS and cipher contracts: AWS and other public clouds periodically retire TLS versions and cipher suites to comply with evolving security baselines. A controller that pins a specific TLS version will eventually fail.
2. Authentication contracts: IAM access keys expire, IoT certificates expire (default 1 year for AWS IoT, 5 years for some configurations), and Cognito identity pools can be deprecated without notice.
3. Endpoint contracts: AWS regional endpoints can be retired, renamed, or have their protocol requirements tightened.

Mitigations that a system integrator can apply at deployment time:

• Subscribe to the AWS IoT blog RSS feed and the AWS service endpoints documentation for the regions in use.
• Set calendar reminders 30 days before each IoT certificate expiration to rotate certificates before they expire.
• Where possible, use IAM roles with short-lived credentials (STS) instead of long-lived access keys.
• Document the cloud dependency in the project handover package, including the AWS account ID, the IAM principal ARN, the IoT thing name, and the certificate thumbprint.
• Maintain a fallback manual control path on the LOGO! itself (physical pushbuttons feeding digital inputs to the cloud-published variables) so that a cloud outage does not disable the physical process.

Verification Checklist

Use this checklist to confirm the cloud path is fully restored before closing the incident.

Frequently Asked Questions