January 2025 was an unusually warm month. It didn’t feel like the middle of winter but more like an early spring or late autumn month. Global warming definitely played a role in this, and Gurtam, as one of the world’s leading telematics providers, together with thousands of Fleet Management Providers, has to do something about it. For example, we can push our end users — fleet owners — to upgrade their fleets from ICE to electric engines by providing solid numbers on the economic and environmental impact of such a change. If not, just take a look at the latest study predicting millions of European deaths due to global warming. And Southern European countries are obviously among the most affected.
And since we already know that the newly elected U.S. president has declared war on environmental protection by pulling the U.S. out of most environmental agreements and even ordering the removal of climate change-related content from official U.S. websites — who will save the planet if not us?
So, back to flespi. In January 2025, our uptime was 100% for the fourth month in a row. Actually, that was last month because, at the beginning of February, we already experienced small service interruptions affecting our telematics gateway REST API services for a few minutes. The issue was quickly mitigated and fixed, and I will provide more details on it in the next changelog. But still, four consecutive months of 100% uptime was a great achievement and a record for us.
There was also an issue with webhooks that were partially unavailable in the middle of the month. We were unable to detect this automatically since webhooks, being a more recent functionality, were not part of our standard uptime testing procedures. After this case, we decided that any kind of problem with webhooks should be counted towards our downtime as well and added them to the standard uptime test sequence, which now consists of more than 20 operations running every minute from 18 locations worldwide.
We integrated two new protocols into flespi — itraiangle and globalstar. As part of our 2025 roadmap towards integrations with vehicle OEMs, we are already in negotiations with a few of them. If everything goes well with the actual testing, we might release these integrations in February. However, negotiations and testing with OEMs are painfully slow compared to working with aftermarket device manufacturers. Telematics is far outside the core business of OEM vehicle sales, and the reliability of their data flow and the quality of their data points are really poor.
When we consider the reliability of data flow — where even a few minutes of interruption are considered catastrophic by our standards — it's quite different from theirs, where pausing the data feed for a day or more is part of standard maintenance. For now, I strongly recommend sticking to aftermarket devices. However, OEMs are changing their approach, and we are integrating them to bring more customers and interest to telematics, so one day, I believe they will become strong competitors to today's aftermarket device manufacturers.
By the way, we published the annual overview of aftermarket device manufacturers whose devices were connected to flespi in 2024. Teltonika is definitely the leader for us, but the competition for the next five places was quite tight. Read all the details in the article.
In January, we committed quite a bit of attention to the video telematics direction. We added numerous improvements to all supported protocols and defined the standard set of ADAS and DSM event-related parameters across them. Special attention was devoted to supporting the full range of video telematics solutions from Teltonika, including their DSM and ADAS cameras, which delayed the Tacho integration for this manufacturer a bit. However, the Tacho integration for Teltonika is now in active development, and we expect to release it in February.
On a separate note, I’d like to highlight that we integrated a new flavor of the Queclink protocol, with support for quite a lot of new devices. This is a completely new kind of binary protocol by Queclink that they plan to power the communication of all future devices. For flespi users, this transition by the manufacturer will be seamless, with minimal effort required. This is a great advantage for the manufacturer as well, as it allows them to accelerate the transition of their customer base to the new protocol and eliminate the need for legacy protocol maintenance and support.
As part of our focus on advanced telematics solutions, we added support for DTC codes according to the J1708/J1587 standard to the msg-dtc-decoder plugin.
We also decided to improve our users' experience with custom (e.g., unnormalized) parameters. Custom parameters are those whose name starts with the ‘custom.’ prefix. Previously, as part of our standard SLA, we integrated custom parameters with a new normalized name into a protocol without prior notice. However, sometimes our users complained that such integration disrupted their data flow when they suddenly started receiving these newly integrated parameters with a different name. To address this, we decided to integrate custom parameters the same way we handle any other parameter whose name or value needs to be updated. We will publish a preliminary notice in the changelog and support both custom and new parameter names during a one-week transition period.
And last but not least, we significantly increased codi’s intelligence. Our AI assistant now has the ability to access the protocol code upon request and investigate how the telematics data flow is implemented in flespi — what parameters are integrated for each particular device, what values they can receive, and how they match with the original protocol published by the manufacturer (e.g., what and how we normalize).
The unique feature that you can now use is the ability to explain everything related to the data that could be sent by a device. Together with the previously implemented ability to access the manufacturer’s documentation for most devices, and with access to actual data and events from the device in your flespi account, you now have a very capable technician who can analyze a lot upon your request. Just remember to provide the actual device ID from your account, and you can task codi with anything related to the device.
With this wonderful combination of information from three different sources — actual device telemetry, device manual documentation, and the actual device protocol implementation in flespi — our AI assistant is now unbeatable in its telematics intelligence, even for hardware manufacturers’ official support agents. So, no need to bother the manufacturer support team anymore. Instead, pass your data through flespi and use our highly efficient AI assistant to solve any device-specific problem.
To take codi's intelligence even further, we equipped it with access to anonymized support case resolutions across our user base. Essentially, it’s now a self-training system where the AI is capable of remembering everything and automatically improving itself. The outcome of this is still under investigation, but from what we can see, codi — with its super-efficient memory of everything that’s happened in flespi over the last 7 years — is now also outperforming our human engineers in most support cases. It’s becoming more and more like an official team member, and one day we may even give it a dedicated spot on the official flespi team page.
As we promised in the roadmap, we are currently developing the drivers' subsystem in flespi. We decided to step away from fleet management terminology and name this new system “assets management.” An asset will be a kind of virtual entity linked to a specific device at a specific time — like a driver driving a vehicle at a certain time, or a rider renting a scooter for a few trips. It can also be a trailer, or serve as a vehicle if you are switching devices between vehicles, for example.
We will implement an API to manage these assets and link or unlink them from devices at specific times. This will be the very first step for this functionality, which we estimate to roll out in late February or March. The next step in asset management is integrating this functionality into analytics, where calculators will be able to access assets in selectors (e.g., split trips when an asset is assigned to a device) and counters (e.g., list drivers assigned to the device).
The final usefulness of assets will appear when we provide transparent access to calculated device intervals through assets. For example, a call to retrieve trips for assets will be transparently proxied to trips for all devices linked to this asset, with their respective times. This will make the transition from a device-based software architecture to an asset-based one quite seamless. Of course, we will also consider providing functionality for the automatic registration/unregistration of assets to devices based on data in device messages.
This full set of functionality with assets will take time. However, what you need to know and understand today is that there will be no breaking changes in the API, and whatever you construct today using flespi analytics will be preserved and transparently available for assets (e.g., drivers, riders, trailers, vehicles) when we implement this subsystem.
Enjoy the last winter month in the Northern Hemisphere and remember to protect the environment we live in. Protect the Planet!