Live and buffered data
Tracking devices generally submit live data reports as a priority when there is communication with the server. Data buffering allows supported devices to store data in their internal memory when communication with the server is not possible. This article will explain how GpsGate Server deals with buffered and live data and how they affect the execution of Live Event Rules.
What is the difference between buffered and live data?
Buffered data: information stored temporarily in the physical memory of the device to be sent as soon as possible.
Live data: information that is delivered immediately to the server after its collection.
Why does the device buffer data?
The device will store data in its internal memory when connectivity with the server is not possible (ex: poor reception/no data coverage), if data buffering is supported it must be specified in the device’s technical specifications.
How does Event Rules handle buffered and live data?
If you see the following message in the Terminal:
“History position. Will not be processed by Live Event Rules.” What does it mean?
Live Event Rules could only be triggered by live data or buffered data submitted in ‘time order’. It is the sending method configuration which determines if the message could/not be processed by the Live Event Rules.
Which submission scenarios do my devices support?
You need to read the technical specifications of your tracker in order to know which mode(s) are supported by your device.
The most common device submission scenarios are:
Devices without buffering support
The device tries to always send the latest position. All the messages that could not be submitted to the server were lost due to the lack of connectivity. The messages that reach the server could trigger Live Events if they match any condition set in the Event Rules.
Devices with buffering support
For this kind of device, there exist at least two common scenarios:
- Send the most recent report: The device always sends the latest known position as a priority, and then sends up buffered data when possible. In this scenario, Live Event Rules will not be executed for the buffered data.
- Send reports in time order: The device sends up buffered data in a time sequence. Sends the oldest data first as fast as it can to the server. In this scenario, all Live Events will be executed if matching a predefined condition(s). This is usually not a default mode and it's only supported by some trackers.
Example of a configuration tool for a Teltonika device that supports sending messages in order (older first):
How do reports handle buffered and live data?
Both buffered and live data are being used in reports as soon as they are ready in the database.
How is the status panel updated with live and buffered data?
If live data is received: it will be displayed in the Status Panel as soon as it arrives.
If buffered data is received:
- Device configured to send the most recent report: the latest known report will be displayed in the Status panel. If older data reports are sent after, these will be ignored in the Status panel.
- Device configured to send reports in time order: the latest known report will be displayed in the Status Panel. If newer reports are sent after, the Status Panel will be updated with the newest.
Diagnosing live and buffered data in the Terminal Window panel
If your device is configured to send the most recent report you will probably see this info message on the terminal window:
History position. Will not be processed by Live Event Rules.
We recommend that you verify the following in order to allow your buffered messages to be processed by the Event Rules engine:
- Configure your device to allow sending data in time order.
- Compare results with a different device brand/model in the Terminal Window.
- Try with a different SIM card of another service provider to improve network coverage.
- If you believe you’ve configured your device properly but still you’re experiencing the same messages, update the device’s firmware or contact your device’s manufacturer for support.