get_last
To retrieve the current state of an active event or the last known state of a completed event, use the events/get_last method.
Unlike events/get, this method doesn’t require events to be loaded into the session and doesn’t return event history.
Endpoint
svc=events/get_last¶ms={
"itemId": <long>,
"type": <text>,
"filter1": <long>,
"filter2": <text>,
"detalization": <uint>,
"measure": <uint>,
"lang": <text>
}
Parameters
The request can contain the following parameters:
| Parameter | Description |
|---|---|
itemId |
Required. Unit ID or resource ID. The resource ID is required for the resource_drivers detector (driver-assignment events). |
type |
Name of the event detector to query. If omitted, the method returns the state of all available detectors. You can use a detector key from that response as the value in a following request. |
filter1 |
Detector filter. For sensor-based detectors, specify a sensor ID, or 0 for all sensors of this type. For resource_drivers, specify a driver ID, or 0 for all drivers. For eco_driving, specify a criterion type, or 0 for all criterion types. For health_check, specify an incident type, or 0 for all incident types. For trips, counters, and speedings, use 0. The default value is 0. |
filter2 |
Optional. Additional detector filter by name. It works only for detectors that register events for a specific sensor or driver: sensor-based detectors (filter by the sensor name) and resource_drivers (filter by the driver name). For trips, counters, speedings, health_check, and eco_driving, the value is ignored. Specify one name, or several names separated by commas, and use the wildcards * and ? if needed, for example, Fuel*,Tank?. This filter is applied only when filter1 is 0. The default value is an empty string (""). |
detalization |
Output flags. Must be specified in decimal format. The default value is 7 (0x7). See below. |
measure |
Measurement system: 0 for SI/metric, 1 for US, 2 for imperial, or 3 for metric with gallons. The default value is 0. |
lang |
Language (2-character code). The default value is en. |
Flags
| Flag | Description |
|---|---|
0x1 |
Basic event data: times, coordinates, and event service flags. |
0x2 |
Detector-specific data. |
0x4 |
Parameters from the message associated with the event. |
0x8 |
Additional event data when supported by the detector. |
0x10 |
Detailed message data when supported by the detector. |
0x20 |
Formatted detector values. |
0x100 |
Additional events registered by the fuel_level and battery_level detectors with the values collected since the previous event. Not required for most integrations. |
Response
If the request is completed successfully, the response contains an object keyed by detector type. Otherwise, an error code is returned.
The data structure inside each key depends on the detector and the requested flags.
Common structure
With the 0x1 flag, the trips and counters detectors return their data directly, in the following structure. Other detectors group event objects by a detector-specific ID, as shown in the examples.
{
"<detector_type>": {
"from": {
"t": <uint>,
"y": <double>,
"x": <double>
},
"to": {
"t": <uint>,
"y": <double>,
"x": <double>
},
"m": <uint>,
"f": <uint>
}
}
| Field | Description |
|---|---|
from |
Event start data: t for UNIX time, y for latitude, and x for longitude. |
to |
Last processed message data: t for UNIX time, y for latitude, and x for longitude. |
m |
Last processed message time, UNIX time. |
f |
Event service flags. |
For a private position, the x and y values are returned as 0.
The other flags return the same data as the corresponding flags of events/check_updates: detector-specific data (0x2), parameters of the message associated with the event (0x4), additional detail data (0x8), detailed message data (0x10), and formatted values (0x20). For the resource_drivers detector, the returned fields are described in the example below.
Error codes
| Code | Description |
|---|---|
| 1 | Invalid or obsolete request SID. |
| 4 | Parameter validation error. |
| 5 | Events are disabled or being initialized. |
| 7 | The event service is unavailable, the item can’t be retrieved, or the user doesn’t have view access to the specified unit or resource. |
Examples
The following examples show how to retrieve event states for different use cases.
Retrieving all detector states for a unit
To retrieve the state of all available detectors for a unit, specify only the unit ID:
svc=events/get_last¶ms={
"itemId": <unit_id>
}
The response is an object keyed by each available detector type:
{
"<detector_type>": {
"...": "..."
}
}
Retrieving the current fuel level state
To retrieve the fuel level state for all fuel level sensors of a unit, specify the unit ID and the fuel_level detector. Use detalization 39 (0x27) to include basic event data, detector-specific data, message parameters, and formatted values:
svc=events/get_last¶ms={
"itemId": <unit_id>,
"type": "fuel_level",
"filter1": 0,
"filter2": "",
"detalization": 39
}
The response is grouped by sensor ID. With detalization 39 (0x27), it can contain the following fields:
{
"fuel_level": {
"<sensor_id>": {
"from": {
"t": <uint>,
"y": <double>,
"x": <double>
},
"to": {
"t": <uint>,
"y": <double>,
"x": <double>
},
"m": <uint>,
"f": <uint>,
"value": <double>,
"raw_value": <double>,
"filled": <double>,
"timeDiff": <uint>,
"latDiff": <double>,
"lonDiff": <double>,
"format": {
"value": <text>,
"raw_value": <text>,
"filled": <text>,
"theft": <text>,
"custom_value": <text>
}
}
}
}
Retrieving the current driver-assignment state
To retrieve the current state of driver assignments, specify the resource ID and the resource_drivers detector. Set filter1 to a driver ID to get the state of one driver, or 0 for all drivers. The detalization value 7 (0x7) returns basic event data, detector-specific data, and parameters from the message associated with the event.
svc=events/get_last¶ms={
"itemId": <resource_id>,
"type": "resource_drivers",
"filter1": 0,
"filter2": "",
"detalization": 7
}
The response is grouped by driver ID. Each driver ID has one object that describes the current state of that driver.
{
"resource_drivers": {
"<driver_id>": {
"from": {
"t": <uint>,
"y": <double>,
"x": <double>
},
"to": {
"t": <uint>,
"y": <double>,
"x": <double>
},
"m": <uint>,
"f": <uint>,
"state": <uint>,
"aflags": <uint>,
"unit_id": <long>,
"real_time_from": <uint>,
"validate_sensor_id": <uint>,
"switched_to": <long>
}
}
}
The from, to, m, and f fields are described in the common structure. The detector also returns the following fields:
| Field | Description |
|---|---|
state |
Current driver state: 0 for unassigned or 1 for assigned. |
aflags |
Assignment flags (see below). |
unit_id |
For state 1, ID of the unit to which the driver is assigned. For state 0, ID of the unit from which the driver was unassigned, or 0. |
real_time_from |
Actual assignment start time, UNIX time. If a long assignment was split into several events, this is the start time of the earliest event in the chain. |
validate_sensor_id |
ID of the sensor used to validate the unassignment. The value is 0 when validation isn’t used. |
switched_to |
ID of the unit to which the driver was switched. Returned only when the value isn’t 0, which means the driver was assigned to another unit without being unassigned from this one. |
The aflags field can contain the following flags. The same flags are used in the completed events returned by events/get, so a current state usually contains only the flags that describe how the assignment started.
| Flag | Description |
|---|---|
0x1 |
The driver was switched to another unit. The unit ID is returned in switched_to. |
0x2 |
The assignment switched the driver from another unit. |
0x4 |
The assignment was started manually. |
0x8 |
The assignment was ended manually. |
0x10 |
The driver was unassigned because an exclusive driver was assigned to the same unit. |
0x20 |
The assignment was ended because an exclusive driver was assigned to the same unit. |
For
state0, thetoobject doesn’t show the time and place of the unassignment. It shows the last processed message. The unassignment time is the end time of the completed event in the event history, which you can retrieve with events/get.