subscribe to our Youtube


4167 questions

4739 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
in Vehicle tracking by anonymous
A good addition to the device would be an "always connected" setting.

Now the device connects (TCP) only when it needs to send data, and in case of disconnects (communication issues or just upgrading the backend) you have to wait (sometimes a lot) for the device to connect. We're also getting some strange disconnects and setting like this would help a lot.

In our case (shared mobility) we need always to be able to send commands to the device and it's hard to find a balance between the frequency of the reports and the downtime we get.

1 Answer

0 votes

Good day, 

Such a function already exist on FMb devices, you can set Open link timeout . We recommend maximum time of 259200s (72 hours ) that way link will be open all the time because clock resets everytime you send command .

by anonymous
No, this is not the same.

This controls when the connection will be closed, not when it will be opened.

Imagine the following case - Record is generated every 30 minutes while device is stopped. Backend reboots and FMB looses connection. FMB will not reconnect until there is actual records pending (which will happen sometimes in the next 30 minutes), device will reconnect and keep the socket open. This means that I will be unable to send commands to the device during this time.

What I want is that the device will establish connection as soon as possible no matter if there is actual records pending in the device queue or not.
This feature would be awesome. I have the same issue. Have to lower the information period in order to make sure that the socket is connected.