Refinement of connection detection

Squirrel Code
1

The Imp API methods device.onconnect/device.ondisconnect work fine, but their granularity is rather coarse (can take 5 to 9 mins to change state according to the docs). I assume the device.isconnected() follows the same connection determination strategy hence is probably not more accurate. .
For our purpose, we would need a more accurate determination of disconnections.
Question: As we are using the MessageManager lib, which provides a timeout handler for send messages, is it advisable to use this timeout to conclude that a disconnection occured, or are there too many other reasons for timeout that could cause false positives ? Eg. is a timeout also triggered if the message doesn’t explicitely reply ?
Alternatively, can we use the MM OnAck callback to conclude that a device is connected when it is triggered ?

Obviously we realise that if this works, the limit of accuracy is the frequency with which we try to poll the device and that we need to strike a balance between data traffic volume and accuracy. We would probably only activate such polling when a client is effectively connected to the agent (which is for our application the main agent use case - gateway for clients to connect)

2

device.isconnected() actually reports immediately the link is down, vs when impOS has given up on it. The connection manager library polls isconnected (see “checkTimeout”) and forces a disconnect when it changes.

Because the protocol runs over TCP, message manager doesn’t resend messages unless there has been a disconnection - TCP handles retries when the connection is up. This is why generally people use message manager AND connection manager together, and why you can pass a CM instance into MM.

3

this is great. So I can use only the checkTimeout config for MM to choose what granularity we want.