Reference · built on requestOperator by FibricFleet, routes & field

Idle Watch

Flags engine idling beyond your policy at depots, sites, and stops, and proposes a coaching note or a recorded exception.

Request accessPricing ↗

About

Idle Watch reads idling events as your telematics system records them: Samsara's idling report with durationMs, fuelConsumptionMl, and isPtoActive; Geotab ExceptionEvents from the idling rule and Trip.idlingDuration; Motive idle_events with start_time, end_time, and fuel at start and end. Each event is placed inside a depot, customer site, or stop by the geofence it fell in, or by nearby places when no geofence exists.

Events longer than the policy you set for that place type become proposals: a coaching note for the driver on shift, or an exception when power take-off was active or the reason is one you allow. A supervisor approves each one. Repeated idling at an unfenced spot proposes a new zone.

This is a reference listing. It documents what Fibric would read from Idle Watch and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Idling events from Samsara through GET /fleet/reports/vehicle/idling, with durationMs, fuelConsumptionMl, isPtoActive, address, and a minIdlingDurationMinutes filter
  • Geotab ExceptionEvents whose Rule is the Stock idling rule, with activeFrom, activeTo, duration, device, and driver, plus Trip.idlingDuration
  • Motive idle events through GET /v1/idle_events with start_time, end_time, veh_fuel_start, veh_fuel_end, lat, and lon
  • Which geofence the event fell in: Samsara addresses with addressTypes such as yard or customerSite, or Geotab Zones with zoneTypes
  • Nearby places from OpenStreetMap through the Overpass API when the location is outside every geofence
  • Who was rostered on the vehicle's shift from Deputy's Roster query, so the note reaches the right person

Proposed actions

  • Target capability: propose a coaching note as a Deputy journal entry through POST /api/v1/supervise/journal with strComment and intEmployeeId
  • Target capability: propose a Slack message to the driver's supervisor through chat.postMessage with the place, the duration, and the fuel used
  • Target capability: propose an exception that marks the event excused, with the reason: isPtoActive, a temperature condition you set, or a place you exempt
  • Target capability: propose a new Geotab Zone through Add, or a note that a Samsara address is missing, when idling recurs at an unfenced spot

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Coach depot idling from Samsara

    Filter GET /fleet/reports/vehicle/idling with minIdlingDurationMinutes, keep events inside addresses typed yard, drop those with isPtoActive, and propose one Deputy journal entry per driver per day.

    With Samsara, Deputy

  • Excuse reefer and PTO idling, still on record

    When a Geotab ExceptionEvent falls at a customer Zone and the vehicle is on your PTO list, propose an exception with that reason so the event is closed with a cause, not silently ignored.

    With Geotab

  • Find the sites you never fenced

    Cluster Motive idle_events by lat and lon, look up what is there through Overpass, and propose a Zone or address for the spot that recurs, so future events are classified.

    With Motive, Places & Geo Context

  • Tell the supervisor, not the driver, first

    Post each proposed note to the supervisor's Slack channel with the event details; the note reaches the driver's record only after the supervisor approves.

    With Slack, Deputy

Requirements

  • Telematics that records idling: Samsara, Geotab, or Motive
  • Geofences for your depots and regular sites in the telematics system, or the willingness to add them as the job proposes
  • An idle policy per place type, in minutes, and the exceptions you allow, such as power take-off
  • A roster source that maps a shift to a person: Deputy, or the driver assignment from the telematics system
Authentication
A Samsara API token with Read Vehicles and the idling report scope, a MyGeotab API user with access to ExceptionEvent and Zone, or a Motive API key; a Deputy permanent token or OAuth 2.0 grant; a Slack app with chat:write.

Limits

  • Samsara's idling report does not name the driver; the driver comes from the vehicle assignment or the roster
  • Geotab reports idlingDuration at the end of a trip only; mid-trip idling appears through ExceptionEvents
  • Motive idle events carry fuel level at start and end, not a computed fuel cost
  • The Overpass public instance asks callers to keep to a small daily query volume; place lookups are cached per location

Access and pricing

Reference listing. Fibric builds the operator under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Idle Watch ↗

Questions and answers

What is the supervisor approving?
One proposal per idling event over policy: either a coaching note with the vehicle, place, duration, and fuel, or an exception with its reason. Approve writes the note to the person's Deputy journal or closes the event as excused. Reject discards it and the event stays open.
What is written down about each event?
The telematics event id, vehicle, start and end time, duration, fuel figure as reported, the geofence or place matched, the person on shift, the policy that applied, the proposal, the decision, and who made it. Excused events keep their reason.
Does it change anything in the telematics system by itself?
No. It reads events and geofences. The only telematics write it proposes is a new Geotab Zone, and that is created only after approval. Coaching notes go to Deputy, messages to Slack, both after a person says yes.
Ask about Idle Watch

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This operator is developed, published, and supported by Fibric. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy