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

shal

shal We have migrated all our storage systems from seconds to microseconds granularity according to initially defined schedule.

We advice all our users using REST API to fetch devices messages to check for correctness of to field in their REST API queries. For example your message is the following:

{
"timestamp": 1490347944.893743,
"din": 5,
"param1": 1,
...
},

Legacy implementation of GET /gw/devices/XXX/messages for the query:

{
"from": 1490347940,
"to": 1490347944,
}

will correctly return this message, as the storage granularity was one second.
New (current) implementation will not return this message, because it's timestamp (1490347944.893743) is larger then right selection border (1490347944).
To avoid any discrepancy please either request 1490347944.999999 as right border (in from parameter) or just select up to next second: 1490347945 and filter out unsuitable values from result.

kial

shal We've added a new public post-processing protocol parameters-filter that can be used to remove any unneeded parameters (except system ones) from the messages of any channel. For example, it can be used to reduce messages storage amount or reduce traffic when receiving a lot of messages through MQTT or a stream.

Another example to remove position information (latitude and longitude) from all messages:

screenshot

adsa

Added functions related to the channel:

You can now change the protocol when updating an existing channel.
Moving a channel between subaccounts. This action is not integrated into the panel, but the action is available through the PUT gw/channels/{selector}/cid method.

adsa

adsa The fix was released today.

adsa

This week we released a rather interesting platform update related to device plugins. The plugin can insert its own fields into the registered device message. But the limitation was in the parameter name, which was fixed to plugin.{plugin-alias}.{field-alias}.

We have completely revised this concept and decided not to restrict our users to this naming scheme. We have made the plugin alias optional. Such plugins store their fields as they are, without a prefix.

The main advantage of this function is to replace any parameter value from the original message with your predefined or calculated using an expression.

This concept no longer requires a plugin alias. It will be removed in a week. All plugins with non-empty alias and assigned devices will be patched. This will not change the logic of existing plugins.

shal

We just installed a massive update to the telematics hub for plugins.

Among all other new features, it is now possible to code any processing of device message using our PVM language, instructions on its usage will be published later, now you may just ask our team for assistance to code something.

Also now it is possible to specify in plugin list of parameters for removal and also specify timezone for using date/time functions in all expressions/validators. For example, you may activate the removal of coordinates on non-business days to conform to GDPR private driving.

This is just an intermediate step on the expansion of plugins functionality. A lot of things are still in our TODO list to make them more usable and simpler and we will implement these things one by one. But this step opens a huge list of possibilities to perform over device message whatever you may want - any arbitrary logic and manipulations over fields. And everything can be done by the user with no requirement for the flespi team to perform any development. We are just developing the technology and supporting it which is an extremely scalable approach.

Remember plugins REST API is still in an experimental mode and we may change it quite quickly so it is better to inform us if you are using something there.

shal

In order to eliminate inappropriate resources usage we introduced shorter timeout for unidentified TCP connections - just 30 seconds. Once device is authenticated, TCP connection timeout is enlarged to standard 10 minutes.

adsa

Today we are going to install an update that affects how plugins work. The plugin features that were added earlier (PVM code, erase fields) made it clear to us that adding new functionality to the plugin itself is difficult.
It is much more convenient if the plugin will have basic functionality (priority, validation) and a selectable plugin type. We have identified four main types:
item-fields - add static fields to the designated item, some of the fields can be stored as message parameters
msg-expression - add new message parameters as a result of evaluating expressions
msg-erase - remove the listed parameters from the message
msg-pvm-code - execute PVM code to process the message

We also implemented four additional types that will be available a little later:
google-reverse-geocoding - Resolve the position address using Google reverse geocoding and add it to the message
nominatim-reverse-geocoding - Resolve the position address using Nominatim reverse geocoding (OSM) and add it to the message. Public or private servers supported.
wialon-reverse-geocoding - Resolve position address using reverse geocoding Gurtam Wialon and add it to the message
wialon-lbs-geocoding - Resolve position coordinates using LBS Wialon geocoding and add it to the message

For the transition period, the plugin REST API will be compatible with both plugin modes. The transition period is up to one month, after which we will convert the existing plugins to the new structure.

adsa

adsa
We remind you that deprecated plugins will be automatically converted to the standard format after 10 days.
It is not possible to automatically convert a plugin with multiple options enabled. Expressions can no longer be combined with static fields. The enabled options affect the plugin's result type in the following order: msg-pvm-code, item-fields, msg-expressions, msg-erase

We recommend manually splitting a deprecated plugin with few options into several standard plugins.

shal

We introduced a limit of maximum 20 commands that can be queued for each device at the same time (per device). Pending device settings (setting value read or update) are not affected by this limit.

adsa

The telemetry field is now available to query the device via the REST API. You can now select devices based on their telemetry, for example:
GET gw/devices/telemetry.speed>0

Telemetry is also available as a device field:
GET gw/devices/all?fields=id,telemetry

shal

We changed a bit the MQTT retain message timestamp value for telemetry parameters.

