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

kial

We've added the last_active field to the devices in the REST and MQTT. This field contains a timestamp where the platform received the last data piece from device over TCP/UDP/etc.
This field can be used to determine "alive" devices working over UDP or other connectionless transports.

kial

Dear flespi users!

We're announcing an upcoming change in the output of the REST API method GET /gw/devices/<selector>?fields=settings

For now, the output of this request contains an array with device settings as a JSON object, and every object contains such fields:

address
current
mode
pending
schema
tab
tags
updated

Next week, on August 28 the following fields will be removed from this list:

address
mode
schema
tab
tags

All these fields can be obtained using another REST API request: GET /gw/protocols/all/device-types/<device-type-id-from-device>?fields=settings

kial

Dear flespi users!

We've installed the update mentioned above: kial

adsa

We are going to rename "gw/protocols" to "gw/channel-protocols". This will allow us to implement other protocol entities such as "gw/stream-protocols" etc. REST API methods based on "gw/protocols" are deprecated and will be removed on November 23rd.

List of affected methods:

Get protocols matching filtering parameters. Deprecated method:
GET /gw/protocols/{protocol-selector}
New method:
GET /gw/channel-protocols/{protocol-selector}

Get commands supported by protocol. Deprecated method:
GET /gw/protocols/{protocol-selector}/commands/{protocol-cmds-selector}
New method:
GET /gw/channel-protocols/{protocol-selector}/commands/{protocol-cmds-selector}

Get device types supported by protocol. Deprecated method:
GET /gw/protocols/{protocol-selector}/device-types/{devtypes-selector}
New method:
GET /gw/channel-protocols/{protocol-selector}/device-types/{devtypes-selector}

adsa

adsa Deprecated REST API methods have been removed.

adsa

We are introducing a new REST entity called stream-protocols. The purpose and use of this entity is exactly the same as the previously mentioned channel-protocols:
curl -X GET --header 'Authorization: FlespiToken XXXX' https://flespi.io/gw/stream-protocols/all

To create a new stream, you must get the available protocols, and then pass the identifier of the desired one to the stream configuration:
curl -X POST --header 'Authorization: FlespiToken XXXX' -d '[{"configuration":{},"protocol_id":1}]' 'https://flespi.io/gw/streams'

By the way, the legacy format is still available until December 16:
curl -X POST --header 'Authorization: FlespiToken XXXX' -d '[{"configuration":{"protocol" : "http"}}]' 'https://flespi.io/gw/streams'

adsa

The new REST API for streams was announced a few months ago, and the new and old format were available until mid-December.
The obsolete format has now been removed and is no longer supported.

Please let us know if you have any problems with streaming.

namo

This is to announce an important update of azure_iot stream implementation.
Update is planned for Monday, 30-Nov-2020 12:00 UTC

property_bag with Content -Type=application/json and Content-Encoding=utf-8 will be added to IoT Hub MQTT topic name. This will prevent base64 encoding of message body at Azure side.

Example of Azure event message before and after the update illustrates the upcoming change:

before:
{ "EnqueuedTimeUtc": "2020-11-25T12:24:40.7280000Z", "Properties": {}, "SystemProperties": { "connectionDeviceId": "namo-device1", "connectionAuthMethod": "{\"scope\":\"hub\",\"type\":\"sas\",\"issuer\":\"iothub\",\"acceptingIpFilterRule\":null}", "connectionDeviceGenerationId": "637418276273362219", "enqueuedTime": "2020-11-25T12:24:40.7280000Z" }, "Body": "eyJiYXR0ZXJ5LmxldmVsIjo5OSwiY2hhbm5lbC5pZCI6MTE3ODEsImRldmljZS5pZCI6MTMwNzI0MSwiZGV2aWNlLm5hbWUiOiJuYW1vIHdpYXRhZyIsImRldmljZS50eXBlLmlkIjoxOCwiZ3NtLmNlbGxpZC4xIjoxMzk1MywiZ3NtLmxhYy4xIjoxMDQwMSwiZ3NtLm1jYy4xIjoiMjQ2IiwiZ3NtLm1uYy4xIjoiMiIsImdzbS5uZXR3b3JrLm5hbWUiOiJmdXNlZCIsImlkZW50IjoibmFtbyIsInBlZXIiOiI3OC41OS4xMjQuMjA0OjE0MzAiLCJwb3NpdGlvbi5hbHRpdHVkZSI6MTkyLjIwMDAxMiwicG9zaXRpb24uZGlyZWN0aW9uIjo1NCwicG9zaXRpb24uaGRvcCI6MjQuMjYxOTk5LCJwb3NpdGlvbi5sYXRpdHVkZSI6NTQuNzAyMDIxLCJwb3NpdGlvbi5sb25naXR1ZGUiOjI1LjIzMTUzNywicG9zaXRpb24uc2F0ZWxsaXRlcyI6OSwicG9zaXRpb24uc3BlZWQiOjAsInByb3RvY29sLmlkIjoxMSwic2VydmVyLnRpbWVzdGFtcCI6MTYwNjMwNzA3OS4xNTgxNCwidGltZXN0YW1wIjoxNjA2MzEwNjQyfQ==" }
after:
{ "EnqueuedTimeUtc": "2020-11-25T12:43:25.3050000Z", "Properties": {}, "SystemProperties": { "connectionDeviceId": "namo-device1", "connectionAuthMethod": "{\"scope\":\"hub\",\"type\":\"sas\",\"issuer\":\"iothub\",\"acceptingIpFilterRule\":null}", "connectionDeviceGenerationId": "637418276273362219", "contentType": "application/json", "contentEncoding": "utf-8", "enqueuedTime": "2020-11-25T12:43:25.3050000Z" }, "Body": { "channel.id": 103, "custom.s_on": 0, "device.id": 171, "device.name": "namo wiatag", "device.type.id": 1, "ident": "namo", "peer": "127.0.0.1:33016", "protocol.id": 1, "server.timestamp": 1606307390.550142, "timestamp": 1606310980 } }

