Every telemetry pipeline we've worked on has the same failure mode eventually: a device that should be reporting isn't. Not because the event never happened — a truck still made the trip, an excavator still loaded it — but because the write path from that specific piece of equipment to the system is, for whatever reason, not there right now.
The gap, stated plainly
In an open-pit haulage operation, trip and load counts normally come from connected equipment reporting automatically. Two things reliably break that assumption: a sensor fails and a truck keeps running without it, or a contractor's truck works the same routes without ever being onboarded into the customer's system at all. Either way, the equipment isn't idle — it's just that its events aren't landing anywhere a dispatcher can query.
The fallback is a human one: the dispatcher keys the radio and asks. That works for a single ad hoc check. It stops scaling the moment you need it regularly, across many crews, because now a person is the serialization layer for every one of those events, and people are a slow, lossy, synchronous channel for something that's fundamentally a stream of small structured records (equipment ID, trip count, timestamp, route, deviation reason).
The fix: point an existing agent at the gap, not a new one
Log Sheet already runs a voice agent for scheduled staff polling — it calls people, asks fixed questions, writes structured answers into a log. The proposal here is narrow: extend that same agent to also poll equipment crews over two-way radio (digital or analog) or a mobile call, on the same schedule logic it already uses for everything else. No new system, no new write path shape — the same agent, a different channel, the same target schema.
A single poll cycle looks like this: at a scheduled time, the agent calls the haul truck driver, asks for trips completed; calls the excavator operator, asks for trucks loaded and any downtime; writes both answers to the log tagged with equipment ID and shift. If a crew doesn't pick up, the agent retries and then escalates to the dispatcher — so the dispatcher's queue is specifically the set of cases that couldn't be resolved automatically: no-answers and downtime reports that need a follow-up question. Everything else never touches a human.
Worth being explicit that this is poll, not listen — scheduled, targeted calls to specific crews, not continuous monitoring of the channel. That matters for both the engineering (you're not doing speech recognition on an open radio feed) and the framing (crews aren't being passively surveilled, they're being asked a specific question on a schedule they can anticipate).
Where the write path actually mattered
Mid-shift visibility instead of end-of-shift reconciliation. If trip/load counts are crew-reported in the first place, polling on a schedule just moves that reporting from ad hoc-and-manual to scheduled-and-logged. The practical effect: a drop in output shows up as a row in the log during the shift, not as a surprise during the end-of-shift rollup.
Partial automation coverage. In practice, automated and manually-reported areas of a pit coexist, and the dispatcher ends up maintaining two mental models of the same shift — what the system shows, and what they were told. Routing the manual area through the same polling path collapses that back into one model, one log.
Shift close-out reconciliation. Driver-reported trip tally and operator-confirmed load count, written to the log instead of held in someone's head, are now diffable against the rest of the shift's records before the report closes — not after. This is the one place where "it's just a log entry" has real stakes: confirmed output frequently ties directly to pay.
Sensor downtime as a labeled gap, not a silent one. When automatic reporting drops out, driver-reported entries fill the same log with the same schema, distinguishable later by their source field. You get a log that's honest about where each data point came from instead of a log with an unexplained hole in it.
Unintegrated contractor equipment. Contractor trucks running the same routes as owned fleet, but outside the customer's system, are structurally the same gap as a dead sensor — the fix is the same polling path, producing an independent record the customer can later reconcile against contractor-submitted volumes.
What this doesn't solve
Polling doesn't make the dispatcher's reconciliation work disappear — missed answers and disputed numbers still need a human to sort out. What it changes is the starting state: by the time that reconciliation happens, routine reports are already structured rows in the log instead of something the dispatcher has to go reconstruct from memory and a stack of ad hoc radio calls.
Takeaway
Swap in whatever your actual unconnected-device problem is — the pattern doesn't change. A missing sensor isn't a missing event, it's a missing write path. Before building a new one, check whether you already have an agent that can reach a human over a channel you haven't pointed it at yet.
Top comments (0)