Fuel is the largest controllable cost in most fleets and the least trusted number in most reports. The reason is rarely that Wialon is wrong. It is that “fuel consumption” is three different measurements wearing the same label, and a report that mixes them, or that runs over units where the sensors were never configured, produces a total that is confidently incorrect.
Three ways to get a consumption figure
By rates. A norm — litres per 100 km, sometimes adjusted for season or load — applied to the distance driven. No sensor involved. It is a budget, not a measurement, and it is the right answer for a vehicle with no fuel hardware at all. Its weakness is obvious: it cannot detect the thing you most want to detect, because a stolen litre does not change the calculation.
By a math or impulse sensor. The engine, or a flow meter, reports how much it burned. Accurate for the engine’s own consumption, and blind to everything that leaves the tank without going through it.
By fuel level sensor (FLS). The level in the tank, sampled over time, with the volume that went in during the interval accounted for. This is the only method that can see a theft, and the only one whose accuracy depends on how well somebody calibrated a sensor two years ago.
Wialon can run all three. They will not agree, and the gaps between them are informative: rates versus FLS is roughly “what we expected versus what left the tank”; math sensor versus FLS is roughly “what the engine burned versus what left the tank”, and a persistent gap there is worth a conversation.
What filtration is doing to your data
Fuel level data is noisy by nature. A tank sloshes on a roundabout, a sensor twitches, a vehicle parked on a slope reads differently from the same vehicle on the flat. Left raw, that noise reads as a sequence of small fillings and thefts that never happened.
Wialon’s answer is median smoothing, set by the filtration level, a value from 0 to 255. At 0 the smoothing window is three messages; above that the window widens with the setting. The trade-off is direct and unavoidable:
- Too little filtration and the report invents events — a fleet manager chasing thefts that were corners.
- Too much filtration and a real event is averaged away — a slow siphoning over twenty minutes becomes a gentle slope that nothing flags.
There is no universally correct value. There is a value that is correct for a particular tank shape, sensor and route profile, and finding it means comparing flagged events against things you know happened.
Fillings and thefts are thresholds, not truths
Two more settings decide what appears in the report at all. A level increase is only treated as a filling if it exceeds the configured minimum, and a decrease is only treated as a theft if it exceeds its own minimum. Fillings detected close together can be merged into one when the gap is inside the configured timeout — which is what you want for a two-stage fill at a pump, and what you do not want if it hides a top-up.
The practical consequence: a fleet reporting “no thefts this quarter” may be reporting nothing more than a threshold set above the amount anyone would bother stealing. Check the thresholds before you trust the absence of events.
Note as well that fillings and thefts are only detected when the unit actually has fuel level sensors and the option is enabled. On a mixed fleet that condition quietly holds for some vehicles and not others.
Sanity-check the fleet before the report
The most common way a fuel report misleads is not a wrong setting on one vehicle. It is a report run across a group where a third of the units have no fuel sensor configured, silently contributing zeros to a fleet average.
So the first question about any fleet-wide fuel number is: which units contributed real data? That is a coverage question, not a fuel question, and it is answerable before you run anything — FleetTAB’s Events view lists every unit against the detectors it actually reports, so you know whether a fleet total rests on 40 vehicles or 27. The Assets table does the same for last known values, which is where you spot the sensor that has been reading a flat 0 since March.
Making fuel a number people watch
A quarterly report that nobody opens does not reduce fuel spend. Three things change that:
Put it next to the behaviour that causes it. Idle time and harsh acceleration are fuel, expressed as driving. A dashboard that shows litres beside idle hours and eco-driving scores invites the connection; three separate reports do not.
Compare like with like. Litres per 100 km across a fleet of vans and tippers is a meaningless average. Per vehicle class, per route type, per driver — those comparisons carry information.
Watch the trend per vehicle. A van whose consumption drifts up 8% over two months is telling you something mechanical, long before anything fails. Single-period reports never show it; the same card over a rolling period does.
Where FleetTAB fits
FleetTAB does not re-measure fuel — the sensors, the calibration and the detection stay in Wialon, where they belong. What it adds is the framing: fuel cards on a dashboard you assemble next to idle, distance and violation counts, over a period and a unit selection you set once for the whole board, and exportable exactly as filtered.
It is free on your own Wialon account, and connecting takes one API token.
Sources: Wialon’s documentation on calculating consumption and additional settings of fuel level sensors.
