AWS IoT connection between server and device get a lot of [disconnected] events and device is not receiving delta messages.
I am using AWS IoT to allow a secure communication between a self written "Controller" (running with AWSIoTPythonSDK in version 1.4.0 on a raspberry pi, connected by LTE stick) and some AWS lambda funcions (using node with npm package aws-sdk in version 2.411.0). The setup is working in general, so delta messages are handled and shadow state is updated from time to time.
I used default configuration from python-iot-sdk example as initial configuration:
myAWSIoTMQTTShadowClient = AWSIoTMQTTShadowClient(self.clientId)
myAWSIoTMQTTShadowClient.configureEndpoint(self.host, self.port)
myAWSIoTMQTTShadowClient.configureCredentials(self.rootCAPath, self.privateKeyPath, self.certificatePath)
# AWSIoTMQTTShadowClient configuration - from AWS example
myAWSIoTMQTTShadowClient.configureAutoReconnectBackoffTime(1, 32, 20)
myAWSIoTMQTTShadowClient.configureConnectDisconnectTimeout(15) # 10 sec
myAWSIoTMQTTShadowClient.configureMQTTOperationTimeout(10) # 5 sec
Unfortunately a lot of shadow updates in AWS are not recognised by the Controller, eg. no information about new delta messages are logged.
I already tried different timeout settings, with enabled and disabled OfflinePublishQueue but without really find a configuration that allows a stable usage.
I do get many logging about disconnect events on client side:
2019-06-02 14:03:03,933 AWSIoTPythonSDK.core.protocol.internal.workers - [DEBUG] - Produced [disconnect] event
2019-06-02 14:03:03,933 AWSIoTPythonSDK.core.protocol.internal.workers - [DEBUG] - Dispatching [disconnect] event
2019-06-02 14:03:04,333 AWSIoTPythonSDK.core.protocol.connection.cores - [DEBUG] - backOff: current backoff time is: 32 sec.
Also the corresponding MQTT topic $aws/events/presence/disconnected/<clientId> shows a lot of connection/disconnections going on (using AWS IoT Test menu).
I really have no further idea how to get a more stable connection, GSM signal is good and we already had a better connection quality in an earlier version of the controller. As long as nearly 30% of the messages are not received by the device, the whole setup is not working.
