This September was a harvest month for Flespi. We delivered a lot of minor and major features, both internally and externally. Moreover, we still have a lot of new features in progress to be delivered in the upcoming months. But as usual, let me start from the monthly uptime metric.
We finished September with 100% uptime in both regions. On September 17th, during the wialon-ips protocol renaming process, we faced a fake downtime report delivered to our NOC. Our automatic uptime checking system relies on the protocol name that is used in one of the tests and once the protocol was renamed it started to fail and reported the beginning of downtime. We fixed the test to use an updated protocol name and cleared this fake downtime record.
- We migrated all device message databases to microseconds granularity. This is something that not everybody needs because the majority of devices still report with seconds granularity. But we already see cases related to insurance telematics and quickly changed I/O status handling plus this is an important step to be well-prepared for the dynamic future. flespi analytics system still operates with a second granularity and we are going to upgrade it in October to finish the transition.
- We added the possibility to inject arbitrary messages into devices via REST API. Together with flespi analytics this allows you to solve a lot of complex tasks such as for instance marking certain events in device history and using them in calculators to automatically detect or count intervals.
- Now you can see traffic for the specific device (which is extracted from channel traffic). This simplifies debugging but can be a security hole for some undisclosable protocols. If you want to prohibit access to the device traffic for your users, make sure you are using ACL tokens without packets submodule.
- We see the future of telematics not only in the state and position tracking but also in remote management via API. Last month we published an article about how to remotely control the device and its output lines, and now we published a technical guide in the KB on how to use REST API for remote control. And as a final note to this - we added the COMMANDS tab to the devices and channels screens in the flespi panel that allows you to construct the command parameters according to its schema using a nifty SetBox-like GUI. This is a huge simplification of this process and I invite everybody to try it and move on to the next level with its application.
- It is now possible to change the channel protocol. This can be used for example to replace the original channel protocol with TCP proxy and forward all connections to another IP:port while maintaining the same channel address for already configured devices. Also, channels together with devices can now be moved between subaccounts.
- In August we implemented the concept of post-processing channels that can change the original message before its registration. Usually, such channels are used to handle 3rd party peripheral devices and sensors that are using standard GPS devices as transport. But also there can be some data manipulation algorithms. One of such algorithms is the parameters-filter protocol used to remove some parameters from the message — for example, all position-related data in order to maintain privacy. Our team can develop and install in a private (per account) mode such data manipulation algorithms upon a request.
- Together with the parameters-filter protocol we also implemented the xirgo-mqtt protocol that provides MQTT Broker services directly on its endpoint. The previous protocol that served as an MQTT client to the external MQTT Broker was renamed to xirgo-mqtt-deprecated and is subject to removal in the near future.
- Another cool feature is the settings readout period configuration option in devices that allows users to control flespi behavior for settings values shadow management — read them once on the very first connection from the device (by default), never try to read settings to minimize the traffic, or to sync them from the device with some specific interval.
- Also din/dout parameters, which represent a mask of inputs and outputs, are additionally registered as specific lines with specific values e.g: din.1=true, din.2=false. This is actual only for those protocols where we know the value for specific in/out lines exactly.
- Ruptela protocol now also (like Teltonika) supports encrypted TLS channels. So far only these two protocols together with MQTT-Broker based (e.g. xirgo-mqtt) can be considered 100% secure from traffic sniffing from the device till your application.
- Those in the USA who rely on the flespi modem to send configuration SMS to devices can now safely and confidently use it. It took us just five months to set up the working configuration with our SMPP provider but now you can relax and enjoy it.
- For those looking at entering the bike and scooter sharing business, we wrote a comprehensive article with one of our clients about their experience of building a powerful mobility sharing platform powered by Flespi. The text features a lot of screenshots and nice ideas.
- Of course, the most burning topic for today for Eastern European telematics service providers is the integration with Polish E-Toll. Although each service provider has to go through a number of steps to become accredited, Flespi offers the engine that forwards data from GPS devices into this system in a few mouse clicks.
- We are still in a testing stage for realms — an authorization system based on flespi that can simplify token management (login) procedures for most applications.
At the end of October, we plan to make one more team meeting in Vilnius to discuss the vector of our future developments. Stay tuned and we wish you a very good and productive month!