We implemented a new counter type - variable. Value of this counter is dynamically updated from the left to the right with each message pass and it is possible to access it in expressions of all other counters and validate_interval, validate_message fields as well.

This opens a totally new possibility to have some state during counters calculations.

For example it is possible to ignore X count or Y seconds initial messages from the moment interval has started. Or ignore all other iButton/RFID codes except the very first.

Variable value is accessed with variable("name") call. Check this artificial sample of 2 counters which will generate a timestamp of the 5th harsh acceleration event withing interval under name harsh.driving.started:

Please note that variables are not available during intervals markup with selectors, but once interval is marked up and its calculation began variables can be used everywhere.

In flespi analytics we updated the behavior of interval calculations for messages with timestamp.key parameters. timestamp.key is a special parameter that is usually constructed from the original timestamp sent by device with event.seqnum (record/event sequence number) added in fraction part. This method is used to store and process multiple messages with the same timestamp but different record sequence numbers.

Previously the value inside timestamp.key was taken as interval begin and end which could result in intervals with fraction ranges and duration.

Now we will always take just the original timestamp value as was reported by the device for the interval begin or end.

This behavior change may result in a slightly higher level of events from the flespi analytics system towards your integration as some intervals will have timing changed.

New function is now available in analytics expressions: weekday(timestamp). It will return day of week for its argument starting from Monday (1) to Sunday(7).

We are currently upgrading the flespi analytics system with a new communication and storage architecture, moving its operational data out of RAM into MQTT and local cache. This process started on Monday March 18 and will take around a week.

The general architecture of the analytics system and its algorithms for device messages processing remained the same, we just changed the communication system between services and instead of a RAM cache we will use a distributed drive-backed mapped cache.

We do not expect any impact on the intervals calculation system - everything is covered with a very large set of cruel unit and runtime tests and we are keeping an eye on any possible problem that may popup. However if you notice something strange in the analytics system behavior please let us know in flespi chat.

Currently we have already upgraded 15% of nodes where analytics calculations are running and will slowly upgrade remaining nodes.

After the upgrade we will have a lot of new functional possibilities available inside analytics. And the very first in our features list is the possibility to use device metadata in calculators to configure flexible per-device algorithms with a single calculator. We will implement it shortly after the upgrade.

We adjusted the contents of interval JSON generated by flespi calculators to always reflect in its JSON fields all defined counters.

Counters that were not able to calculate a value within interval messages will now store null values to the interval JSON. Previously such counters did not add any value to the interval which we consider inconsistent.

Please adopt your integration to that change if required.

We've modified the logic inside inactivity detection selector in flespi analytics. The change in logic affected only the indicated end time of detected inactive interval. It was extended up to the moment of connectivity with the device was restored.

Previously the end time of such interval was a last message with latency beyond configured. This is indicated on a screenshot below from a inactivity detection calculator with 60 seconds configured allowed data latency. At the top of screenshot you can see interval and at the bottom last included messages (highlighted):

As you can see at 07:26:05 connectivity was restored, but the end of interval was indicated as 07:25:04 - it was the timestamp of last message with latency above configured 60 seconds.

The new logic will finish such interval on the last reported message before the connectivity was restored. Here is the same data calculated with a new logic:

In this logic message with timestamp 07:26:04 was included into inactivity period, because connectivity was restored at 07:26:05.

We enhanced parameter interval counter with method=distinct. Now it is able to add to the interval (e.g. trip) a list of all unique geofences visited, BLE beacons detected or DTC codes reported.
Of course It will also work with other parameter that you may have in device message.

Check the details in this KB article covering these use cases.

Now it is possible to add to the interval in one calculator aggregated data from intervals of another calculator. You can do this by utilizing two new methods for calculator counters of type=”calc”: aggregate and aggregate_by_field:

• “aggregate” will aggregate all intervals into a single resulting object.
• “aggregate_by_field” will take the first defined field as a key and aggregate all intervals with the same key into a single resulting object. The output of that counter will be an array of stats per each encountered key.

Also for counter type=”calc” we enabled the usage of flespi expressions in fields configuration. This is available for all methods, not only for aggregation.

You can read more information about the usage of this new functionality in a related KB article describing the method how to calculate aggregated time spent daily in each geofence.

flespi analytics system received new intervals processing engine. This may affect how calculator's intervals are detected in real-time - created, updated and deleted.

We implemented a huge set of tests to ensure seamless upgrade of this engine however in such complex system as telematics analytics anything can go wrong.

We expect that it should now process data from your devices better and detect more complex edge cases but if you notice something strange with intervals detection please contact us in HelpBox with all details to look into your case.

We enabled geofences assigned directly to devices in flespi analytics.

So right now there are 3 variants how you can control geofences with calculators:

• assign geofences to calculator either directly or indirectly via groups;
• assign geofences to device;
• specify geofences geometry directly in interval selector (only to detect entrance/exit by the selector);

When you hit test current message with geofence() or geofences() function in calculators' expressions both geofences linked to the device and calculator are analyzed together, based on their actual priority and geometry.

To simplify the setup we recommend to use in your flespi-based project one of these methods only. However if both device and calculator have linked geofences you will have a combined hit-test result in expressions. Later we may add to calculators the configurable selection of geofences source (device, calculator or both) if there will be appropriate demand.

We implemented 2 new functions to work with JSON arrays inside expressions:

• json_array_contains(X, Y): will return true if array X contains value Y or false otherwise. For string values wildcards can be used as well. For example next expression will test if DTC codes reported by device contain any DTC code that starts from "P": json_array_contains(dtc.codes, "P*").
• json_array_find(X, Y): will apply expression Y to each item in JSON array X and return first matched item or null otherwise. For example to fetch BLE beacon with specific ID defined in device's metadata it is possible to use next construction: json_array_find(ble.beacons, "id == '" + tostring(metadata("sensor_id")) + "'"). If device's metadata contains sensor_id with value "ABCD" the function call will be equivalent of: json_array_find(ble.beacons, "id == 'ABCD'"). It's important to format expression in argument Y correctly, en-quoting all strings.

