Find out where the car is and how it is doing, from chat

The agent calls the StarLine API and starts from the account: it reads the user profile, collects the list of devices and then, for each device, pulls its data and state — coordinates and speed from the GPS module, the alarm, doors and ignition, the fuel level, the battery voltage and the engine temperature from OBD diagnostics, the event history and the alarms that fired. Out of that come summaries of the day's trips and of the readings that dropped over the week.

Telematics shows not the car but the last packet the unit managed to send: in an underground car park or with a weak signal the data freezes. So the agent always names the time of the last update next to the coordinates and never passes yesterday's point off as the current one. For the same reason it distinguishes the alarm state read from the unit from a command you have just sent: until a fresh packet arrives, that is not yet a fact.

Remote commands — arming the alarm, warming up the engine — are an action on a real car, so the agent runs them only after your explicit confirmation in the chat and names the device it is addressing. After a command it re-reads the state of the unit and says whether the command took effect or not. Everything else — coordinates, diagnostics, trip history — runs read-only.

The connector raises the session itself: the application signs the request, the account confirms it, and from there the agent works on the issued token, renewing it when it expires. It polls on a schedule or on your request and stays inside the thousand calls a day, so the car's state is not pulled every minute and trip history is collected in one batch for the period. About data the unit did not send — a sensor that is not fitted, a lost signal — the agent says so plainly instead of filling in a zero.