Today we'll install an update for the commands and setting engine, to provide new features:

• device-level commands: now you can send a command to the device without direct access to the channel where the device is connected. Added a new REST API interface for the device-level commands queue management, similar to the channel-level commands: you can POST command into the queue, examine queue content and check command execution results. The set of the available commands is the same as for the channel.

• instant device-level commands sending: if your device is connected right now, you can send device-level command by HTTP REST request, which will return its response only when the command was executed on the device. To do this you can specify the optional "timeout" parameter and your request will be suspended until command completion.

Please be noted that during the update installation process you may face an insignificant delay in commands execution.

In addition to kial and shal updates, we've added a command field to the GET
/gw/channel-protocols/{protocol-selector}/device-types/{devtypes-selector} request.
That field contains an array of all commands available to execute directly through the device (real-time, sms commands, and device-level commands queue).
The array of available commands are combined from the channel-level commands and get- and/or set-command per each setting defined for the device.
Now it's possible to execute one device setting several times with different parameters using the device commands queue, and all of the PUT requests will be delivered to the connected tracker.

We enhanced channels with the possibility to post-process the message. The list of post-processing channels that are operating on special protocol type is available in the channel configuration:

It works such a way that message from normal device first being parsed by the original protocol which output standard message (JSON) for the channel. After that message is used as a source for input for any post-processing channel that may add or remove any field there or perform some special parsing for fields.

This feature open for us a whole world of new possibilities:

• add or remove any parameters from the message
• perform special parsing of 3rd party devices attached to serial port or CAN bus including SigFox and LoRaWAN protocols
• attach geocoded position, from Google Maps for example
• attach position detected via LBS service
• perform any other logic we may need

Right now we are developing few protocols to parse data from peripheral devices attached to the serial port of standard GPS device. These devices are using standard GPS device just as a transport layer to deliver its data.

As usual we are open for our users to request to implement such protocols by our team. These protocols with custom logic can be installed in private mode, available only for particular flespi user.

We are reporting minor changes to the Azure IOT stream configuration.
The previously introduced parameter convert_message has its own rules for working with periods in the names of message parameters. Therefore the special parameter replace_dots is deprecated and should be replaced with the convert_message parameter. Please uncheck replace_dots option, enable convert_message option and select snake_case for replace_dots option.

On September 16, the deprecated stream configuration will be fixed automatically.

If you change a non-existent device setting, you will not receive any errors. This is a bug, not a feature. We're going to change this behavior. Thus, any PUT/DELETE request to gw/devices/{devices-selector}/settings/{setting-name} to change a non-existent device setting will return 400 Bad Request.

The update will be installed on October 8th.

We've installed an update extending digital inputs and outputs (din and dout) parameters handling for the protocols, which sends them as a separated bits, not as a combined bitmask.
In that protocols in addition to parameters din and dout you will get the parameters din.N/dout.N where N is a 1-based bit index, and the parameter value will be true/false according to that bit state.

SMS gateway updated: + symbol excluded from destination phone number of SMPP client when sending a message

shal We completed 1st and 2nd steps described above and now for all 40 data clusters(shares) there are two mirrors providing messages with microseconds granularity.

If everything will be OK next week we will replace last 3rd mirror and finish transitioning to microseconds data format, but already starting you can enjoy this feature in flespi database as read operations are automatically routed only to new mirrors.

We have created a new streaming protocol to integrate flespi with the Polish E-Toll system https://etoll.gov.pl/.
Stream requirements:

1. You must be registered as a ZSL provider at https://test.puesc.gov.pl/en/web/puesc/zsl-105.
2. You must have a valid certificate, private_key and access point URI.
3. Due to the need for E-Toll, you must provide your own original IP address. So your stream URI should point to the TCP proxy running on your server.
4. Before you can access the production environment, you must pass the E-Toll certification.

If you have any questions, please write to us in the Helpbox.

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.

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:

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 The fix was released today.