LOGO! CMR2020 Troubleshooting Resolving Email and WBM HTTPS

Problem Details: CMR2020 Mobile Data, Email, WBM, and GPS Symptoms

The Siemens LOGO! CMR2020 (Article Number 6GK7 142-7BX00-0AX0) is a 4G/2G mobile wireless communication module used to bridge a LOGO! 8 base module (BM) to a cellular network for SMS alarming, e-mail notifications, GPS positioning, and remote Web-Based Management (WBM). A typical field complaint involves a partially functional unit: SMS sending/receiving works, the cellular link is established, signal strength reads in a normal range, but e-mail transmission, HTTPS WBM access, or GPS satellite acquisition silently fail.

Concrete indicators recorded in this case:

• Hardware product version: 2
• Firmware: V2.2.9
• Mobile wireless module firmware: 13.00.106
• SIM: Play (Poland), 2G verified in a phone, APN string internet
• Signal: 28 / -57 dBm (CSQ scale 0-31; RSSI derived from CSQ)
• GPS antenna: ANT895-6ML, mounted indoors
• Diagnostic buffer entry: Sending e-mail failed. Last reply from server 0. Internal error identifier: 7. Number of attempts: 1 (later variant: identifier: 28)
• WBM over HTTPS unreachable from the public Internet

These four symptoms — failed SMTP, unreachable WBM, no GPS fix, healthy SMS — share one root cause pattern: outbound TCP from the CMR to the public Internet is not completing a TLS handshake, while UDP/GSM control plane services still work.

CMR2020 Architecture and Cellular Data Path

The CMR2020 terminates an Ethernet link to a LOGO! 8 BM and brings up a 4G LTE/2G GPRS cellular connection through a Sierra Wireless cellular engine. Its internal logical stack is:

1. BM (LOGO! 8) <-> Ethernet <-> CMR2020 LAN side
2. CMR2020 WAN side <-> SIM authentication <-> APN context <-> cellular packet core
3. CMR applications: SMS, e-mail (SMTP/SMTPS), WBM (HTTP/HTTPS), GPS (NMEA over CMR diagnostic frame), time sync (NTP)

Once the diagnostic buffer reports Connection to the mobile wireless network established followed by Mobile data service ready, the PDP context is active. That alone is not sufficient to prove end-to-end IP reachability; it only proves the radio link and APN attach succeeded. TCP-based services may still fail on TLS negotiation, MTU, or provider firewall rules.

Root Cause Analysis of E-mail Internal Error 7 and 28

The diagnostic message Last reply from server 0 is the CMR's way of stating that the SMTP server reply buffer is empty when the transaction closes. Internal error identifier: 7 and identifier: 28 map onto the internal state machine of the mail client task: no banner was received (connection refused, blocked, or timed out before any SMTP greeting). In practice the same identifiers also surface when the client TCP connect succeeds, the 220 greeting arrives, but the EHLO/STARTTLS exchange terminates with no data line in the response buffer.

Polish consumer APNs (Play internet, Plus internet, Orange internet, T-Mobile internet) historically block outbound TCP/25 (SMTP), TCP/465 (SMTPS implicit TLS), and on some APNs also TCP/587 (SMTP submission) to curb spam. SMTP submission on port 587 with STARTTLS is the most commonly reachable option. This is the change that resolved the case.

Solution Step 1 — Reconfigure SMTP Port to 587 with STARTTLS

The CMR2020 WBM exposes the mail account under Functions > E-mail. Replace the port with 587 and enable STARTTLS. Most residential and free webmail providers publish the following working settings:

Configuration procedure:

