How many vehicles are online is not one question
Wialon gives you seven states, not a boolean. Two panels on the same dashboard said 19 and 29 for a fleet of 58 — here is the rule that settled it.
A dashboard we were building said 19 vehicles were online. A panel further down the same page said 29. The fleet had 58 units and both numbers were computed from the same data, a few hundred pixels apart.
Neither was a bug in the arithmetic. They were two different opinions about what online means, and Wialon supports both.
What Wialon actually gives you
A unit does not carry a boolean. What you can read is a last message, a position with a timestamp, an ignition sensor, a movement flag and a connection state — and from those, an account can be sorted into states that are all reasonable and all different:
- moving — reporting, and the position is changing
- online — reporting, in contact, not moving right now
- stationary, and separately stationary with the ignition on — parked with the engine running is a different fact from parked
- LBS — located by cell tower rather than by satellite, so it is in contact but the position is coarse
- offline — not in contact
- no actual state — in the account, but there is no current data to judge by
- no messages — it has never reported at all
The last two are the ones that produce disagreements. A unit that has never sent a message is not offline in any useful sense — it is unconfigured, or it is a spare, or somebody created it last week and the hardware is still in a box. Counting it as offline makes a healthy fleet look broken. Counting it as online makes a broken one look healthy.
The rule we settled on
Connected is moving, online, stationary, stationary with ignition and LBS. Offline is offline. No actual state and no messages are their own groups and are never folded into either.
That last part matters more than the grouping. A fleet of 96 where 6 have never reported is a different conversation from a fleet of 90. Hiding those six inside "offline" answers the question you were asked and loses the one you should have asked.
Count in one place
The actual fix was not the rule — it was having exactly one function that applies it. Every view that shows a number calls it. The two numbers on our dashboard existed because two components each counted statuses inline, and each stopped at a slightly different place in the list.
This is the boring kind of bug: no exception, no failed request, nothing in a log. Just two numbers that could not both be right, and a page that had shipped looking fine.
Why an assistant makes this worse before it makes it better
Ask a language model "how many vehicles are online" and hand it a list of units with a raw status field, and it will count something. It will count confidently. What it counts depends on the wording of the question and on how the statuses happen to be spelled.
So the tool answers with the counts already made, not with rows to be counted, and the status vocabulary is translated before it reaches the model: no_messages becomes "has never reported", no_actual_state becomes "no current data". A raw status code should never reach a person, and it turns out it should not reach a model either.
