Wondering what an event means or why you're receiving it? We've collected answers to common questions about events, fields, and faults.

Q: What is the difference between a Disconnect event and a Real-Time Disconnect Event?

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:

Event Timestamp

The 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

Ingestion Timestamp
​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?

A: The 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.

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! 👍