Geotab integration: location, fault codes and idle time

A unit running Geotab reports its position continuously, and separately reports engine fault codes and idle time as they happen. Roadmark reads all three: location is what tracking turns into an ETA, and fault codes and idle time land on the unit's own card, next to its hours of service, trailer and home time, the same card dispatch planning checks before it puts a driver on the next load.

What Geotab actually reports

Geotab's MyGeotab API exposes fleet data as typed objects. A fault comes through as a FaultData record, tied to a specific device and a Diagnostic, and Geotab documents support for reading standard OBD-II and J1939 fault codes from it. Engine measurements come through as StatusData records, and each Trip record carries its idling time, counted while the speed is zero and the ignition is on. Location comes through as LogRecord records, the device's position and speed at a point in time. Roadmark reads these and doesn't touch how the Geotab device runs in the vehicle.

Connecting the two

MyGeotab doesn't issue a separate developer API key. Its own guidance is that a connection needs a MyGeotab database, an appropriately scoped user, and a password, and Geotab's service account guidance recommends a service account, a user with the Service Account authentication type and View only clearance for reading data, rather than a person's own login. An admin sets that account up once and gives Roadmark the database name and credentials; nothing about how a dispatcher or driver uses MyGeotab changes.

Where it shows up

Location is one of five sources Roadmark checks for a load's status, alongside the driver app, a carrier's own app or an EDI 214, visibility networks, and a check call when nothing else is reporting. A fault code doesn't wait for a shop visit to matter: it's visible on the unit's card the moment dispatch planning looks at that unit for the next load, next to the hours of service and home time already there. Idle time sits on the same card, so a unit that's been sitting shows up next to the one that's been driving, without a dispatcher pulling a separate report.

A Tuesday example

On the carriers board, unit 207 (T. Okafor) is running Toronto to Detroit, then a backhaul from Windsor to London. With Geotab connected, that unit's position updates on the board the whole way, so tracking has an ETA for both legs without anyone calling ahead. If Geotab reports a fault code partway through the first leg, it shows up on unit 207's card next to T. Okafor's remaining hours, before dispatch planning looks at that unit for the Windsor leg, not after a shop finds it at the next inspection. And if the unit sits at a dock longer than expected, the idle time on its card is what shows a dispatcher it's stopped, not just that it hasn't arrived yet.

For a fleet switching ELDs

A carrier moving from one ELD to Geotab, or running Geotab on some units and a different ELD on others, doesn't lose the unit card in the meantime. Roadmark reads whichever connected ELD a unit reports to, and the card looks the same either way: hours of service, trailer, home time, and now location, fault codes and idle time from Geotab. Nothing about how a dispatcher works the board changes because a unit's ELD changed.

For a fleet already running Geotab, connecting it mostly means the board and the unit's own card catch up to what the device has been reporting all along: an ETA built from the truck's actual position, and a fault or a long idle that a dispatcher sees before it becomes a bigger problem.