AdaTrack v1.6: From Raw Telemetry to Automatic Trip Intelligence

IoT platforms are very good at recording where a device was. They are considerably worse at telling you where it went. Most fleet and asset tracking systems store a continuous stream of GPS coordinates and leave the question of journey segmentation entirely to the operator — write a query, define a threshold, export to a spreadsheet, repeat every time the rules change. The result is that the raw data is there, but the operational insight that should emerge from it requires manual work every single time. AdaTrack v1.6 ships the Travel Log: a system that processes every incoming telemetry packet and, without any user configuration, segments continuous location streams into discrete, fully-annotated trips — complete with distance, speed, stops, export, playback, dashboard widgets, workflow triggers, and as of v1.6.2, native integration with the Chat Bot and AI Assistant plugins.

A Finite State Machine Inside the Ingestion Pipeline

The trip detector does not run as a background job that periodically scans the readings table. It runs inline in the UDP processing pipeline, invoked on every packet immediately after the HMAC is verified and the payload is decoded. The architectural choice here is deliberate: the detector needs sub-second latency to accurately record trip start and stop times, and a polling approach introduces lag proportional to the poll interval. By processing each reading as it arrives, trips are detected at packet resolution.

The implementation is a three-state finite state machine: IDLE, MOVING, and STOPPED_WAIT. A device starts in IDLE. Transitioning to MOVING requires all three of the following conditions to be true simultaneously:

• Speed exceeds 1.5 m/s (approximately 5.4 km/h)
• That speed has been sustained for at least 60 consecutive seconds
• The device has moved at least 100 metres during that window

The triple-condition check is not arbitrary — it is specifically designed to reject GPS jitter, brief traffic-stop creep, and slow parking-lot manoeuvres that would otherwise create dozens of spurious one-minute trips per day for a parked vehicle with an active GPS fix. Once in MOVING, the FSM transitions to STOPPED_WAIT on loss of speed. The trip does not end until the device has remained stationary for a continuous five minutes. A red light or a drive-through window becomes a recorded stop within the ongoing trip; only genuine parking ends it.

State is managed by a DetectorPool — a mutex-protected map from device_id to TripDetector. Because the UDP processor already shards work by device ID across a fixed goroutine pool, a given device's packets are always processed by the same goroutine. The pool mutex is still held for the duration of each Detect call to ensure correctness if that sharding assumption ever changes. New devices get a detector on their first packet. On server restart, LoadActiveTrips restores any in-progress trip state from the database, so a mid-journey server restart does not create phantom trip boundaries. Active trip metadata is flushed to the database every 30 seconds so that API reads of live trips show current distance and duration rather than stale zeros.

Standard and Enterprise users can override detection thresholds per device — useful for slow-moving assets like forklifts or equipment where the 1.5 m/s default would never trigger. Per-device configuration is stored alongside the device record and loaded into the detector on its first packet after a config change.

What the Travel Log Exposes in the UI

The Travel Log page (/travel-log) shows a sortable, filterable table of all recorded trips — device, start time, duration, distance, stop count, max speed, average speed, and status. Active trips appear at the top with a live badge; distance and duration counters update in real time via WebSocket without requiring a page refresh.

Clicking any row navigates to a dedicated detail page at /travel-log/<trip-id> with breadcrumb navigation back to the list. The detail page renders the full route as a speed-gradient polyline — green segments below 30 km/h, yellow approaching 60, orange approaching 100, red above — so the speed profile of a journey is visually immediately obvious. On desktop, the map occupies 65% of the viewport width and the trip timeline fills the remaining 35%, both stretching to full viewport height. The timeline lists every stop with its dwell time and address (when reverse-geocoding is available), and segment colours between stops match the average speed of that leg.

The Playback mode animates the device icon along the recorded route at speed multipliers from 1× up to 32×. A scrubbable timeline lets operators jump to any moment in the trip. At the playback cursor, a live data panel shows speed, heading, timestamp, and the decoded payload fields from that point in time — the same structured telemetry that would appear in the readings table. Stop events are marked as jump targets on the scrubber.

