The first month of summer was not that hot but still quite productive for flespi. Part of our team spent a few days in Germany at the CeBIT exhibition. We got a rare chance to speak face to face with our target audience and so far we see tremendous growth in understanding of the flespi idea. Moreover, what we are providing now is already a response to demand from developers of fleet management and telematics solutions. Remember — just a little more than a year ago at the CeBIT 2017 we presented flespi for the first time and it was the first time we announced the idea of the middleware backend in the telematics world. The interest in our concept illustrates that even if we have not created the new market, we have at least predicted it. And this is great! That’s why last week the flespi team spontaneously decided to go to a barbeque party in the middle of the day and discuss our further strategy.
- But we also had some achievements that we are proud of. First, we still maintain an extremely high level of platform uptime — we finished June with 99.991% and stick around this “almost 100%” mark for the last five months. This is a challenge for the flespi platform since Gurtam developers are creating new solutions that rely on flespi for data processing and stress testing us quite a bit. Almost every day we upgraded our storage system and MQTT broker with new patches for better performance. At the platform status page, you can see the real-time numbers of live devices, which is currently more than 100 000. This is the number of unique device identifiers we detected in channels for the last 24 hours. Most of the devices are artificially created for test purposes, but they are still generating real load. By the way, in one year we grew from 6 servers to 21 and all the time we have enough hardware resources to adapt to high growth.
- For the telematics hub, we developed two new protocols — fleetboard for receiving data from Daimler Fleetboard platform and wialon-combine as recommended Gurtam protocol for device manufacturers. Also, we introduced settings management for Teltonika devices, which covers not all device types and not all the settings compared to Concox and Queclink where we are covering almost 100% of both, but still allow to manage most popular configuration options with REST API and via the GUI.
- We continue our transition to MQTT as a primary communication method for receiving data from flespi. We moved the state of all flespi items into MQTT and now it is possible to detect updates in real time. Moreover, now in flespi/state/# MQTT provides some information that is not available via REST API — for example the number of messages that passed last minute from the channel or its last-minute traffic. To understand how easy it will be to work with MQTT from a web-developer standpoint, we also migrated our primary GUI flespi.io to use MQTT instead of HTTP. So now you could track any changes there in real time. And according to our key flespi.io developer Evgenij Spitsyn now it is much simpler — you do not need to initialize state and then poll each time for updates — you just subscribe to a correct topic once and receive initialization data and updates in real time.
- At the same time, we introduced a massive change in parameters naming — we renamed indexed attribute in parameters from ‘#’ to ‘.’ to be able to send the update for each individual parameter in MQTT. For example, analog input 2 was renamed from “ain#2” to “ain.2”. And immediately after that, for the registered devices on the platform with each new message from a device we started to push its parameters separately into MQTT — we call this device telemetry. Also for position-based parameters, e.g. with names “position.*” we create/update artificial “position” telemetry parameter that contains all position information inside. Now to be able to track device’s current location and movements with minimal latency and traffic it is enough to subscribe to the topic: flespi/state/gw/devices/+/telemetry/position.
- Moving in the direction of integrations that I wrote about last month we created the flespi devices plugin for grafana that renders nice charts with devices parameters. For web developers doing integrations with flespi, we made it possible for 3rd party application to authorize with flespi and receive back a valid token for any further actions. Our next integration is a special project for connecting flespi channels and devices to Microsoft Azure. After working with it a bit, together with Google Cloud and Amazon AWS, I would say that these products are too complex, huge and expensive to make a reliable solution, but for those who are already using them, it will be a good opportunity to connect telematics devices to all these cloud systems via flespi.
- And last but do not least. We implemented the flespi_pipeline open-source Python-based tool that has only one goal in mind — receive some data, process/change it and push back. The very first thing that we implemented using flespi_pipeline is a GDPR-related private/public switch that cuts off position information from messages when the private mode is on. Feel free to use this feature for your vehicles on any flespi-friendly platform, e.g. Wialon.
- We are still working on a massive transformation project for the telematics hub and it might even take the whole summer. It’s an important step for us that will make our life easier for further integrations and developments. The same is true for the embedded chat for flespi users support — it is a work in progress until we have this feature introduced in flespi.io. And we are developing own REST API documentation renderer instead of swagger-ui to make life easier for those developers that are using flespi.
Use flespi and enjoy summer!