adsa

Plugins have become more useful with the latest platform update. Along with static fields that extend device messages, you can now extend a message with dynamically calculated fields.

Find out more in the updated post:
https://flespi.com/blog/plugins-endless-possibilities-to-customize-message-content

adsa

The following platforms were integrated as dedicated stream protocols and no longer needed to be configured as HTTP stream:

omol

Support of self-signed certificates for third-party servers will be discontinued in 1 week (on February 17). MQTT channels and streams now support custom root certificates (ca field in configuration object) so you can use this option for proper and fully secure TLS/SSL usage.

omol

omol
We have disabled support of self-signed certificates. Please use custom root certificates feature from now.

omol

omol
Custom root certificates support (ca field) has been added to HTTP streams as well.

adsa

Over the past few weeks, we have moved the device REST API methods to a new engine. The methods and their result remain unchanged.
Today we plan to smoothly upgrade our services. But if you notice any incorrect behavior, please contact us.

Thank you for being with us.

adsa

Introducing the new Flespi Gateway streaming protocol and its counterpart, the Flespi Gateway channel, which allows telematic messages to be sent between different user accounts or even flespi clouds.

Learn more in the knowledge base article:
https://flespi.com/kb/flespi-to-flespi

adsa

The new ruhavik streaming protocol provides an easy way to share telemetry from your flespi devices with the ruhavik app.
Ruhavik is a free modern app for evaluating, analyzing and monitoring your trips. The corresponding type of tracking device for Ruhavik is the Flespi Gateway.
https://gurtam.space/ruhavik

Learn more in the knowledge base article:
https://flespi.com/kb/flespi-to-ruhavik

shal

Device plugins, when fields are used with expressions now received newer implementation of the expressions processing engine. In this new engine, strict type of each parameter is checked and it is not possible to add boolean to number or string.

You can use isnumber(xxx), isboolean(xxx) test functions as well as tonumber(xxx), tostring(xxx), toboolean(xxx) functions for converting type of argument.

New reserved words now also available to use: null, true and false.

We will safely upgrade existing plugin expressions with the intended result type soon. For example if you have field with expression: "din & 0x8" and result type boolean, it will be converted to "toboolean(din & 0x8)". At the same time, we will remove result_type specifier. This will give you the possibility to specify not only booleans and numbers as a result of expression but also nulls and strings.

We have checked and tested all expressions in all fields of all existing plugins so the update should be safe for all our users.

shal

shal We installed update to field plugins and removed result_type property from the field. Now you may type of output with builtin functions described above. All expressions for all plugins were converted as well.

kial

Dear flespi users!

The next Friday, March 26 we'll rename the channel protocol with id=241 from the current name "trakm8" to the new name "trakm8-gateway".

kial

We've renamed the protocol with id=241 from the old name "trakm8" to the new name "trakm8-gateway".

adsa

We recently allowed null values to be stored and used in expressions. This was not the case for device telemetry, where null values were used to clear the existing value. We are correcting the inconsistency between device telemetry and device messages by allowing the device to store 'null' values as telemetry.

To get rid of irrelevant or incorrect device telemetry fields, a new REST API method has been added:
DELETE gw/devices/{device-selector}/telemetry/{telemetry-selector}

This functionality is already built into the panel:

In addition to the REST API method for getting telemetry of the whole device, a new REST API method has been added to get some telemetry fields:
GET gw/devices/{device-selector}/telemetry/{telemetry-selector}