Trips can be exported individually as CSV (stats header plus one row per stop), GPX 1.1 (standards-compliant with <trkpt> for every GPS point and <wpt> for each stop), or PDF (map image plus stats table, generated by the platform's existing reporting engine). Bulk export supports up to 1,000 trips per request; the archive is prepared asynchronously and delivered via in-app notification or email. When auto-detected boundaries are wrong, users can split a trip at any timeline point, merge two consecutive same-device trips (within a 60-minute gap), or soft-delete trips.

Six Widgets, Two Triggers, Two Report Blocks

Travel Log data surfaces throughout the platform rather than being isolated to a single page. This reflects a broader principle in the platform's design: a feature that generates data should make that data available at every layer where operators might need it, not just in its dedicated UI.

Six Travel Log dashboard widgets are available in the Dashboard builder: Trips Today, Distance Today, Idle Time Today, Last Trip Summary (a card with the most recent completed trip's key stats), Device Trip History (a sparkline of daily trip count for a selected device), and Active Trips (a live list of devices currently on a journey). All six are real-time: Active Trips and any counter showing today's statistics update via the existing WebSocket hub without page reload.

Two AdaTrack Flow trigger nodes expose trip events to the no-code automation engine. The Trip Started trigger fires the moment a new trip is detected and provides device_name, started_at, start_lat, and start_lng. The Trip Completed trigger fires at trip end with the full set of final statistics: distance_meters, duration_seconds, max_speed_ms, avg_speed_ms, stop_count, and start/end coordinates. These nodes compose naturally with existing actions — sending a Slack message when a vehicle exceeds a distance threshold, creating a maintenance record after every completed trip, or triggering a geofence check against the trip's final coordinate.

Two report blocks are available in the Report Designer: a Trip Summary Table with configurable column selection and grouping by device or day, and a Trip Map that renders a static image of all trip traces for the report's date range, coloured by device or by speed gradient. Both blocks participate in the PDF export pipeline, so scheduled fleet reports can include journey analysis alongside telemetry charts and alert summaries without leaving the platform.

Access to Travel Log data is governed by seven granular RBAC permission slugs (travel_log:list, travel_log:get, travel_log:export, travel_log:delete, travel_log:edit, travel_log:configure, travel_log:analytics) with role-based defaults. Tier limits on trace point resolution (Community: 500 points, Standard: 5,000, Enterprise: unlimited) and trip history retention (30 days, 1 year, unlimited) are enforced at the quota layer. The entire module is gated by the enable_travel_log feature flag.

v1.6.2: Travel Log Meets the Chat Bot and AI Assistant

AdaTrack's plugin system is designed so that new platform capabilities become first-class citizens across every installed integration — without the core feature knowing which plugins are present, and without plugins hardcoding knowledge of each other. Travel Log's v1.6.2 integration with the Chat Bot and AI Assistant plugins demonstrates exactly this pattern.

The Chat Bot plugin (v1.1.0) adds three new commands available in both Telegram and Slack. /trips lists the ten most recent trips for the linked user, formatted with device name, start time, distance, and duration. /trip <id> returns the full detail for a single trip: distance, duration, max and average speed, stop count, and start and end addresses when available. /tripstats returns a 30-day analytics summary — total trips, total distance, total hours driven, and average and peak speed. All three commands are protected by a new chatbot.travel.read permission (granted to the USER role by default) and are routed through the same RBAC enforcement layer as every other chat command.

Beyond query commands, the Chat Bot now subscribes to trip.started and trip.completed events from the platform's EventBus. When a trip starts or ends for a device owned by the linked user, the forwarder checks the account's notification preferences, applies quiet-hours filtering, and dispatches the notification to the appropriate Telegram or Slack chat. Trip notifications are opt-in — the new notify_trips preference defaults to false — because high-frequency fleets generating dozens of trips per day would otherwise produce noisy notification streams. Users toggle the preference from the Chat Bot > Preferences tab.

The AI Assistant plugin gains three new LLM tools alongside its existing eight platform tools: list_trips (recent trips, optionally filtered by device), get_trip_details (full statistics for a specific trip), and get_trip_analytics (aggregated summary over a user-specified time range). These tools are backed by the same TripService and TravelLogRepository as the REST API — the same ownership checks, the same tier-gated trace point resolution, the same repository interfaces. Queries like "How far did my fleet drive last week?", "Which device had the longest trip yesterday?", or "What was the average speed on Truck-04's last three trips?" now compose naturally into the AI assistant's multi-hop reasoning loop without any additional backend code.

Both integrations are built on the TravelLog() accessor added to the PluginHost interface in v1.6.2. Any third-party plugin or scripted Goja VM can now call host.TravelLog() to receive a TravelLogReader with ListTrips, GetTrip, and GetAnalyticsSummary methods. Access is subject to the calling plugin's declared permissions, enforced at the host layer — the Travel Log repository itself is never directly exposed to plugin code.