[Changelog] flespi telematics hub
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
- Edited
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
- Edited
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.
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".
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}
We've added validation for the messages containing coordinates.
- If the message has a parameter named "position.latitude" or "position.longitude", their type should be a JSON number.
- Next, we'll check that "position.latitude" value is non-zero and inside the (-90, 90) range.
- Then we'll check that "position.longitude" value is non-zero and inside the (-180, 180) range.
If any of these checks fail, we add a "position.valid": false parameter to the message and discard the following parameters:
- "position.latitude"
- "position.longitude"
- "position.altitude"
- "position.speed"
We added optional validate_message field to device plugins. It allows to specify boolean expression that may filter plugin application to the message if validation expression is failed to execute or contain false result.
It can be used for example to store in telemetry or device messages only valid latest data from OBD CAN bus in case device is sending zeroed reading if vehicle ignition is off. Or to discard some reading when some sensors are not connected.
- Edited
We recently added a new method to get device telemetry:
GET gw/devices/{device-selector}/telemetry/{telemetry-selector}
This method has expanded the capabilities of telemetry data collection and will subsequently replace the original method:
GET gw/devices/{device-selector}/telemetry
We're going to completely replace the old method with a new one in about a month.
After two weeks, the old method will start issuing a warning in response. The method will be removed on May 26th.
To switch to the new method seamlessly, just add the all selector:
GET gw/devices/{device-selector}/telemetry/all
Please note that MQTT topics will not be changed
- Edited
We are announcing the future upgrade for filter expression format in various REST API calls. The most important are the GET /devices/XXX/messages and GET /calcs/XXX/devices/YYY/intervals API calls. So all REST API calls where you can specify filter expression will be affected.
Once the whole upgrade is finished it will be possible to use extended expressions in requests with math functions, arithmetic operations, brackets for operations priority and so on. But so far we made simple compatibility mode that you need to adjust your requests to.
List of changes to the filters format
- textual fields will require quotes. For example filter="email=123@gmail.com" should be upgraded to filter="email='123@gmail.com'".
- instead of | or & separators please use || or &&. For example filter="field1=1|field1=100" should be upgraded to filter="field1=1||field1=100".
- parameter existence check in form filter="param1" or filter="param1!=" will stop operating. Please use filter="param1!=''" instead (except the case when param1 may have empty string value).
If some parameter does not exists in the message the whole expression will be marked as invalid and thus message will be skipped. In that case you may already precede parameter name with dollar sign: filter="$param=1 || $param2 = 2"
There will be few stages for this update.
Stage 1: effective from April 26th
We will add warnings response to REST API requests that are still using old scheme. So the ordinary response from request will be:
{"result": [...], "warnings":[{"reason":"You are using REST API call format that will soon be deprecated"}]}
In most of the systems this will not change any kind of processing, because the whole result located under "result" nested object is unaffected.
Stage 2: effective from May 17th
We will switch filters processing in API calls to a new expressions implementation. In case you will be still using older format your requests will return error with corresponding information or even do not operate as expected in some cases. From that moment you will have the ability to use all the power of new expressions engine.
In between stages we are actively monitoring API usage and will personally inform users that will be affected by this change, especially if we already have a non-empty communication chat between flespi support and this user. But nevertheless please do the upgrade of your code on your own as soon as possible and be prepared for the possible changes in requests processing on May 17th.
According to our release schedule today we marked method GET gw/devices/{device-selector}/telemetry as deprecated and now warnings are generated for those who are using it.
Also those who are using old scheme in filters (GET /gw/devices/xxx/messages, GET /gw/calcs/xxx/devices/xxx/intervals methods and so on) are also receive warning attached to the actual response of REST API call. Please see post above fore more details.
We are gathering statistics and will send personal notification to those users who are still using deprecated methods or format and will be affected by ongoing changed.
- Edited
Along with the plugin filter, we added the same filter to the stream configuration. If a filter ("validate_message" field) is set, the stream will check any message before sending. If the message does not match the expression, it will be skipped.
Separate plugin field modes "publish", "telemetry" and "store" confused users and introduced inconsistencies between live messages and historical messages. Today we have combined these modes into a single "store" option. This option is enabled by default and adds a field to the message and telemetry.
The following fields will be added to the device telemetry:
- ident
- device.id
- device.name
- device.type.id
- protocol.id
The update will take place on May 31.
