Refinement of connection detection

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)

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.

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