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

[heypete]

Background
I have a Mictrack MT710 tracker running on the 1NCE network.

1NCE assigns devices private, internal IP addresses and uses NAT to allow them to communicate with the broader internet. Device-to-internet connections are seamless, but internet-to-device communications can only occur for the limited period of time that 1NCE's NAT system considers NAT connections to be "established".

Although 1NCE states "After 350 seconds of no data packets being transmitted, a established connection via the 1NCE Internet Breakout will be closed automatically.", a user reports that the NAT connection for UDP within 20 seconds.

Problem
Traccar sends commands to "online" devices immediately. Commands sent to offline devices are queued for delivery when the device comes online.

However, the device's "online" status remains valid for 10 minutes in Traccar (if I read that code correctly). Thus, there is a window of time where messages will be sent immediately but the device is unable to receive it, so the packets are dropped.

Requested Feature
Implement an option to have a command (or, more broadly, all commands) for a specific device be queued until the device communicates with the server, at which point the command will be sent immediately. The time window after the device communicates during which commands should be sent (vs. being queued for sending at the next device check-in) should be configurable via attribute.

Describe alternatives you've considered
I have briefly attempted to set the status.timeout attribute in the Device --> Settings --> Attributes, but this was unsuccessful. I will continue to attempt to adjust things in attributes to see if the "online" status" can be reduced.

Additional context
I am happy to pay a financial bounty for this feature, amount TBD.

[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.