-1

Our peripheral device must stay connected to a MQTT broker and wait to receive a publish and immediately react to it.

Using WiFi connection, the goal is reached.

Using the GSM modem GL865 Telit, setting MQTT PING = 30 minutes (because we want to save as much money as possible) we have this repeating situation:

  1. on the peripheral, the status of the TCP socket is "online"
  2. after ~ 20 mins, we write on a topic that the peripheral subscribed to
  3. the broker finds out that the socket is "in error" and disconnects
  4. but the peripheral doesn't know or receive any indication of socket error
  5. the peripheral wait until PING time is reached
  6. then try to PING but finally detects a TCP socket error and proceed to reconnect

if we use a 1 minute PING, the problem doesn't happen because there is simply no time enough for it to happen.

We think that the problem involves telephonic providers, in particular a few ones. By simply changing the SIM, with a few providers the problem happens more than others.

Is someone experiencing the same problem?

1 Answers1

1

The GL865 has a socket timeout, by default, of 120 seconds if I remember correctly. If there is no data or the socket is otherwise not updated, the socket will unbind and your code will find out the hard way as you are experiencing. I think you can bump it up to something like 5 minutes, but your CSP will also have a 'stale connection' timeout of some sort as well. Either way, 30 min is way way too long for a GSM connection.

On a side note: GSM IoT devices are usually used to SEND data, not receive and act on the data...at least not with MQTT in my experience. Its great for sending data from sensors that are too far away for Wifi or LoRA, but as you are finding out, not good at staying connected for incoming data. For those use cases, I almost always use a polling/queue arrangement where the device wakes up, polls for any incoming messages, then disconnects. This can be done with MQTT if you set the RETAIN flag on the publish and the amount of packets being published is relatively low.

JD Allen
  • 799
  • 5
  • 12