Place for information about telematics hub updates.

We supported special streaming protocol called nis . This protocol is used in Russia only, and although it is very stupidly designed - HTTP/SOAP based with just one message per HTTP request - it is quite popular on CIS space for inter-servers communications. Feel free to use it.

nis streaming protocol was updated to send values for Digital inputs, outputs and Analog inputs. The number of streamed Analog inputs is limited up to 8 for nis and wialon_retranslator streams.

We have removed deprecated fields " ident " and " phone " from the devices REST API. These fields was left for backward compatibility for a few months. In addition, we have removed old stream subscriptions REST API methods also marked as deprecated a few months ago. More details are placed in this article: https://flespi.com/blog/sync-up-with-changes-in-the-flespi-device-api

Platform has changed the way it accumulating logs when operating under subaccounts hierarchy . Say you have account root with subaccount sub and it branched another subaccount subsub . Tree looks like this: root<=sub<=subsub. Now imagine that you have log message for the subsub account, for example device was connected. Before the update : logs both in realtime (subscribing to flespi/logs/#) and in history mode (accessible via REST ) where placed by the system into an account subsub and all its parents: sub and root . Thus when operating with large volumes we have quite a big storage size of root top-account basically multiplied by the number of subbaccounts it has. After the update : the log message will be stored exactly and only at the account where it was generated. E.g if you have device or channel that belong to some subaccount you can access log messages for this entity only from its account. This is applied to both REST and MQTT. Toolbox was modified accordingly and now has account selector whenever you have some flespi accounts to switch between.

We increased telemetry expiration time up to 370 days.

We've added the "status" field for each device setting. It's indicating the source of the current setting value (if available) and the flespi platform intention to read the new current value or apply the pending setting value. The full documentation is available here: https://flespi.io/docs/#/gw/!/devices

Platform update affects devices with ident collisions. Collision occurs when two or more devices have the same ident, device type and share a common channel. The device with the lowest identifier remains unlocked, other devices will be blocked using the "bad configuration" code.

adsa We have reverted update until some problems being solved.

Next Monday, on October 14, we will install an update with the small change in our Telematics Gateway REST API. Once installed, the devices creation method ( POST , https://flespi.io/docs/#/gw/!/devices/post_devices ) will require the " device_type_id " and " configuration " fields to be specified. Also, the " configuration " object for all device types will require an " ident " field. Please review your integrations and correct them to always include such fields when you're creating devices. If you have any questions, please contact us in the chat embedded in the flespi.io panel or on forum.flespi.com

adsa The problems were resolved and the update was installed.

[Changelog] flespi telematics hub

adsa

Important: Upcoming Change to Parameter Naming Validation

We've identified an inconsistency in how flespi handles parameter names containing minus signs (-) that we need to address.

Current Situation:

Device messages currently accept parameter names with minus signs (e.g., "engine-rpm", "custom-value")
However, device telemetry doesn't support minus signs in parameter names
This causes parameters with minus signs to be missing from telemetry, even though they appear in messages

What's Changing:
To ensure consistency across the platform, we will synchronize the validation rules. After this update, device messages will no longer accept parameter names containing minus signs.

Impact:

Any existing parameters with minus signs will need to be renamed
This affects custom parameters sent via HTTP/MQTT channels or created by plugins
Standard flespi parameters are not affected (they already follow the correct naming convention)

Recommended Actions:

Review your device configurations and custom integrations for parameter names containing minus signs
Replace minus signs with underscores (e.g., "engine-rpm" → "engine_rpm") or dots for hierarchy (e.g., "engine-rpm" → "engine.rpm")
Update any applications or scripts that send data to flespi with the new parameter names
If using plugins that create parameters with minus signs, update their configuration

Best Practice Reminder:
Parameter names should only contain:

letters (a-z)(A-Z)
Numbers (0-9)
Dots (.) for hierarchy
Underscores (_) as separators

This change ensures that all parameters visible in messages will also be available in telemetry, providing a more consistent and reliable experience.

adsa

The maximum webhook response size has been reduced from 32MB to 8MB, and responses exceeding this limit will now interrupt processing.

shal

We added "blacklisted IP" field for all protocols using which you may block certain IP networks from posting messages to your channel.

And we introduced new limit on number of UDP packets per minute channel can pass through.

kial

We've added an optional "meta":{...} field for commands sent through device commands queue or in real-time mode. More details in kb article

shal

We added to assets the possibility to track currently active interval via MQTT topic flespi/state/gw/assets/{id}/active. This enhances assets application for assignments planning purposes.

We also modified recently added device commands customization by renaming the field from metadata to meta in the API call for naming consistency with other flespi systems.

adsa

Maximum nesting level for webhook message JSON payloads is now limited to 16 levels.

adsa

We discovered an incorrect response format in the POST /gw/devices/{dev-selector}/messages REST API method. The current response contains an unnecessary nested array within the result array, which deviates from standard flespi API response format.

Current (Incorrect) Response Format:

{
  "result": [
    [
      {
        "device_id": 123,
        "msgs_count": 5
      }
    ]
  ],
  "errors": []
}

New (Correct) Response Format:

{
  "result": [
    {
      "device_id": 123,
      "msgs_count": 5
    }
  ],
  "errors": []
}

What's Changing:

The secondary nested array will be removed from the response
Each device's result will be a direct object within the result array
This aligns the response format with other flespi REST API methods

Timeline:

Announcement Date: October 2, 2025
Implementation Date: November 1, 2025 (30 days from announcement)

Action Required:
If your application parses the response from POST /gw/devices/{dev-selector}/messages, please update your code to handle the corrected response format before November 1, 2025.

Note: This change only affects the response structure. Request format and API functionality remain unchanged.

adsa

We've added messages and traffic fields to device REST API and MQTT retained topics.

messages - Message count received in the last minute
traffic - Traffic in bytes received/sent in the last minute

shal

According to recent announce device media traffic (video/photo/tacho uploads) is now again counting towards channel traffic limit.

This affects all active users of video telematics functionality in flespi and may require plan upgrade or distributing devices across multiple channels to manage traffic effectively.

When channel traffic limits are exceeded, the platform now implements smart blocking:

Identifies the most active devices (by traffic volume in the last minute)
Blocks only the minimal number of devices needed to bring traffic below limits
Blocked devices are automatically unblocked after 1 minute

As a part of this update we removed legacy media_traffic field from connection logs and channel properties.

shal

We extended the device commands queue API with three new optional fields that provide fine-grained control over how queued commands are executed:

priority — defines the execution order of commands in the queue. Commands with higher priority values are picked for execution first, regardless of when they were added. This is useful when you need to ensure critical commands (like engine immobilization) are processed before routine configuration updates.

max_attempts — limits the number of delivery attempts before the command is rejected. An attempt is counted when the device doesn't respond or something goes wrong during delivery. Once the limit is reached, the command moves to commands-result with failed status. Default behavior remains unchanged for commands without this field.

condition — a flespi expression evaluated against current device telemetry before each execution attempt. The command stays in queue until the condition becomes true or the command expires. You can use metadata() to access device metadata and geofences() to check assigned geofences in the condition expression.

YuryAheichyk

Video Streaming: HTTP-FLV support

Added support for HTTP-FLV video streaming from devices. In addition to the existing HLS streaming, devices can now stream video in FLV format, which provides significantly lower latency (1-2 seconds vs 5-10 seconds for HLS) by delivering a continuous video stream directly to the client without segment buffering.

Device log changes: "mediastream from device started" (event_code:308)

The log message reported when a media stream starts has been updated with the following field changes:

mediastream (new) — indicates the stream format: "hls" or "flv"
url (new) — contains the full URL for accessing the stream

Deprecation notice: the "hls" field from "mediastream from device started" (event_code:308) log will be removed on March 26, 2026

YuryAheichyk

request_video command result format change

The request_video device command result format will be updated on April 3, 2026.

Some devices may send multiple media files in response to a single request_video command. To support this, the response field in the command result will change from a JSON object to a JSON array.

Old format (object):

{
  "result": true,
  "response": {
    "url": "https://media.flespi.io/...",
    "uuid": "...",
    "mime": "video/mp4",
    "name": "video.mp4",
    "size": 12345,
    "created": 1731390161,
    "meta": {
      "channel": 1,
      "type": "video",
      "video_codec": "h264"
    }
  }
}

New format (array):

{
  "result": true,
  "response": [
    {
      "url": "https://media.flespi.io/...",
      "uuid": "...",
      "mime": "video/mp4",
      "name": "video.mp4",
      "size": 12345,
      "created": 1731390161,
      "meta": {
        "channel": 1,
        "type": "video",
        "video_codec": "h264"
      }
    }
  ]
}

If your integration relies on the response field of request_video command results, please update your code to handle a JSON array in addition to of a single object.

adsa

New fields for related REST API entities:

channel: streams_count
device: groups_count, streams_count, plugins_count, calcs_count, geofences_count
stream: devices_count, groups_count, geofences_count, channels_count
calc: groups_count, geofences_count, devices_count, assets_count
group: devices_count, calcs_count, plugins_count, streams_count, geofences_count
plugin: devices_count, groups_count, geofences_count
geofence: calcs_count, plugins_count, groups_count, streams_count, devices_count
asset: groups_count, calcs_count
MQTT session: subscriptions_count

YuryAheichyk

Deprecation Notice: Camera-based media commands

Due to very low adoption of camera-based addressing in media commands, we are simplifying the API by removing camera index support.

No changes are needed if you are already using the channel property directly.

The camera property in media commands (request_video, playback_video, start_videostream, stop_videostream, take_photo, request_photo, video_timeline) and the cameras array in device type configuration will be removed on May 5, 2026.

After this date, media commands will only accept the channel property to specify the target camera channel directly. The filter_cameras parameter in video_timeline will also be removed in favor of filter_channels.

What you need to do:

Replace "camera": <index> with "channel": <number> in all media command requests
Replace "filter_cameras": [...] with "filter_channels": [...] in video_timeline requests
Stop relying on configuration.cameras array for camera index resolution

adsa

Upload media files to device via REST API

You can now upload media files (tachograph files, video clips, and images) directly to device media storage via the new POST /gw/devices/{dev-selector}/media API method.

Previously, device media storage could only be populated by physical hardware devices uploading files through supported protocols. Now you can register media files from any external source — your own backend, a third-party system, or even manual uploads — and they will be processed through the same pipeline as device-originated files, including device message registration with media links.

How it works

The method accepts a multipart/form-data request with two parts:

file — the actual media file
data — JSON object specifying the file type and optional metadata

Two file types are supported:

Tachograph files (type: "tacho"):

curl -X POST 'https://flespi.io/gw/devices/123456/media' \
  -H 'Authorization: FlespiToken YOUR_TOKEN' \
  -F 'file=@driver_card.ddd' \
  -F 'data={"type":"tacho","meta":{"created":1775000000,"vin":"WDB1234567890","plate_number":"AB123CD","driver_id":"1200000000110200","driver_first_name":"John","driver_last_name":"Smith","region":"LT"}}'

Video/Image files (type: "video"):

curl -X POST 'https://flespi.io/gw/devices/123456/media' \
  -H 'Authorization: FlespiToken YOUR_TOKEN' \
  -F 'file=@event_clip.mp4' \
  -F 'data={"type":"video","meta":{"channel":1,"created":1775000000}}'

Upon upload, flespi will:

Process the file through the standard media pipeline (including video codec detection, tacho file handling, etc.)
Store the file in device media storage with a unique UUID and public access link
Register a device message at the created timestamp with media=true and corresponding media.tacho / media.video.X / media.image.X parameters

This means all downstream integrations — streams, plugins (including tacho-file-parse), MQTT subscriptions, and webhooks — will process uploaded files exactly as if they came from the device itself.

Extra parameters

You can attach custom data at two levels:

params — extra attributes stored on the media file itself (accessible via GET /gw/devices/{dev-selector}/media)
message_params — extra parameters injected into the generated device message
meta — file-type-specific metadata (timestamps, driver info for tacho, camera channel for video)

Use cases

Tachograph file import: Upload .ddd files obtained from external sources (card readers, third-party download tools, legacy systems) into flespi device media storage. Files will be automatically processed by the tacho-file-parse plugin if assigned, and forwarded to downstream platforms via streams — including Wialon and S3.
Video/photo import: Register externally captured video clips or images against a device timeline, making them accessible through the same Mediabox UI and API as device-originated media.
Data migration: Move historical media files from another platform into flespi while preserving original timestamps and metadata.
Testing and development: Upload sample media files to test your integration pipeline without requiring a physical device connection.

adsa

Deprecation Notice: POST calculate methods replaced by GET

The following REST endpoints now accept GET requests; the existing POST variants remain functional but are marked deprecated and are scheduled for removal on July 1. Each deprecated POST call now returns a warning in the response body: "deprecated: use GET method instead".

If you are unable to migrate by that date, please reach out to our support team — we will handle your case individually.

Old => New endpoints (preferred)

Calculate intervals from messages:

POST /storage/containers/{selector}/calculate => GET /storage/containers/{selector}/messages/calculate
POST /gw/devices/{selector}/calculate => GET /gw/devices/{selector}/messages/calculate
POST /gw/calcs/{selector}/devices/{selector}/calculate => GET /gw/calcs/{selector}/devices/{selector}/intervals/calculate

Calculate intervals from logs — GET /xxx/logs/calculate now available for every endpoint that previously supported only POST, including:
gw/channels, gw/devices, gw/streams, gw/calcs, gw/assets, gw/geofences, gw/groups, gw/plugins, gw/modems, storage/containers, storage/cdns, platform/tokens, platform/customer, platform/subaccounts, platform/webhooks, platform/deleted, platform/realms, platform/grants, platform/limits, platform/identity-providers, /mqtt/logs/calculate, /ai/logs/calculate.

Request format

Calculation parameters are now passed as a required URL-encoded data query variable (same JSON schema as the former POST body):

GET /gw/devices/{selector}/messages/calculate?data=<url-encoded JSON>

Deprecation: 'calculate' submodule in token ACL

Including the legacy calculate submodule in a token's ACL is still accepted for backwards compatibility but now returns the warning: "deprecated submodule 'calculate': use 'messages' submodule instead".

Affected endpoints: POST /platform/tokens, PUT /platform/tokens/{selector} (and their admin counterparts).

Please migrate ACL entries to use the messages submodule:

{
  "uri": "gw/devices",
  "methods": ["GET"],
  "ids": "all",
  "submodules": [
    { "name": "messages", "methods": ["GET"] }
  ]
}