1 September, 2017

August 2017 change log

Major flespi improvements in August 2017
Disclaimer: flespi registry module merged with the gateway module to form the telematics hub between devices and platforms.

In August flespi platform had a few major achievements one of which is that we finally removed “subject to change” disclaimer from gateway and platform API, basically marking these APIs as “released” and ready to use by developers in own products.

  • Total platform downtime in August amounted to 240 seconds; it occurred once on August 30 due to human error during updates installation process. We have already eliminated this human factor to prevent similar problems in the future. Anyway, we still operated with 99.991% monthly uptime staying on the high level of four nines.
  • On our flespi.com resource got a special Docs page where we accumulated all important technical documents about the platform, its features, and architecture description. The page also features a nice FAQ section answering many basic questions concisely and clearly.
  • We consider security one of the most valuable components in any type of library or platform, that’s why we created a special ACL extension for tokens in platform API so that it is possible to generate and send tokens that can only be used by 3rd party developers in view mode or with certain limitations. We will cover this special topic later in a separate post when flespi.io panel provides the corresponding GUI.
  • We added an optional name attribute to devices, streams, containers, and abques. This field can be used by developers as a custom ID or tag which is easy to specify in an associated URI of REST method, for example, GET /registry/devices/name=”my-custom-id”.
  • As we switched focus from gateway API and concentrated our forces and knowledge on the high-level registry API, it is now possible to specify zero value in a messages_ttl parameter for channel to prevent storage of any data in the channel buffer. This does not affect devices that operate through this channel.
  • We removed system attributes channel_id and source from messages received via channel buffer. We also removed ident and device_id attributes from messages stored in device history. Both removals should not have any impact on your current developments.
  • We implemented the possibility to POST JSON messages directly into devices via registry REST API.
  • We implemented 3 new stream types, i.e. options on how to connect regular telematics devices supported by flespi into 3rd party platforms:
    • abque — to forward messages from multiple devices into a common buffer. This type of stream is useful for software developers who want to combine all new messages from multiple devices in one queue and read them from this single queue — this allows implementation of new messages processing, online tracking for user sessions, etc.
    • aws_iot — a special type of stream that is used to deliver device messages into AWS IoT system via MQTT connection. This is an in-house high-level replacement for open source python channel forwarder. With this stream, it is possible to both deliver MQTT messages with full JSON payload according to protocol specification that can be processed by AWS rules engine, and report changes to AWS IoT device shadow.
    • thingsboard — used to stream device messages into Thingsboard.io open-source IoT platform. With this platform, it is easy to create functional and good-looking dashboards. We will post a detailed overview of this nice platform in a little while.
  • As for devices and protocols integrations:
    • we split queclink-1 protocol into two separate protocols: queclink-gv500 and queclink-gv300 due to incompatible differences in protocol specifications.
    • ident message attribute in channel messages can optionally contain password received from the device, separated by a semicolon: “imei:password”. The same format of the ident naming scheme is used for devices.

Our plans for September include hard work on Registry to implement the basis for a generic online devices configurator and cover most of our latest developments with dedicated posts. We will also dig deep into 3rd party IoT platforms and will keep searching for a nice and easy-to-use visualization tool.

Thank for staying with us and have a productive start of autumn!