Finally, at the very end of December, we had some snow in Minsk and Christmas felt a lot more like Christmas at least for a few days. This year’s winter has been rather warm so far, so instead of skiing down the slopes, we continued our engineering work on the flespi components.
The December uptime made up 99.9873% and all failures were due to our uplink provider and its faulty hardware somewhere in AMS-IX. This was totally out of our control; we only reported the issues and after a few problematic nights the faulty hardware was finally identified and replaced.
Now that the whole 2019 year has passed, our calculations show that the total yearly flespi uptime was 99.986%. This is a bit lower than 99.995% in 2018 but we have a strong reason for that. If you look into our monthly uptime bars for the entire 2019 year, you will notice April with its extremely low 99.925%. This drop was caused by a managed network split between flespi and Wialon networks and this was a rather complicated process. This was not a software or platform failure but a network maintenance operation that greatly affected the whole year’s uptime. What doesn’t kill us makes us better — now we have a fully independent network with our elder brother Wialon and we are looking forward to the really high uptime numbers in 2020.
- Although not about the platform and not about the team but still important — we have a very nice fresh homepage at flespi.com with animations and a clearer explanation of what flespi is doing in this world. Most of the animations are clickable as a link to a corresponding page providing a detailed explanation about this or that item. Now you can explain flespi even to a child — I have personally checked this with my 9-year-old daughter — it works!
- One very interesting feature that will be useful for all flespi users is the possibility to specify rotation size for device messages. It can be used to control the storage size instead of the legacy way of controlling the storage period — once device messages size reaches the specified threshold, earlier messages will be automatically erased.
- We have published an article explaining how flespi analytics is engineered with the hope that it will make it more transparent for our users. The approach of automatic continuous background calculation of telematics data on a 3rd-party backend is something very new and unusual for most people but still, it is extremely promising and scalable for the project of any size.
- Once we finished the platform changes necessary to scale to the second datacenter, we got back to adding features to it. One of our primary focuses will be the analytics engine and in December we already installed a few interesting features to the engine. Our intentions are to make flespi analytics as flexible and powerful in telematics calculations as possible and finally replace the need to do any manual calculations over locally stored messages from devices for any flespi user.
- Two new protocols were integrated into flespi — eelink and dct-syrus. Both protocols were engineered using our new pvmII engine. Of course, due to the usage of a new protocol engine, the integration process was much slower compared to using legacy pvm engine. But at the same time, together with the new protocols integration we implemented a lot of features to the engine itself thus making each next integration faster and simpler.
- We migrated our flespi.io panel to the latest quasar framework. This is something invisible from the outside but the actual diff in our git system contained tens of thousands of changed lines.
- And finally, we removed the implementation of the nis stream and implemented a new — maxoptra stream — the one that is used to feed Maxoptra route optimization engine with realtime data from telematics in distribution vehicles.
In January we want plenty of snow in Belarus. And a stable network in the Netherlands. And we are ready to deliver new features to the platform but let me keep it a secret at the moment.
Have a great year ahead!