Shop floor device connections timeout to cloud MQTT broker after 30 seconds

MES Siemens Opcenter Execution
, , , , , , , ,
1

We recently migrated our shop floor control module to Opcenter Execution 4.2 cloud deployment and are experiencing intermittent connection timeouts from our barcode scanners and weight scales to the cloud MQTT broker. Devices connect initially but drop after 30 seconds with no error logged on the device side.

Our MQTT configuration shows port 8883 for TLS connections, and we’ve verified the TLS certificate is properly installed on the broker. However, I’m concerned about the network security rules between our on-premise shop floor and the cloud instance.


mqtt.broker.url=ssl://opcenter-cloud.region.azure.net:8883
mqtt.client.timeout=30000
mqtt.keepalive.interval=60

Has anyone dealt with similar timeout issues in a hybrid cloud deployment? The devices work perfectly in our test environment but fail in production.

2

I work on the infrastructure side and can confirm that Azure NSG rules are often the culprit. Beyond just allowing port 8883, you need to ensure that your service tags are correctly configured for Azure IoT services. Also check if you have any route tables that might be sending MQTT traffic through a network virtual appliance that’s inspecting and dropping packets. We’ve seen stateful firewall devices terminate MQTT connections when they don’t recognize the protocol pattern.

3

Excellent troubleshooting! Let me provide a comprehensive solution summary for anyone encountering similar MQTT timeout issues in Opcenter cloud deployments.

MQTT Port Configuration: First, verify your cloud network security configuration allows bidirectional traffic on port 8883 (or 1883 for non-TLS). In Azure, this means both inbound and outbound rules in your Network Security Group. Don’t rely on default “allow all outbound” rules - explicitly define the MQTT ports. Also check for any Service Tags that might override your custom rules.


# Recommended MQTT client settings for cloud:
mqtt.client.timeout=60000
mqtt.keepalive.interval=45
mqtt.connection.retry=3

TLS Certificate Validation: Ensure your MQTT broker presents a complete certificate chain including intermediate CAs. Verify this using:


openssl s_client -connect opcenter-cloud.region.azure.net:8883 -showcerts

The output should show the full chain. If devices have embedded certificate stores, ensure the root CA is present. For older industrial devices, you may need to disable TLS 1.3 and stick to TLS 1.2 with compatible cipher suites.

Network Security Rules: Beyond NSG rules, investigate:

  1. Route tables - ensure MQTT traffic isn’t routed through inspection appliances
  2. Corporate proxies - many transparent proxies break MQTT/TLS connections
  3. Stateful firewalls - configure application-aware rules for MQTT protocol
  4. ExpressRoute/VPN MTU settings - fragmented packets can cause timeouts

For hybrid deployments, I recommend setting up a dedicated network path for shop floor IoT traffic that bypasses standard corporate security layers. Use a separate VLAN with optimized routing to your cloud MQTT endpoint.

Also consider implementing MQTT connection monitoring with reconnection logic in your device firmware. The Opcenter cloud MQTT broker supports persistent sessions, so devices can reconnect without losing queued messages.

4

One thing to add - make sure your MQTT keep-alive interval (currently set to 60 seconds) is properly negotiated with the broker. If the broker has a lower maximum keep-alive configured, it might be silently rejecting your connection parameters. Also, that 30-second client timeout seems low for cloud connections with potential latency. I typically use at least 60 seconds for timeout in hybrid deployments.

5

I’ve seen this exact behavior before. The 30-second timeout is a strong indicator that your firewall or security group rules are blocking the MQTT keep-alive packets. Check if your cloud provider’s network ACLs allow bidirectional traffic on port 8883, not just inbound connections. Also verify that your on-premise firewall isn’t dropping long-lived connections.

6

Thanks for the quick response. I checked our Azure network security group and found that while inbound 8883 is allowed, there’s a default rule blocking certain outbound ranges. I’ve opened a ticket with our network team to review the bidirectional rules. In the meantime, are there any MQTT client settings I should adjust to help diagnose this further?

7

Update: Our network team found the issue was a combination of problems. The NSG rules were blocking return traffic, and our corporate proxy was interfering with the TLS handshake. We’ve resolved both and connections are stable now. Thanks everyone for the pointers!