Automating flespi Fleet Telemetry Analysis with AI Agents

A morning report that says "40 devices offline" is not 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 are running a tracker firmware version with a known GPS-fix bug" is information. The first one costs your team a day of clicking through the flespi panel. The second one is what this article is about.

This is part three of our flespi fleet telemetry analysis series. Part one mapped what goes wrong in GPS fleet monitoring at scale — silent devices, protocol parsing failures across mixed tracker fleets, parameter drift, and the channel/device/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 what the fleet looks like right now, and it tells you brilliantly — but the why behind every silent device still needs an engineer to go 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 article covers moving that loop to CloudThinker agents: connect read-only, let the agents watch device health continuously, and let them do the SIM-vs-protocol-vs-config-vs-hardware elimination work before a human ever looks.

Connecting: a scoped flespi token, about 5 minutes

CloudThinker connects to flespi the same way your own scripts from part two did — with a flespi token — but you should 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 the resources the agents need: devices, channels, streams, logs, and messages under the gw (telematics gateway) API.
3. Set an expiration policy 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 agents can see your fleet, not change it. No device settings 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 the autonomy levels below.

What the agents watch continuously

Once connected, CloudThinker agents run the part-two checks on a loop — not as a nightly export, but as a standing watch across the whole flespi account:

• Silent devices, with context. Last-message age is still the core health signal, but the agents track 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 you can do with a DIY sweep — 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 as 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 agents flag rate outliers per device and per channel.
• Connection flapping. Devices cycling connect/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. If a stream forwarding data to your downstream platform starts accumulating a backlog or rejecting messages, that's flagged before your downstream consumers notice missing positions.

The investigation layer: is it the SIM, the protocol, the config, or the tracker?

This is the part that native tools don't do at all. When a device goes silent, the interesting 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 agents run the elimination sequence an experienced fleet engineer would:

1. Did the device disconnect cleanly or drop? Channel connection logs 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 declining GSM signal values, 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 messages produce parsing errors in the channel log, the fault is between firmware and channel protocol configuration — commonly 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 itself failing? Trackers that reported degrading GPS fix quality, repeated internal-battery low events, or reboots in their final messages before going silent get classified as probable hardware, with the supporting message history attached.

The output isn't "device 4471 offline." It's "device 4471 dropped mid-session at 03:12, its last 6 hours of messages show GSM signal falling from 24 to 3, and it has flapped 14 times this week — probable SIM or antenna fault; suggest a SIM diagnostics check before dispatching a technician." Each finding carries the evidence — the specific log entries and message parameters — so you verify rather than trust.

Graduated autonomy: what the agents may act on

Every action class gets an autonomy level you set explicitly:

• Notify — report the finding and the diagnosis. The default for everything.
• Suggest — propose a specific fix: reassign a device to the correct channel, correct a reporting-interval parameter, restart a stalled stream.
• Approve — the agent prepares the action and executes only after a named human approves it in the queue.
• Autonomous — execute and report. Sensible only for narrow, reversible actions — restarting a backlogged stream, say — and only after you've watched the agent be right at the Approve level for a while.

Anything above Notify requires a token with the corresponding write ACL — you grant capability on the flespi side and permission on the CloudThinker side, and both have to agree. Every proposed and executed action lands in an audit trail: finding, evidence, proposal, approver, result, timestamp.

What a first fleet review typically surfaces

Illustrative numbers — 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.

The pattern worth noticing: roughly three-quarters of the raw "offline" count dissolves under triage — parked vehicles that were never a problem. What remains is a short, causally-labeled work list instead of a 200-row spreadsheet, and the two config-class findings (protocol settings, reporting interval) come with approval-gated fixes attached.

Prompts to try in your first session

The agents are conversational — you ask in plain language, in chat:

• "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?"
• "Summarize this week's fleet health for the ops review: silent devices, new faults, and anything trending worse."

Each answer cites the underlying flespi data — the same logs and message history you'd pull manually with the part-two curl calls.

What the agents will not do

Because "AI with access to the fleet platform" should prompt exactly these questions:

• They are read-only by default. The scoped flespi token grants no write access at connection time; remediation requires both a write-scoped token and an autonomy level above Notify.
• They never send commands to devices, change device or channel settings, or delete anything without approval — unless you have deliberately set that specific action class to Autonomous.
• They don't bypass the audit trail. Every finding, proposal, approval, and action is logged with its evidence.
• They don't make fleet decisions. Whether to swap a carrier, RMA a batch of trackers, or re-provision a depot's installs remains your call — the agents just make sure it's an informed one.

From fleet snapshots to fleet answers

Part one showed you where fleet telemetry operations break at scale; part two gave you every native flespi tool to detect it. The gap that remains is investigation at fleet scale — and that's the part 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-class faults (parsing, reporting intervals, duplicate idents) days earlier.

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