Previously all telemetry parameters were registered with timestamp sent by the device. But sometimes devices send some invalid timestamps in the far future or in the past which makes it difficult to debug such cases as you do not have any telemetry available (we store it for 1 year only starting from the timestamp value).

Now flespi-specific message parameters like device.id, server.timestamp, channel.id, peer, etc will be stored in the MQTT retain messages under current time timestamp (equals to server.timestamp value from the message being registered). It means that these telemetry parameters will always contain actual and latest values.

We do not expect any side effect in this update for our users.

adsa

We are going to synchronize the naming scheme of streaming protocols. Some streaming protocols have underscores in their names, but corresponding channel protocols have hyphens. Thus, all underscores in the protocol name will be replaced with hyphens.
This change will affect the method: GET gw/stream-protocols/name=xxx.

According to our logs, there were no such requests for the last 60 days.
Full list of affected protocols:
aws_iot => aws-iot
azure_iot => azure-iot
etoll_pl => etoll-pl
flespi_gateway => flespi-gateway
google_iot => google-iot
key_telematics => key-telematics
wialon_flespi_gateway => wialon-flespi-gateway
wialon_retranslator => wialon-retranslator

This change will take place on July 19th.

adsa

New methods were added:
PATCH gw/devices/{devices-selector}
PATCH gw/plugins/{plugins-selector}
PATCH gw/plugins/{plugins-selector}/devices/{devices-selector}

These methods will merge fields if they are of type JSON object and overwrite others.
It is convenient to use these methods instead of PUT to update only certain keys from the configuration.

shal

Channel commands REST API is marked as deprecated from now and we will completely discontinue the support of commands on the channel level on December 1, 2022.

Channels will be available only for incoming data flow. For any bidirectional communication with device you are welcome to use devices commands.

Please read full information about upcoming changes and migration instructions here: https://flespi.com/blog/channel-commands-discontinued

adsa

shal
We discovered that we left the method by mistake during this update. The method is GET gw/channel-protocols/{selector}/commands/{selector}. We will mark it as deprecated and give it one month to transition to the GET gw/channel-protocols/{selector}/device-types/{selector}?fields=commands method.

adsa

Added device_id, ident fields to GET gw/devices/{devices-selector}/commands-result method output. The origin_id field will be deprecated on October 7th. The changes are aimed at simplifying the transition from channel commands to device commands.

shal

HTTP response header x-flespi-apicalls that became useless a year ago is now marked as deprecated and will not present in flespi.io's HTTP and MQTT API responses anymore.

shal

We enhanced flespi functionality with device groups feature. Currently it is only available in REST API, but in October we will add groups to the flespi.io GUI.

Streams, calculators and plugins can now link to a device group instead of a separate device and once you add device to the group it will be automatically linked to all them. Same with ACL - if token provides access to device group, it will automatically provide access to all devices in this group.

Groups are mostly designed to simplify operations on large volumes of devices and automate various assignments.

shal

In order to more effectively mitigate DDoS attacks now and in the future we are changing the default gateway IP for all connections originating from flespi network.

If you configured the firewall in your infrastructure to accept traffic from our platform (connections from streams, plugins, proxy and various API or MQTT based channels), please update your configuration as soon as possible:

Old IP: 193.193.165.35 [is active gateway now]
New IP: 185.213.2.10 [will be active gateway soon]

The change will come into effect on Monday, 17 October 2022 or earlier in case we will experience DDoS attack.

This week we are also changing IP addresses for REST(flespi.io) and MQTT(mqtt.flespi.io) services, but this is based on DNS records and the change will go smoothly.

And finally we will setup new range of IP addresses for channels, although current addresses 193.193.165.X will be retained and fully operative as an entry point for existing channels. If your devices are using channel URI with domain name you are totally safe for any change. For those who hard configured in devices IP 193.193.165.X you may be sure we will continue to serve it now and in the future although its routing and DDoS protection level may differ.

shal

shal Our primary IP address for channels from now is 185.213.2.30.

IP address 193.193.165.37 is still operational and will continue to operate in the future, however all our uptime tests that we constantly run from multiple locations will not count downtime if this address is not available due to any reason.

Nevertheless we still keep an eye on it inside internal monitoring system and will immediate react in case of any troubles with it but this won't be automatically announced in the NOC comparing with default channel IP addresses 185.213.2.30.

How this may affect you:

If you are using IP address in devices configuration you are free to use any of these: 193.193.165.37 or 185.213.2.30 but I suggest to configure newly provisioned devices to new IP address.
If you are using channel DNS record in devices configuration (e.g. xxxxx.flespi.gw) than your devices will automatically use new IP address. But in case you whitelisted 193.193.165.37 somewhere in the operator network you have to whitelist also new IP address. If this can not be done quickly please contact us in HelpBox in order to temporary fix DNS records of your specific channels to old IP address.

shal

We applied announced change of default flespi IP for outbound connections from 193.193.165.35 to 185.213.2.10. We recommend all our users who use streams, plugins and special channel protocols (usually OEMs related) to check the status of their systems.