1 February, 2019

January 2019 change log

Major flespi improvements in January 2019

January this year was extremely chilly in Belarus. That’s why flespi team concentrated on the engineering part to prepare for vacations in warmer months.

  • Our most important achievement in January was the resolution by the team that we are not a startup anymore. The resolution itself is based on the fact that we demonstrated 99.995% yearly uptime in 2018 and our REST API for various platform components was stable and modified in a backward compatible manner only. At the same time, we already have more than 1000 users of the platform with a decent percentage of projects and products using flespi as an internal component.
  • Based on these stats we modified the terms of use and raised the uptime guarantee bar in our SLA responsibility with automatic 70% penalty to the monthly bill in case our uptime will be less than 99.89% for Premium level. 
  • Regarding January itself — we finished it with 99.986% uptime. On January 15 we experienced three service interruptions of 99, 8, and 259 seconds long, all for the same reason. The problem was due to abnormal load to one of 48 database partitions we have and most of our users were unaffected. However, our clever and honest bot detected this problem from two locations and we counted it as downtime. We installed a hotfix to restrict the load and in two days implemented alternative write operations queue handling on our storage system so that such load should not affect us in the future.
  • Among other important features we delivered is a long-awaited presentation of the enterprise level subaccounts feature and a set of articles on the same topic in our knowledge base. With this feature, it is now possible to use flespi seamlessly as a part of a large-scale system with millions of connected telematics devices. Subaccounts feature engineering started in August and took us four months to deliver it to our users in a documented form.
  • We are actively moving from old-fashioned e-mail based communication to modern and fast chat connecting our users directly with the corresponding engineer. There we are able to provide instant support to flespi users solving any type of questions in minutes. In January we released a dedicated chat application helpbox.flespi.io that can be used separately from the flespi panel. We plan to utilize the latest technologies there like PWA or push notifications to provide the experience you expect from native Messenger applications on mobile phones.
  • January 2019 is the official birthday of the HASD technology. In this rapidly growing IT world, we try to minimize time-to-market for software applications and this new technology was designed with this goal in mind. HASD is not only about MQTT or telematics — it’s a generic state database for any kind of software applications.
  • Internally we are already using HASD technology a lot. For example this month we moved the entire device settings storage from a relational database into MQTT and now you may enjoy an absolutely new experience with flespi device configurator where everything is fast and smooth due to push-based state visualization backed by MQTT.
  • We integrated two new protocols: one for Tekelek sensors and another for Borderless Hub. As usual, we integrated a lot of new devices for existing protocols, as you know these device manufacturers are releasing new device models and firmware upgrades almost every day. This is a non-stop background work and the primary reason to use flespi for many of our users.
  • Since we encounter more and more devices with incorrect firmware, we decided to prevent device telemetry from rubbish values by limiting the possibility to specify message timestamp during registration in the future up to 24 hours from the moment we receive this message. It means that if a device sends a message with a timestamp more than 24 hours in the future, it will be replaced with the current time on our servers.
  • For our pure MQTT users, we also have a bunch of good news. First of all, now all online and offline MQTT sessions are visible in the panel and it is possible to force their disconnect.
  • In our broker, we implemented WebSocket level compression for MQTT inbound/outbound packets that resulted in 7x traffic reduction under normal conditions. The compression is enabled by default on all modern browsers so you should already feel it in your projects. 
  • For persistent, i.e. non-clean, MQTT session we increased the maximum expiry interval from 10 days up to 365 days. This is to allow persistent sessions usage in long-running projects, in which a session can be offline for up to one year but still receive all subscribed messages upon reconnect.

In February we will continue optimizing our internal systems’ performance and behavior under high load. One of our well-known users is currently changing its existing platform implementation to rely in telematics data processing and storage purely on flespi that should bring us approximately 150,000 devices on the backend in the middle of this year. 

At the same time, we have more and more Commercial flespi users with their less ambitious, but still very important projects and products. Being used as telematics gateway and primary storage system for such projects we do a lot of invisible day-to-day work to enlarge the list of integrated devices

We also plan to add more features to HASD by analyzing typical cases in the industry. When we notice that a certain project can be optimized by redesigning its architecture, we are in this business. This is an almost invisible background process we are involved in each day.