It looks like in February the worldwide situation with coronavirus is going slightly better, more and more people are being vaccinated and we have good opportunities to resume our familiar lifestyle soon. The same is going to happen to affected business segments as well. We at flespi are keeping our hand on the pulse and can feel how our telematics market is awakening, slowly but steadily. This is a good trend and I’m keeping my fingers crossed with the hope that each month now it will get better and once upon a time current international travel restrictions will be canceled.
Continuing a good trend of 2021 in February we had a 100% uptime in both regions. This is a great achievement and we are continuing to do our best to maintain this level for the remaining months.
By the way, we noticed that more and more of our users are located in the cloud systems, mostly in AWS and Azure. Currently, we are automatically testing flespi availability and performance from servers located in the Netherlands, Russia, and Canada. In the near future, we will install testing servers in the US region of AWS and in Azure to immediately detect any issues in the data flow between the cloud provider and flespi.
February was the month which we devoted to security. Let’s take a look at a general scheme of flespi as a middleware:
flespi users (usually creating custom software) can retrieve data via MQTT and REST API directly and this is possible only via SSL-encrypted connections with enhanced security mechanisms.
If streams are used for data delivery, they rely on the connection protection scheme specified by the user itself. Streams to AWS, Azure, and Google IoT cloud services were properly protected with SSL from the very beginning. This February we raised the security level on the side of http and mqtt streams and forced SSL certificates validation upon connection. It will prevent any possibility of a man-in-the-middle attack. In order to use self-signed certificates, we introduced the possibility to provide the CA key.
The weakest point here is the link from devices to channels. Due to performance limitations on the devices, they are mostly using plain TCP or even UDP connections for data delivery. And although in flespi you can configure the range of addresses that are allowed to connect to the channel, still it is possible to intercept the data somewhere on the path from the device to the channel. But from now, as a side-effect of upgrading to a new pvmII engine, for all our protocols we enabled optional TLS protection. This also requires special implementation on the device side, initially this is available for teltonika protocol and you are welcome to test this new security feature. If there are other devices that already support TLS protection for TCP connection please let us know.
- We decided to simplify the life of our users and introduced a simple flespi-gateway type of channel and corresponding streaming protocol to enable seamless data exchange between flespi accounts.
- We moved in the same direction with Wialon — popular fleet management and GPS tracking platform — we implemented a special type of stream with the simplest configuration possible — just select the product and the region to get the data moving.
- In February we worked closely with Azure — a cloud platform from Microsoft. We posted very straightforward instructions on how to connect flespi to Azure IoT Hub ending with messages appearing either in Azure Cloud Shell or directly in the Visual Studio Code. But we didn’t stop on just feeding Azure with telematics data and decided to extract something useful from this integration. And for any cloud system, the best thing to do will be to create a fully autonomous solution that does not require any piece of additional code or operational application. We decided to enable bidirectional communication between flespi and Azure where the latter will control the device remotely via flespi and generate a beep in the vehicle if it goes out of geofence specified in the device configuration. We fully succeeded with this task and the implementation details are presented in our blog article.
- One more interesting system that we integrated this February was the GPS-Trace platform and its Ruhavik application. The integration is done via a simple ruhavik stream and provides flespi users with a powerful mobile application for GPS tracking, trip analysis, and much more for free. Cool application, works in web browsers, on Android and iOS and I suggest everybody try it.
- One more third-party dashboarding system tightly integrated with flespi that was enhanced with mobile applications for Android and iOS together with additional new functionality is Hazer. Check the overview of its new features in our blog article.
Here is a list of new/updated articles in our Knowledge Base posted in February:
- Our flespi.io frontend application received a package of performance improvements while working with medium and large accounts. This is something not noticeable at first glance, but it may take a huge amount of effort, especially when you need to optimize for Firefox web browser which is usually much slower than Chrome but at the same time much more secure.
- Toolbox — our magic tool that helps to solve any problems on the telematics side received the possibility to export messages to CSV format and its map and track widget additionally received ruler for distance measuring.
- We integrated a new neoway protocol into flespi with its telematics and Industrial IoT devices being now supported by the flespi.
- The part which is not that visible, but took a couple of weeks in February is the upgrade of /gw/devices/ REST API to a newer engine. The best result here for us is if nobody notices anything. With this newer REST API engine, we plan to loosen restrictions on our REST API calls in the future and allow our users to squeeze even more data/operations from flespi than is currently available.
- Together with the overhaul of our REST API engine, protocols new integrations, and GUI enhancements we are also closely focusing on the development of the analytics system and device plugins. Both rely on the same expression engine that currently can generate only numeric output. We are already at the end of the implementation stage with a complete overhaul of this engine that will provide our users with the possibility to operate with booleans, strings, nulls in plugins and device intervals together with a lot of new functions. We even think of applying this expression engine in REST API selectors in the future. Imagine that you may select devices for operations with expressions like “messages_size > 10000 && (protocol_name == ‘teltonika’ || protocol_name == ‘queclink’) && messages_rotate * 0.9 > messages_size”. This is not very compatible with the current specification of REST API selectors, but we will obviously consider how to proceed to make this upgrade with the least impact if to make it at all.
- For device plugins we consider enhancing their functionality not only with the new expressions engine but also by providing tools to cut off unneeded parameters and for other parameters allow to amend the message with their values cached from device telemetry. This is now achievable with a special pipe-cache-params channel, but we want to move this widely used feature directly into devices.
And we are very close to installing a new feature for our users — an extended authorization system with the oAuth support that can be embedded into third-party applications. One popular pain of each application is the secure and featureful authorization system and our new feature should make it quick and easy. Together with some way of using lambda functions in flespi by itself we are going in the direction of secure and powerful serverless applications. Of course, this can take months or even years but this is the way we see the future of quickly-created, powerful, and secure applications for mobile and Internet users. Hope you are sharing our vision!