Disclaimer: flespi registry streams API has changed, so everything talking about streams in this article is outdated. This article applies an “each device has its own streams” model, i.e., streaming messages from several devices to one endpoint requires creating the same stream for each device.
We’ve got numerous requests to implement streams for channels and also to enable sending HTTP-requests with messages to the third-party platform instead of sending messages as a response to HTTP calls via our REST API. The solution was to redesign our streaming architecture. Which we did. Please meet and learn more about the brand new streams here.
Disclaimer 2: flespi registry module merged with the gateway module to form the telematics hub between devices and platforms.
This March we first presented flespi platform on the CeBIT exhibition. We positioned flespi as a middleware between telematics devices and software applications. Its key competence is to make the life of software developers easier providing them with a nice and easy-to-use API capable of using unique device features to the maximum.
We started with the Gateway module by providing API for interaction with devices via channels. Channel is a connection point for devices operating via a specified protocol. Each user can create as many channels as needed. Using this API we deal with channels as a single entity — by managing connections to it, scheduling commands, and fetching received messages. For example, we can fetch all messages received by the channel from all connections in one request. The only way to identify them is by the ident parameter in each message, which is usually associated with a device IMEI. The same happens to connections and commands — we use an ident to identify a connected device and we know nothing else about the device itself. We position Gateway as a low-level devices communication layer.
With the release of the Registry module, it is now possible to interact with devices as separate entities. To start working with a device within the flespi platform you need to create it first — specify its unique ident value and pick the device type from the list. Once the flespi device is created, all new messages received by the channel from connections with the same ident are accumulated in the device history messages buffer and are available for further operations.
With flespi devices you can:
- access raw messages sent by the physical device based on the messages time-to-live (TTL) setting;
- send commands according to device and channel configuration;
- remotely configure device settings accounting for the protocol capabilities, automatically gather configuration changes from the device, and store them;
- virtualize devices with the possibility to replace hardware without any impact on data processing;
- fork and join communication with devices from various tools such as device management platforms;
- create streams to seamlessly forward messages to multiple platforms and receive commands from them (see below);
Some features are used by programs, for example, access to raw messages can be used by a fleet management platform to store telematics data in a specialized cloud storage ensuring extra quick access and reliability, and eliminating the need to maintain a bulky infrastructure to process terabytes of data.
Other features enable seamless integration of the flespi cloud as a middleware between tracking devices and a platform to deliver extended functionality or work with devices from multiple platforms at the same time. Streams are responsible for sending/receiving data via various protocols to make platforms think that a real device is connected.
Indeed, one of the most exciting features is the possibility to configure devices over-the-air by changing their settings from a device management portal. Protocol and device configurations determine what settings are changeable and when a user changes one, the portal automatically generates a special command executed once the device is connected. As soon as the command arrives at the device, the associated configuration gets updated with the new value. Firmware updates can also be performed via such portal.
Of course, some device manufacturers supply customers with their own online configuration tools, however these work solely with the devices from the given manufacturer. flespi, in turn, offers a unified approach to have all settings from all devices accumulated in one portal regardless of the protocols and manufacturers. Moreover, the manufacturers with no proprietary portal can use flespi to simplify the life of their technicians.
Currently, registry supports the following types of streams to connect devices to software platforms:
- http — makes a POST request with JSON list of messages as a HTTP “data” parameter;
- mqtt — general implementation capable of working with your specific MQTT broker;
- wialon_retranslator — a generic protocol by Gurtam;
- aws_iot — MQTT-based telemetry data transmission to Amazon Web Services;
- thingsboard — MQTT-based telemetry data transmission to Thingsboard.io open-source IoT platform;
We plan to expand this list according to requests from flespi platform users.
The pricing model for the Registry module is explained on the flespi platform pricing scheme. The first 1000 devices within the flespi platform are included in the starter kit. Additional 100 devices cost $1 a month (meaning that the price for 1 device is as low as 0.01 $/month). If you are working with the gateway module we still do not charge for the number of devices connected to the channel and support up to 50 000 connections per one channel.
***
Gateway and Registry modules are like yin and yang ensuring end-to-end telematics connectivity — from end-devices in the field to business applications in the office. This is just a brief overview to put you in the picture of what we have prepared for you; the subsequent articles will include detailed clarifications and practical walkthroughs. You can already check the basic flespi use case here.
Stay with us and try our extended functionality for free.