Add option for queuing all commands (rather than sending immediately when a device is online) and sending within X seconds of an incoming connection about traccar

[tananaev]

Why not set connection timeout on the server?

[heypete]

Why not set connection timeout on the server?

Do you mean the connection timeout described here, either globally or for the specific protocol this devices?

If so, that certainly could be a functional alternative, but the issue may not be universally applicable (other carriers or other devices, even those using the same protocol, might not be affected the same way). Having a per-device option to set a post-check-in window during which commands can be sent immediately vs. being queued would be more flexible and be usable by users who don't run their own server.

Regardless, I'll try changing the connection timeout on the server and see if that improves things. Thank you for the suggestion.

[alenvukelic]

Small info from my side, regarding other devices also, for example Teltonika. Since TCP/IP connection is used, and mobile operators put not used connection in some weird sleep state (time differs from one mobile operator to the next and is not guaranteed), there is no way except using ping to determine if connection is open or not.
However, Teltonika devices return ACK packet, or reply message if command is sent successfully.
In short, just sending message to device if connection is open is bad practice. Message should be in queue and removed only when device confirms receiving it.
This would really be a must have feature..

[tananaev]

@alenvukelic let us know once you complete your investigation about this weird state. Once we have all the details on what's happening and why it's happening, we can take it into the consideration.