1. Open WBM of the CMR2020 from the LAN side (default https://192.168.0.100 or DHCP-learned address).
2. Navigate to Functions > E-mail.
3. Set Outgoing mail server (SMTP) to the provider's submission host.
4. Set Port to 587.
5. Set Encryption to STARTTLS (or SSL/TLS if 465 is chosen and reachable).
6. Enter user name (full e-mail address) and password; for Gmail, generate an App Password under the Google account security settings — plain account passwords are rejected for IMAP/SMTP/POP when 2FA is enabled.
7. Save and trigger a test e-mail from Diagnostics > E-mail test.

After the change in this case, the diagnostic buffer stopped reporting identifier 7/28 and a test mail was delivered.

Solution Step 2 — Enable WBM HTTPS via a Publicly Reachable IP

The CMR HTTPS WBM is a server service, so it is reachable only if the cellular provider assigns a public, inbound-routable IPv4 address. Default consumer APNs place the CMR behind carrier-grade NAT (CGN), which is why https://<wan-ip> never answers from the public Internet.

Available remedies:

1. Public APN / business tariff. Request a SIM with a public, static IPv4 address (often a separate APN, e.g. internet.public, static). The CMR WAN IP is then directly reachable.
2. VPN tunnel. Configure an IPSec or OpenVPN client on the CMR (firmware-dependent) or on a downstream router so the WBM rides inside an encrypted tunnel to a known endpoint.
3. Reverse tunnel / MQTT bridge. Replace direct WBM access with a cloud broker (Siemens LOGO! CMR supports the SINEMA Remote Connect / AWS IoT MQTT profile on newer firmware). The WBM is then accessed via the broker, not via direct HTTPS.
4. SMS-only operation. Disable HTTPS WBM if the application only needs remote alarming. Functions > Services > Web server > HTTPS access can be turned off, and SMS acts as the remote I&M channel.

Solution Step 3 — GPS Fix Requires Outdoor Antenna Placement

The ANT895-6ML is an active GNSS antenna. Indoor attenuation from concrete, foil-backed insulation, and low-E glass routinely exceeds 20-30 dB, dropping satellites below the CMR's tracking threshold. The diagnostic buffer only reports GPS active, not GPS fix; the user must check the coordinates in Diagnostics > GPS or in the LOGO! BM tag VW mapped to GPS lat/long.

1. Mount the ANT895-6ML with a clear sky view, ideally on a metallic ground plane of at least 70 x 70 mm.
2. Keep the antenna cable run short; ANT895-6ML is specified to work with the supplied pigtail length only.
3. Verify Diagnostics > Information > GPS shows latitude/longitude with non-zero digits and a UTC time stamp within the last second.

Diagnostic Buffer Walkthrough

The CMR2020 maintains a ring buffer in Diagnostics > Information > Log table. Reading the buffer chronologically is the fastest way to localize a fault.

Because NTP works at the same moment SMTP fails, the IP path is open. The failure is therefore application-level (port 465 blocked or TLS rejection), not network-level.

Signal Strength and CSQ Interpretation

The reported 28 / -57 dBm is the CSQ (0-31) reading and a derived RSSI. Mapping per the 3GPP TS 27.007 AT+CSQ convention:

CSQ 28 maps to roughly -57 dBm, which is a strong signal. The link budget is not the cause of e-mail failure.

APN Configuration and Carrier Constraints

The CMR2020 reads the APN from the SIM profile. With Play (Poland), the standard consumer APN is internet with no user/password. The CMR can be forced to a custom APN in Functions > Mobile wireless if a business APN is supplied by the operator. Confirm the APN by issuing the equivalent of the AT command AT+CGDCONT? through the WBM diagnostic page; the response should include the PDP type IP or IPV4V6 and the APN string.

Firmware and Compatibility Notes

The combination in this case — CMR FW V2.2.9 with cellular module firmware 13.00.106 — is in field service for several European MNO SIMs. When you cannot change the SMTP port behavior, consider the following:

• Upgrade to the latest CMR FW listed on the Siemens Industry Online Support portal for hardware product version 2. Newer firmware releases add TLS profile updates and additional SMTP error logging that can disambiguate identifier 7 from identifier 28.
• If the cellular module firmware is older than the FW bundle expects, flash both together; mismatched module firmware can produce subtle TCP issues.
• Check the LOGO! BM and LOGO! Soft Comfort project for the CMR e-mail trigger block; a misconfigured tag map will trigger e-mails with empty bodies and may be reported as send failures by the CMR.

For the official equipment manual covering the WBM, the diagnostic buffer, the e-mail and SMS configuration screens, refer to the LOGO! CMR2020 / CMR2040 Equipment Manual (PDF).

Verification: End-to-End Checklist

1. Send a test e-mail from Diagnostics > E-mail. The diagnostic buffer should show a 250 OK line; no identifier 7/28 should appear.
2. Trigger a LOGO! BM alarm in the program. Confirm the alarm e-mail arrives at the configured recipient within 30 s.
3. From a host on the public Internet, open https://<CMR public IP> — only valid if a public APN is in use; otherwise rely on SMS or SINEMA Remote Connect.
4. Send an SMS to the CMR. The diagnostic buffer should record SMS received and the configured output should toggle in the LOGO! BM program.
5. In Diagnostics > GPS, confirm valid latitude/longitude and a fresh UTC timestamp. Sat count should be >= 6 for a stable fix.
6. Re-check CSQ. Anything above 10 is acceptable for 2G, above 14 is acceptable for LTE Cat-1.

Troubleshooting Matrix

FAQ