Automating flespi Fleet Telemetry Analysis with AI Agents

A morning report that says "40 devices offline" isn't information. It's a to-do list with no instructions. A triage that says "28 of those are parked in underground garages and will reconnect on ignition, 9 have SIMs that stopped attaching to the network, and 3 run a tracker firmware version with a known GPS-fix bug" is information. The first costs your team a day of clicking through the flespi panel. The second is what this article is about.

This is part three of our flespi fleet telemetry series. Part one mapped what goes wrong in GPS fleet monitoring at scale: silent devices, protocol parsing failures across mixed tracker fleets, stream backlogs, parameter drift, and the channel, device and stream health model. Part two built a DIY monitoring workflow with flespi's native tools: panel sweeps, flespi API calls with curl, MQTT subscriptions and the analytics engine.

If you followed part two, you ended with a working set of scripts and one honest conclusion. flespi tells you brilliantly what the fleet looks like right now, but the why behind every silent device still needs an engineer to read channel logs, compare message history and rule out causes one by one. On a fleet of a few thousand devices, that investigation loop is where the hours go. This part moves the loop to CloudThinker: connect read-only, watch device health continuously, and do the SIM, protocol, config and hardware elimination before a person ever looks.

---

Why scripts stop where investigation starts

A cron job can run the part-two sweep every ten minutes. What it can't do is decide what to check next. Its output is the same list every time: device IDs and ages. Turning that list into causes means following a different path for each device, and the path depends on what the last check found.

Connected but silent? Go to the channel log. Disconnected? Read the last messages. Signal falling? Look for neighbours that went quiet in the same place. Nothing wrong at all? It's probably parked. An experienced fleet engineer runs that tree naturally, one device at a time. A script only runs the branches someone wrote down in advance, and on a mixed fleet nobody writes them all down.

01Signal

Out of rhythm

A device misses its own reporting pattern, not a fleet-wide threshold.

02Context

Gather

Last messages, device and channel logs, neighbours on the same channel or route.

03Judge

Eliminate

Rule out parked, cellular, protocol and hardware, in that order, with evidence.

04Output

Finding

The likely cause, the evidence, and the one next step for the right team.

Connecting: a scoped flespi token, about 5 minutes

01Telematics platform

flespi

• Devices and telemetryRegistry, last values, message history
• Channels and logsConnections, parse errors, rejected idents
• StreamsDelivery state, queues, stream logs

Read-only ACL token

02Investigation

CloudThinker

• Watch the whole fleetEach device against its own rhythm
• Work out whyParked, cellular, protocol or hardware
• Propose the fixWith evidence and the owner who must approve

Nothing installed on trackers

03Where the team works

Chat and tickets

• Slack or TeamsFindings and approvals in the thread
• JiraCarrier, install and RMA work lists
• Audit trailWho approved what, and what changed

Nothing new to watch

CloudThinker connects to flespi the same way your part-two scripts did, with a flespi token. Scope it the way your security review would insist on anyway:

1. In the flespi panel, create a new token dedicated to CloudThinker. Never reuse your master token.
2. Add ACL entries that restrict it to read access on what the agent needs: devices, channels, streams, logs and messages under the gw (telematics gateway) API.
3. Set an expiration consistent with your credential rotation rules.
4. Paste the token into the CloudThinker connection screen and run the connection test.

The flespi connection guide walks through the exact ACL configuration. The important property: at connection time the agent can see your fleet, not change it. No device commands, no channel edits, no deletions. The token itself won't allow it, independent of anything configured on the CloudThinker side. Write access, if you ever grant it, is a separate, deliberate step tied to Auto Mode below.

What the agent watches continuously

Once connected, CloudThinker runs the part-two checks on a loop. Not a nightly export, a standing watch across the whole flespi account:

• Silent devices, with context. Last-message age is still the core signal, but the agent tracks each device's own reporting rhythm. A tracker that reports every 30 seconds going quiet for 20 minutes is an anomaly. A weekend-parked vehicle going quiet for 40 hours is normal. Static "offline if silent for X hours" thresholds, the best a DIY sweep can do, produce both false alarms and missed failures.
• Parsing errors per channel. Error and warning entries in channel logs are grouped by channel, protocol and message type, so a firmware rollout that starts producing malformed packets on one tracker model shows up as a pattern, not scattered log lines.
• Message-volume anomalies. Devices that suddenly send 30x their normal message rate (a misconfigured reporting interval, a tracker stuck in a retry loop) inflate your flespi message volume and your bill. The agent flags rate outliers per device and per channel.
• Connection flapping. Devices cycling connect and disconnect every few minutes, the classic signature of weak cellular coverage or a failing SIM, are separated from devices that are cleanly offline.
• Stream health. A stream forwarding data to your downstream platform that starts building a backlog or rejecting messages gets flagged before your downstream consumers notice missing positions.

The investigation: SIM, protocol, config or tracker?

When a device goes silent, the useful question is why, and the answer is almost always sitting in data flespi already has, spread across connection logs, message history and channel state. The agent runs the elimination an experienced fleet engineer would:

