The behavior of REST API methods with max_count parameter specified has been changed for channels logs, devices logs and streams logs. Check information in the corresponding storage system changelog.
[Changelog] flespi telematics hub
6 days later
Some of our users had difficulties filling out the headers field for the HTTP stream. The inconvenience of the interface is caused by the scheme used for headers field: {"header-name": "header-value", ...}.
We decided to change the scheme to an array, in the form: [{"name": "header-name", "value": "header-value"}, ...]
This solution will allow you to add heades in the usual way.
Existing streams remain in their original form until november 4. After they will be automatically converted to a new format. Support for the old scheme in the REST API will continue until november 18.
2 months later
shal We decided to remove nis protocol from the streams at the moment, but upon request may re-enable it later.
And we implemented maxoptra streaming protocol for integration telematics data from flespi hub directly into Maxoptra Distribution Route Planning.
We enabled JSON objects(and arrays) in device telemetry fields and enlarged allowed textual value size for the telemetry from 1KB to 4KB.
- Edited
Method /platform/subaccounts/all/logs was added. Using it you can get your subaccount's logs in a single REST call. The most convinient way is to fill filter parameter to select what kind of logs do you need.
Use this request to fetch all deleted devices from all subaccounts:
https://flespi.io/platform/subaccounts/all/logs?data={"filter":"event_code=3,origin_type=11"}
8 days later
- Edited
Devices and calculators received new property for controlling maximum storage threshold they can use.
This parameter is a convenient way for controlling your flespi storage size. Now instead of guessing how much storage you will use in devices in a day/month/year you may just specify automatic messages rotation size and flespi will control it for you. Whenever any newly added message will overflow specified size older messages will be automatically discarded.
Same applies to analytics and intervals size used by assigned devices.
Read https://flespi.com/kb/how-to-manage-device-storage for more information about messages rotation.
2 months later
For streams to Azure IoT we have added special parameter replace_dots which is off by default. Once enabled in stream configuration all messages received by stream on Azure side will contain replaced dots to underscores in parameter names, e.g. "position.latitude" to "position_latitude" and so on. This is to enable special rules engine on Azure side which is impossible to use when original flespi parameter naming scheme is used (with dots).
8 days later
- Edited
For security issues we decided to remove ident parameter from device telemetry. This way device telemetry can be securely exposed to external users via REST and MQTT. Together with recently installed changes to flespi ACL tokens it even possible to expose just the device telemetry excluding device settings or its configuration.
The update which removes ident parameter from device telemetry will be installed tomorrow in the morning.
- Edited
We have implemented special plugins framework that extends functionality of flespi telematics hub for special cases.
The very first case we have implemented is the possibility to forward telematics data from devices into Bulgarian tool roads system, effective from March 1st 2020 via tollbg.eu service. In order to use it you need to:
- register at tollbg.eu service, receive authentication credentials that you will use for stream (if asked during registration for stream status webhook you may use this url: https://flespi.io/gw/hooks/toll_health);
- register there plate number of vehicles you want to stream;
- create flespi stream with type=tollbg:
- activate tollbg plugin for the flespi device and fill per each device two required fields - pan number and license plate number, like on screenshot below:
- subscribe stream to devices with activated tollbg plugin;
As now we have this special framework that allows us to define custom fields and plugins for various types of flespi entities we plan to add more and more plugins in the future - connect to various toll roads services, government regulations system for specific countries and create connectors to various aggregators and hubs that our users can use upon their desires. Please contact us in flespi chat if you have requirements for some specific projects.
2 months later
The channel has a static IP address, but a static address is vulnerable to a DDoS attack.
The goal is to minimize the impact of a theoretical DDoS attack on an gateway IP.
Thus, we took the very first step to replace the static IP address of the channel with a personal DNS record.
The panel now displays the channel URI as a DNS record.
We recommend that you use a DNS record for all future connected devices and, if possible, reconfigure existing ones.
As a part of our anti-DDoS preventive measures we are softly switching from IP-based channel specification to DNS-based. Each channel is assigned its unique DNS record in form {channel-id}.flespi.gw. Currently it is resolved as a CNAME type record to gw.flespi.io for EU region and ru-gw.flespi.io for RU region which by itself are A-type records to the underlying IP address which was recently a part of channel’s URI.
It means that except the visualization part currently there are no actual changes occurred in the endpoint where to connect your telematics devices. However we strongly recommend you to update the server address of your devices from IP-based format to the new DNS format as proposed by the channel uri property.
In case of any kind of DDoS attack we will immediately manipulate with these DNS records to reroute devices to different multiple IP addresses and save and secure the traffic from your devices. If you use the DNS address of your channel you will be safe. If you use an old fashioned IP address - the traffic from your devices may be blocked for some period of time.
Moreover later we will introduce more IP addresses for communication with devices and even may install and rotate channel listeners in different datacenters to improve reliability and performance. Please use the DNS name of your channel everywhere and together with flespi prepare for the future.
For all new channels created from this point of time, with ID higher then 18000 for RU region and 22000 for EU region we expect that the devices connect to DNS name and we may further change IP address it points to without additional notice. Please be aware.
18 days later
We have added an "IP whitelist" optional property to the all channels configuration, where the channel is dealing with incoming connections (most of the protocols at this time).
Now you may set a comma-separated list of IP addresses (or a wildcard-masks like 192.168..) to allow incoming connections only from such IP addresses.
20 days later
One of flespi access methods - pull based access to channel messages via REST API will update range values of some input parameters from 32-bit unsigned integer to 64-bit unsigned integer.
Methods and parameters affected:
- GET /gw/channels/{1-ch-selector}/messages for curr_key and next_key parameters
- DELETE /gw/channels/{1-ch-selector}/messages for delete_key parameter
In most processing systems these methods will continue to operate as is, cause in Javascript, Python and most of other languages there is no specific datatype for number limitation up to 64-bit.
This message for you is just a notice to check your code and prepare for the upcoming update from flespi side.
6 days later
6 days later
- Edited
We released the second version of the plugin system to extend device functionality. All plugins for the initial release (the first version of plugins system) were converted into this new one and messages flow should be unaffected.
From that moment we will add features to it on a constant basis. Plugins system is still considered experimental at the moment and thus we may introduce changes to its API without prior notice.
In short, plugins allow you to define extra fields to messages published to devices. You define the schema of each plugin and its fields (name, parameter alias, actions with fields - store in the database, publish to MQTT, publish to device telemetry, etc) and after that, you may add devices to the plugin by filling their fields.
Plugins can be used just to store and reference any extra information about the device and use it with REST API selectors. E.g. to extend each device with special customer number, plate number, or even to add a phone number or SIM ICCID.
Some plugins, which are part of a complex pipeline process, like tollbg are available as a template making it simple to create and use them in one click.
REST API is available here. You may read about associated plugins GUI changes here.
We plan later to publish a few articles in our blog covering the most popular use cases for the plugins.
We also plan later introduce plugins to other types of flespi entities, e.g. channels.
Be aware that the number of plugins you may create is limited by your flespi plan. Free flespi users can create just one plugin. And Commercial flespi users have two plugins included in the base package and each extra plugin will cost $20.
12 days later
We implemented special REST API method to move device between various flespi accounts: PUT /gw/devices/{devices-selector}/cid
This is quite a complex method and may be used by our commercial users that can organize their flespi account into subaccounts hierarchy on a per-project basis and to distribute devices between subaccounts persisting their settings, storage, calculation and streaming configurations.
We do not plan to add button to call this method from GUI at the moment - it will remain available only via REST API.
2 months later
- Edited
Please take a look at flespi database changelog message as it may affect the operation of the flespi telematics hub for you. We ensure our users to test their integrations and keep an eye on it during the transition period.
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.
