Although February is the shortest month in a year, we filled it with a lot of news and changes.
The worst one will be the total monthly uptime which fell down to 99.78% due to a 1.5-hour downtime that occurred on the night of February 27-28. This was caused by the network failure of the primary uplink of our connectivity provider during a normal maintenance operation. And due to the nature of the BGP advertisement, it was not possible to fix it by switching to secondary uplinks. Detailed explanations for the reasons for the outage are available in our NOC. For us, this is the second-largest outage after the one that occurred in September 2017. This time we had nothing to do but wait for the fix from the engineers on-site.
The rest of the news here is positive +).
- The largest project our team has been involved in for the last ten months — the opening of a new flespi datacenter located in Russia — was finally finished in February! We even migrated a few users that were very happy as they didn’t experience the downtime described above. The Russian region is totally autonomous and independent in operations with just a few shared systems like HelpBox, billing system, and protocols/device types database. Read more about the new region launch and how to get there on our forum.
- flespi.com website received a whole new system for listing protocols, devices, and manufacturers. Now you may use tag-based filtering in the devices catalog to narrow down the choice to the ones meeting the requirements of your projects.
- For our users in India, we have integrated a special ais-140 protocol.
- We looked into applications where BLE tags can be used, described a few of them and implemented a special ble-beacons protocol. In March we will continue playing with BLE tags to implement indoor navigation based on tags and a GPS tracker.
- We implemented a very special pipe-cache-params protocol targeted mostly towards Wialon users. It can be used to cache and add the occasionally missing parameters in some messages on the fly. Read the full description of this application in our blog post.
- Another interesting feature for the users of Wialon is the possibility to send chat messages directly from Wialon into Telegram for those who are tracking Telegram users via location sharing feature. Once Wialon implemented the support for sending commands to flespi devices and flespi can track Telegram with location sharing, it was logical to finish the integration by adding a special setting for the virtual flespi/Telegram device that is used to deliver chat messages from the platform to the user. Which is what we did. Here you can read the full case amended by recently implemented features. The interesting part is that such chat messages in Wialon could be sent from notifications and jobs.
- We have integrated UDP support into our new pvmII engine and immediately added UDP support to the eelink protocol. Next, we will upgrade the calamp protocol from the older engine to the new one followed by the implementation of remote settings management for it, which is expected to the beginning of March. It means we can finally implement remote control and universal device configuration tool even for devices that are working over UDP and this is great, especially for calamp, which remote control over UDP is a much-awaited feature for our users.
- Another important new feature is the plugin ecosystem that we engineered and implemented for devices and streams. In short, it allows us to define the scheme for additional properties for particular devices (with an activated plugin), fill these properties in the device window and then use the entered values somewhere — in a database, streams or flespi analytics. The very first plugin that we implemented is used to stream into the Bulgarian toll roads system using the tollbg.eu as a recipient.
- flespi analytics engine has received two quite important features. First of all, it now supports timeouts in calculator configuration. The timeout is used to generate a notification when a data flow is interrupted due to the lack of data. In this way, you can control if a device is online or if GPS data is valid.
- Another even more important feature is the possibility to intersect the data from multiple calculators, for example, generate trips that contain stops, where stops are detected by a separate calculator. In our closest plans for the analytics engine is to implement accumulating counters — e.g. total mileage, engine hours, total time spent in geofence and so on.
As you see, once we finished the operations with a new datacenter, we may refocus our efforts on the implementation of the new cool features. And we will. Expect a lot of interesting stuff from flespi in the next few months, believe me.
We are very close to the implementation of OTA firmware upgrades for various devices and protocols. I know that in our quickly changing world it is an extremely important feature and flespi will fulfill it the best possible way soon. Some protocols might already get it as early as in March.
And one more killer feature that is currently in testing from our side is the possibility to display raw (hex/text/binary) traffic for every channel split by device ident in a handy hex viewer like the one you may use now for proxy channels. No more need for proxy channels when you want to catch some traffic from a particular device — it will be available for all TCP and UDP channels automatically in an easy-to-use form. And we will not charge anything for this — like many other functionality, this will be a free feature for every flespi user.
Wishing you a sunny spring! And stay tuned for our news!