teltonlka
Offline means that your device has disconnected.
Maybe I didn't state my question clearly.
I would like to know under what circumstances or what instructions sent by the device will become offline state and under what circumstances will become unknown state. Assuming that the location information is not updated for 10 minutes, why do some devices become unknown state while some devices become offline after 10 minutes? There are no special operations for these two state types of devices
Offline - device disconnected. There's no default timeout for this. It can happen immediately after uploading data if device works like this.
Unknown - device hasn't disconnected but not reported data for 10 minutes.
Note that in some cases there's no concept of connection. For example UDP and HTTP protocols. In those cases you will never get offline state.
Thank you for your help.
I use these devices. Depending on your mobile provider and how their CGNAT is configured the session can be torn down. I'm working on solving this issue locally here in Australia so that the device is always in either online or offline state, not unknown. It's also important that if the mobile provider tears down the session that the status is immediately updated to offline.
It's best to use TCP to ensure this, as a teardown via a CGNAT gateway using TCP will at least send a TCP reset. The absolute worst scenario to end up in is with Traccar thinking the device is online but the NAT session has been torn down. This will cause lost commands.
Records Settings Teltonika Programing
Open Link Timeout:
The parameter used to define a timeout between the fleet management device and the server. If the device has sent all records, device holds the link for duration of the confugured timeout. “Open link timeout” will refresh after device sends a new record. If there is a need to keep a constant link with a server, increasing the value of the parameter is needed.
Server Response Timeout:
Is used to set a period of time waiting for the response from the server-side. If there is no response from the server during the timeout, the device will close the link and according to device configuration resend the same packet.
NOTE! If Data protocols are not implemented correctly, device will not send data correctly.
Network Ping Timeout:
Enables network ping after timeout to prevent link close by operator. For example, if the operator closes the active link after 15 minutes when no data is sent, you can set the "network ping" timeout to 10 minutes then the device sends a 0xFF byte to server to keep the link open. This functionality works only for Record and Backup Servers. Network Ping Timeout should be always lower than Open Link Timeout.
In the first two, use the highest values that it allows you, in the third, investigate how long your provider closes the connection, or configure it every 120 seconds.
The above info from the Teltonika Wiki is useful, but it's important to have a packet sniffer available to monitor how your particular mobile provider functions.
In my case, Telstra here in Australia has an aggressive CGNAT gateway that actively tears down the connection in both directions to the client and the server. When the Teltonika device receives the TCP FIN packets, it assumes that the server has actively told it stop talking, and so the Network Ping Timeout value has no effect becausse it accepts the FIN packet and stops communicating.
Switching to UDP - for this mobile provider at least - is worse because their UDP teardown is silent and has a random timeout. If you don't set your network ping timeout to less than 5 seconds (which consumes data), Traccar assumes the device is online when it's actually offline, and any commands will be lost.
Ergo it is best to use TCP, and also monitor how your mobile provider's CGNAT behaves using a Packet Sniffer. From there you need to alter your device settings and traccar settings to ensure that your command sending is as reliable as you can make it.
I have a device using the teltonlka protocol format, but after other devices or mobile phones using other protocol formats have correctly changed into the unknown state ten minutes later, this device has changed into the offline state. Shouldn't this device also become the unknown state? Or where in the 4.15 code can I see how unknown and offline are distinguished