ELD telemetry is only as useful as what you do with it. Most carriers know their drivers' positions down to the meter and have HOS status refreshing every 30 seconds. Yet the routing engine that actually schedules the afternoon dispatch run still operates on static assumptions baked in at 6 AM. There's a gap there. A meaningful one.
We've seen this at regional carriers running 40 to 120 trucks out of a single depot. The Samsara or Motive dashboard shows exactly which drivers are 18 minutes behind schedule and which ones wrapped their morning routes early. The dispatcher knows. But that knowledge doesn't flow back into the routing solver before the afternoon wave goes out. Manual intervention, at best. Usually nothing.
This article walks through how we wire live ELD signals from Samsara and Motive directly into a re-optimization solve so that route assignments for the next wave reflect actual driver state, not the plan from hours ago.
What ELD Data Actually Contains (And What Routing Needs)
Both Samsara and Motive expose webhook and REST endpoints that surface a few key signal types relevant to dispatch re-optimization:
| Signal | Samsara field | Motive field | Routing relevance |
|---|---|---|---|
| Current GPS position | location.latitude/longitude |
current_location |
Start node for next route leg |
| Available HOS (hours remaining) | hosStatus.remainingDriveMs |
hos_available_drive_hours |
Feasibility constraint per driver |
| Active duty status | hosStatus.currentStatus |
current_duty_status |
Available vs. on-break vs. driving |
| Vehicle odometer / fuel | vehicle.engineStates |
vehicle.odometer |
Service window eligibility |
The critical pairing is position plus available HOS. A driver who is 45 minutes from depot but has 6.5 hours of drive time remaining is a very different resource than one who is 10 minutes out but has 1.2 hours left. Your solver needs both numbers simultaneously to make a sensible assignment decision.
The Integration Architecture
Here's how we structure it at Parcelarc. The integration runs as a pre-solve enrichment step, not a real-time streaming loop. That distinction matters.
Polling the ELD API for every vehicle every 30 seconds during active dispatch creates unnecessary load and, frankly, doesn't improve outcomes. Route re-optimization has a natural cadence tied to wave cutoff times, not continuous GPS refresh. In our experience, a 5-minute enrichment pull, triggered 20 to 30 minutes before the next dispatch window, hits the right balance.
- Trigger: Parcelarc dispatch scheduler fires a pre-solve hook N minutes before wave cutoff (configurable per depot, default 25 min).
- ELD pull: Parallel requests to Samsara
/fleet/vehicles/statsand Motive/v1/vehiclesendpoints using driver vehicle ID as the join key. - HOS normalization: Samsara returns remaining drive time in milliseconds; Motive returns decimal hours. Both get normalized to fractional hours before being written to the driver state object.
- Position geocode: Raw lat/long gets snapped to the nearest road segment in the routing graph. Direct coordinate injection into a road network solver without snapping produces infeasible routes about 8% of the time in our validation set.
- Constraint injection: Updated driver state (position + HOS) is written into the solver's vehicle fleet object, replacing the morning snapshot values.
- Solve: The re-optimization runs with updated constraints. Assignments shift where needed. Everything that doesn't need to change stays put.
The whole cycle runs in under 90 seconds for a 60-vehicle fleet. Fast enough to complete before the dispatcher needs to push assignments to drivers.
HOS as a Hard Constraint, Not a Warning
This is where a lot of integrations get it wrong. They pull HOS data and surface it as an informational overlay. A color-coded warning on a map. The dispatcher still has to manually reassign the affected stops.
Treating HOS as a hard constraint in the solver means the re-optimization engine simply will not assign a route leg to a driver who can't legally complete it. Period. No warning to click through. No manual intervention required.
In practice, this affects roughly 3 to 7% of drivers in any given afternoon wave at a regional carrier running multi-leg days. Small number. But those are exactly the drivers who, without the integration, generate the last-minute scrambles that delay the entire wave by 20 to 40 minutes.
Fact: in a 90-truck depot we worked with, wiring HOS constraints directly into the afternoon re-optimization solve reduced late wave departures from 14% of dispatch days to under 4% in the first month. The change wasn't better planning. It was removing the manual step that existed between knowing a driver was constrained and acting on it.
Handling the Mixed-Fleet Reality
Most regional carriers aren't mono-ELD. They run a mix. Samsara for the newer trucks, Motive for the legacy fleet, sometimes a third provider inherited from an acquisition. Our integration needs to handle that without making the solver care about the source.
The approach: normalize everything to a common driver state schema before it touches the routing engine. The solver sees one data structure regardless of which ELD produced it. The per-provider adapters sit upstream and handle field mapping, unit conversion, and auth token rotation independently.
One practical note on Motive specifically: their webhook delivery can lag by 2 to 4 minutes under high fleet activity. We've seen this on fleets above 80 vehicles. The mitigation is to always use a direct API pull for the pre-solve enrichment step rather than relying on buffered webhook events. Webhooks are useful for alerting and dashboards. For time-sensitive dispatch decisions, pull fresh.
What Doesn't Change (And Why That's Good)
A common concern when we demo this: "If we're re-optimizing before every wave, does the route plan keep changing on drivers mid-day?"
No. The re-optimization runs before assignments are dispatched to drivers. Drivers who are already on route see no changes. The solve only touches the unstarted legs of the next wave. In our implementation, any stop already in progress or accepted by a driver is locked. The solver treats it as a fixed node.
This matters for driver trust. A system that keeps reordering a driver's day after they've mentally committed to a route creates friction. The integration is designed to produce a better plan before commitment, not to chase an ever-moving optimum once drivers are in motion.
Key Takeaways
- Pull ELD data as a pre-solve enrichment step, not a streaming loop. 25 minutes before wave cutoff is the right trigger window.
- Normalize Samsara milliseconds and Motive decimal hours to a common unit before they reach the solver.
- Treat HOS as a hard constraint, not a display layer. The solver should reject infeasible assignments, not warn about them.
- Snap GPS coordinates to road segments before injecting into the routing graph. Raw lat/long produces infeasible routes at a measurable rate.
- Lock in-progress driver assignments before re-optimization runs. Only the unstarted portion of the next wave is eligible for reassignment.
The integration isn't complex. The data is already there, in Samsara and Motive, refreshing continuously. The gap is the pipeline between that data and the moment the routing solver runs. Close that gap and you're not adding new capability. You're using capability you already paid for.