When applying these functions we suggest to use special tool to test your expression before using it in calculator or plugin configuration to avoid syntax mistake.

These new functions can be used in any flespi subsystem: calculators, plugins, webhooks, stream validators, REST API calls. The most common areas of application are DTC codes, BLE beacons and any other array structure reported by devices or constructed with plugins.

We enhanced the flespi analytics system with the possibility to access values located in the previous interval when calculating or validating the next one.

This functionality is available via counter type=”interval” and validate_interval expression.

There you may operate with values calculated by current interval counters and apply some logic mixing values calculated/stored in previous interval. You can access such values using the previous(“interval-counter-or-property”) call.

For example, to know the difference between the end of previous interval and beginning of current interval you may use the counter of type=”interval” and expression: if(previous('end'), begin - previous('end'), 0).

Or if you would like to prevent intervals creation within 1 hour from the end of the previous interval you may put into validate_interval the following expression: begin - previous('end') >= 3600.

As a bonus and for really complex cases previous function will allow you to retrieve the data not only calculated by the counter by also attached to the interval via PUT /gw/calcs/{calc_id}/devices/{device_id}/intervals/{previous-interval-id} call. For example you may attach to some interval user data and subsequently copy its value to all further intervals until the next user-data. For example, for counter name=”datacache”, type=”interval” you may use the next expression: if(previous('userdata'), previous('userdata'), previous('datacache')) and attach to the interval custom value under 'userdata' key.

The deprecated calc_id parameter in POST /gw/devices/{dev-selector}/calculate REST API call was finally removed.

Now it is possible to include intervals from another calculator that happened before or after the current interval's time range. You can do this by utilizing two new parameters for calculator counters of type="calc": lookup_time_before and lookup_time_after.

• lookup_time_before - specify how many seconds to look back before interval begin to search for intervals
• lookup_time_after - specify how many seconds to look forward after interval end to search for intervals

Both parameters can be set up to 10 days and work in conjunction with existing allow_start_before and allow_finish_after boolean flags. This allows for precise control over which intervals to include in calculations.

This functionality is particularly useful for Hours of Service (HoS) calculations where you need to analyze cumulative driving time. For example, you can add to the current trip interval the combined driving time from all trips that happened within the last 7 days, helping to ensure compliance with driving time regulations.

The parameters complement the existing aggregation capabilities of calc counters, allowing not only to combine intervals within the current time range but also to look beyond it when needed.

New Aggregation Methods for Message Counter in Calculators

We've enhanced the calculator counter of type "message" with two powerful aggregation methods:

• aggregate - combines multiple messages into a single value with summated fields
• aggregate_by_field - groups messages based on the first field, then aggregates them into single values per group

These new methods are particularly useful for analyzing and summarizing device data by specific identifiers. For example, you can now easily track driver activity statistics:

{
  "type": "message",
  "name": "driver_stats",
  "method": "aggregate_by_field",
  "fields": [
    "driver.id",
    {
      "name": "drive_time",
      "expression": "position.speed > 0 ? (timestamp - previous(\"timestamp\")) : 0",
      "aggregate": "summary"
    },
    {
      "name": "distance",
      "expression": "mileage()",
      "aggregate": "summary"
    },
    {
      "name": "trips_count",
      "expression": "position.speed > 0 && previous(\"position.speed\") == 0 ? 1 : 0",
      "aggregate": "summary"
    }
  ],
  "validate_message": "exists('driver.id')"
}

This configuration will:

1. Group all messages by driver ID
2. Calculate total driving time for each driver
3. Sum up the distance traveled by each driver
4. Count the number of trips initiated by each driver

The resulting interval JSON will contain an array of objects, each representing a unique driver with their activity metrics:

{
  "driver_stats": [
    {"driver.id": "D12345", "drive_time": 14520, "distance": 187.5, "trips_count": 5},
    {"driver.id": "D67890", "drive_time": 9360, "distance": 112.8, "trips_count": 3}
  ]
}

This enhancement makes it much easier to create meaningful summaries of data grouped by specific identifiers without requiring complex post-processing.

We've improved recently introduced aggregate_by_field method in message and calc counters to preserve the original data types of aggregated values. Previously, all aggregated field values were converted to strings, but now they retain their original data types (numbers, booleans, etc.).

Example:

When aggregating messages by voltage with this counter configuration:

{
  "fields": [
    {
      "aggregate": "first",
      "expression": "floor(external.powersource.voltage)",
      "name": "voltage"
    }
  ],
  "method": "aggregate_by_field",
  "name": "voltages",
  "type": "message"
}

Before: Values were converted to strings

"voltages":[{"voltage":"15"},{"voltage":"13"},{"voltage":"14"},{"voltage":"12"}]

After: Values maintain their original type (numeric in this case)

"voltages":[{"voltage":15},{"voltage":13},{"voltage":14},{"voltage":12}]

We enabled assets integration with flespi analytics.

Assets are virtual entities representing physical objects like drivers, trailers, or vehicles that can be monitored by different tracking devices over time.

Assets can be assigned to calculators either directly or indirectly via groups. Once assigned, you can use two new functions in calculator expressions:
• asset() - returns the asset with the highest priority to which the device was linked at the given time, or null if no asset is assigned;
• assets() - returns an array of all assets to which the device was linked at the given time.

Calculator automatically triggers interval recalculation for all assigned devices when its list of assigned assets changes or when any asset interval is updated.