1. Did the device disconnect cleanly or drop? Connection events distinguish a device that closed its TCP session from one that timed out mid-stream. A clean close after ignition-off telemetry usually means a parked vehicle, not a fault.
2. Is the SIM still attaching? A device whose last messages show falling GSM signal, or one that flaps between short-lived connections, points at the cellular side (SIM, coverage or carrier) rather than the tracker.
3. Is the protocol parsing? If the device is connecting but its frames produce parsing errors in the channel log, the fault sits between firmware and channel configuration. That's common after a tracker firmware update changes the message format, or when a device is registered against the wrong channel for its protocol.
4. Is the hardware failing? Trackers whose final messages show degrading GPS fix quality, repeated internal-battery low events or reboots get classified as probable hardware, with the message history attached.

One device, worked through

Here's device 4471 the way CloudThinker works it. The details are illustrative.

At 03:22, device 4471 is ten minutes past its usual 30-second rhythm with the vehicle's ignition last reported on. Four readings fit, and each predicts different evidence: parked (a clean close after ignition-off), cellular (signal falling, reconnect bursts), protocol (connections that never produce messages) or hardware (power or GPS trouble at the end).

Connection state. The device record shows connected: false, and the device log shows the session timing out at 03:12 rather than closing. Not a clean close, so parked is unlikely, and protocol is unlikely because nothing is still connecting.

The last six hours of messages, pulled with only the fields that separate the readings:

curl -s -G "https://flespi.io/gw/devices/4471/messages" \
  -H "Authorization: FlespiToken $TOKEN" \
  --data-urlencode 'data={"count":500,"reverse":true,"fields":"timestamp,gsm.signal.level,position.satellites,external.powersource.voltage"}'

GSM signal falls from 24 to 3 over six hours. Satellites and external voltage stay normal. Hardware looks unlikely.

History. The same device flapped 14 times this week, always in the same depot area. No other device near it went quiet tonight, so this isn't a regional carrier outage.

The finding, posted in the fleet operations channel:

Device 4471: probable SIM or antenna fault. Dropped mid-session at 03:12. Last 6 hours show GSM signal falling from 24 to 3 with normal power and GPS. 14 reconnect bursts this week in the same depot, no neighbours affected. Proposed: run SIM diagnostics with the carrier before dispatching a technician. Owner: fleet hardware team.

Each finding carries the specific log entries and message parameters, so you verify rather than trust. No change was needed in flespi, so nothing waits for approval. The next step belongs to a person with a carrier portal.

---

Acting on the fix

The fixes that touch flespi are things like reassigning a device to the correct channel, correcting a reporting-interval parameter or restarting a stalled stream. Each one is prepared with its evidence. CloudThinker acts within Auto Mode, so you decide what runs on its own and what waits for approval.

Any write also needs a token with the matching write ACL on the flespi side. Every proposed and executed action lands in an audit trail: finding, evidence, proposal, approver, result and timestamp.

What a first fleet review typically surfaces

These numbers are illustrative, a composite of what a first pass tends to find on a mid-market fleet of around 5,000 devices across mixed tracker brands. Your fleet will differ.

Look at the shape. Roughly three-quarters of the raw "offline" count dissolves under triage into parked vehicles that were never a problem. What's left is a short work list with causes attached instead of a 200-row spreadsheet, and the two config findings (protocol settings, reporting interval) come with approval-gated fixes.

Why this beats the traditional approach

The deeper difference is where the hours go. With scripts, the time goes to collecting evidence for each device. With the agent collecting, your time goes to the decisions only your team can make: a carrier escalation, an RMA, a depot visit.

---

Prompts to try in your first session

CloudThinker is conversational. Ask in plain language, and each answer cites the underlying flespi data (the same logs and message history you'd pull with the part-two curl calls), so you can verify it rather than trust it:

"Which devices have been silent for more than 24 hours, and how many of those look like parked vehicles versus real faults?"

"We updated firmware on our Teltonika units last week. Did parsing errors change on their channel since then?"

"Device 4471 went quiet overnight. Work out whether it's the SIM, the protocol or the tracker. Propose only, change nothing."

"Are any streams building a backlog right now? If so, what do the stream logs say about why?"

"Summarize this week's fleet health for the ops review: silent devices, new faults, and anything trending worse."

---

What the agent won't do

"AI with access to the fleet platform" should prompt exactly these questions. Here are the answers:

• Read-only by default. The scoped flespi token grants no write access at connection time. Any change needs a write-scoped token you grant, and then goes through Auto Mode.
• No device commands, setting changes or deletions you haven't allowed. Without a write-scoped token, they can't happen at all.
• No bypassing the audit trail. Every finding, proposal, approval and action is logged with its evidence.
• No fleet decisions. Whether to switch carrier, RMA a batch of trackers or re-provision a depot's installs stays your call. The agent makes sure it's an informed one.

From fleet snapshots to fleet answers

Part one showed where fleet telemetry operations break at scale. Part two gave you every native flespi tool to detect it. What remains is investigation at fleet scale, and that doesn't fit in a cron job. Teams that move from manual silent-device sweeps to continuous, evidence-backed triage typically cut device-health investigation time by well over half, and catch config faults (parsing, reporting intervals, duplicate idents) days earlier.

Related reading

• How an Australian telematics provider automates day-to-day operations with CloudThinker
• Auto Mode: you decide what runs on its own
• CloudThinker Connections

Try CloudThinker free with 100 premium credits and no card required, and follow the flespi connection guide to see your own fleet's first triage within the hour.