Wondering what an event means or why you're receiving it? We've collected answers to common questions about events, fields, and faults.
Frequently Asked Questions About Device Events
A: A disconnect event is generated when a device has powered down after being disconnected from the OBDII port. When the device is plugged back in, the first event it sends is a connect event, followed by the disconnect event.
When a device has a supercap and is disconnected, it sends a real-time disconnect event so that you don't have to wait until the device is plugged back in to get information about the disconnect.
Note: the supercap device remains powered on after it's been unplugged for up to a few minutes. If the device is plugged back in before the device powers down, the connect and disconnect events will not be generated. In this case, the only event you'd receive is the real-time disconnect event.
Q: What timestamps are provided in the event and what do they mean?
A: There are several timestamps that provide relevant information:
Delivered At Timestamp
timestamp field in the
body of the event provides the time for when the event occurred. The nesting of the timestamp field depends on the protocol.
Timestamp Location in TCP Event
Timestamp Location in UDP Event
There is also an
ingestionTimestamp in the
header of every event, which records when our platform received the event from the device.
The ingestion timestamp may be the same for several events whose timestamps are different.
For example, if GPS is collected every 5 seconds on the TCP protocol, and uploaded every minute, then the
ingestionTimestamp would be the same for 12 GPS events whose
timestamps are each 5 seconds apart.
Delivered At Timestamp
Customers using our DynamoDB or Bigtable integration will notice other timestamps on their events. One of these is the
deliveredAt timestamp, which records when the event was successfully delivered to the third party.
Q: What is the difference between messageId and eventId?
eventId field in the
header is a UUID that uniquely identifies the event. This UUID never appears anywhere else.
In contrast, the
messageId uniquely identifies the packet that an event arrived in. Packets contain a varying number of events (depending on their sizes) so a
messageId may be repeated across several events.
Q: Which events provide information about vehicle odometer support?
A: Several events indicate whether the vehicle that a device is plugged into reports its odometer value.
Unfortunately, this field is not consistently named across events, so you'll have to look at the event structure below.
UDP First Plugin Event
UDP Connect Event
UDP Disconnect Event
UDP Real-time Disconnect Event
UDP GPS Event
TCP Abs. Time Trip Start Event
TCP Abs. Time & GPS Trip Start Event
TCP Abs. Time & GPS Trip End Event
Q: If the vehicle odometer is not supported, what are the values provided in the odometer fields?
A: If the vehicle does not report its odometer values, the device will provide a cumulative distance calculated from the time it was first plugged in.
Distance is calculated using vehicle speed readings, and the units of the odometer value depends on the device's configuration.
Q: Why am I not getting values in the
fuelConsumed field in Trip End Events?
A: If this field is always zero, the most likely culprit is a lack of vehicle support for collection of OBD-II PID 16 (Mass Airflow Rate), which is necessary for the device to calculate fuel consumption.
Have a question that's not answered here? Send us a message! 👍