Is there any more information on how losant uses MQTT under the hood wrt heart beat messages, commands, QoS, etc. I am looking to understand a few things:
- how many messages and what type of messages are being sent by edge devices (like LEA) so I understand better what the data consumption will be for a device that is on an LTE connection. For instance, are you sending heartbeat messages to verify if the connection is still alive? How often?
- How does losant detect edge devices going online/offline? If a device doesn’t update its state for a long while, how do you know its still online? Especially since you only support QoS 0, could it be that devices are actually offline because their network connection dropped, and they didn’t actively disconnect from the MQTT broker? I guess you are relying on the TCP connection and TCP ack messages, and TCP connection timeout to detect that a connnection to the broker dropped when a command is sent to an edge device? Would a TCP connection timeout trigger the device going offline in the cloud? And on the edge device itself? What are the connection timeouts that are being used for this? Since this is all stuff that losant takes care of for the users internally, I would be interested to know how you handle this stuff under the hood, so I can understand the consequences on the reliability of commands being sent to devices, and state being sent from devices.
- Do you have a write-up somewhere how to handle connection reliability in general. I know there are docs on individual nodes that help with this (like state inactivity timer), or for instance documentation about what parts of the MQTT protocol are supported, but an article piecing together the bigger picture and describing common design patterns to help with this would be useful. Things I would be interested would be: how do I know whether commands have been received by edge devices? How do I make sure from the cloud that any commands that weren’t received by an edge device, get re-sent once they reconnect? And on the edge device: if I send the state over MQTT, how do I make sure the state commands are being received by the broker (aka, how do I setup QoS1 for publishing state messages on losant edge workflows)? Is there a common design pattern in losant to make sure that past state messages that haven’t been received by the broker get sent as soon as a connection comes back? How quickly can I detect on the edge side the network connectivity has dropped to go into a fail-safe state, and snap out of it when the connection comes back.
- The question has been asked many times, but there seems no real activity as far as I can see on the product side: what is the status of supporting retaining messages and QoS1? The ability to integrate message acknowledgement both on the edge and cloud side to detect whether devices are online, act upon it if they go offline, and confirm whether state/command messages have been received, seems valuable for device control where reliability and fail-safe scenarios are important.