February is the shortest month of the year, but in 2025, it was fully packed with events. And most of them didn’t come from the telematics world but from North America. It’s hard to say how the situation looks from inside the U.S. However, from the outside — through the eyes of decade-long U.S. partners like Canada, Mexico, and European countries — it’s all about frustration and rapidly growing expectations of the worst. Actually, I think the same sentiment prevails in most other countries.
It seems the U.S. is quickly losing its position as a reliable trade partner, military ally, and, overall, a country you can trust or build long-term political cooperation with. The country is now headed by a leader driven by personal goals, making rapid and chaotic political moves both internally and externally. The focus is on short-term results, with little regard for history, a quick dismantling of existing architecture, and a lack of long-term vision.
When all this happens to the world’s #1 economy, it creates the perfect hand for a deep and prolonged economic recession. Maybe that’s exactly what the world needs right now to stop the war in Ukraine — but even this realization doesn’t inspire much confidence in the final outcome.
Now, back to telematics and flespi in particular. We wrapped up February with a 99.9924% monthly uptime. The only three minutes of unstable availability in telematics REST API services, we had on February 1, were due to a bug that surfaced after a major architectural refactoring of our REST API subsystem. The issue was quickly mitigated once detected.
Another failure we experienced — though not reflected in our uptime metrics — was a partial webhooks outage on February 20. The outage affected only webhooks serving MQTT messages with a payload size of 512 bytes or more. This was related to another large architectural refactoring of the MQTT event bus, where we introduced compression to reduce dependency on network bandwidth. Due to a tricky combination of factors, this issue wasn’t detected during development and only appeared in the production environment. Now, our pre-production tests cover this kind of scenario as well.
As you may have noticed, most of the issues we’ve encountered recently were tied to internal optimizations. And that’s true — since late 2024, we’ve been deeply focused on improving our internal systems, making them faster, more reliable, and more predictable for our users. This is driven by the growing demand for our services, which we continuously scale to meet.
It’s hard to pinpoint the exact catalyst for this surge in demand — whether it’s our super-intelligent telematics AI assistant codi, the release of tacho functionality, enhancements in video telematics functionality, or simply the overall maturity of the platform. Either way, we’re not just on for new features but also ensuring that the flespi platform — both hardware and software — can handle at least double its current load. This aligns perfectly with my response at Gurtam DevConf about the ideal balance between feature development and refactoring for a strong product. We usually keep it around 50/50.
The biggest highlight for us in February was, without a doubt, the integration of tacho functionality into the Teltonika protocol. It took at least two months longer than expected, but the demand for it is huge. Personally, I didn’t anticipate such high interest, as I don’t see Teltonika’s popularity being directly tied to tacho functionality. However, as soon as we announced the integration, within about a week, a dozen European TSPs were already testing it — which I’d call a real boom. I’ll be keeping an eye on how this evolves and which manufacturer will lead the tacho race for us by the end of 2025.
Right now, we’re fine-tuning and improving tacho support across protocols to ensure the best and most transparent operation. We’re also enhancing Mediabox for .ddd file management, improving the Tacho Bridge App with a better UI/UX, and adapting it for seamless use in Tacho card hotels.
We also integrated two new protocols into flespi: Squarell and Volvo-Trucks. Both are notable for their extensive parameter sets (100+), most of which are related to EV and CAN bus data collection. A special mention goes to the Volvo Trucks integration, which aligns with our ongoing strategy to connect OEMs directly to flespi. We’re currently working with several other OEMs as well. The key difference between standard on-demand protocol integrations and those we develop proactively is the testing phase — since we usually don’t own many vehicles from these brands, we rely on external partners to assist with testing.
In analytics, we enhanced the implementation of a so-called cross-calculator referencing system, allowing calculator intervals to be added from another one. The latest update enables the selection and referencing of intervals that occurred before or after the active interval. Simply put, this makes it easy to build and automate HoS-type compliance checks. For example, if you need to add rest time data from the past 24 hours to a current trip, this feature simplifies the process.
The magic of flespi analytics is that it automatically applies both to historical data and real-time updates, based on incoming telemetry from the device. The real power of this system becomes evident when, with just a few clicks, you can generate a comprehensive HoS state report — showing continuous driving time, rest periods, and other required details based on the country’s regulations. This data can be monitored on the go for quick decision-making or even injected directly into the device message and streamed into a fleet management system.
For all reverse geocoding plugins, we unified their output under the same 'address' parameter instead of using provider-specific naming conventions. This is configurable, but the default setting now follows the unified naming approach.
We also completed the refactoring of the stream logging system. Now, all streams publish the details of each message, whether processed or skipped, in their logs. Previously, log entries were created for entire message batches. This significantly improves transparency and traceability in message streaming.
Moving forward with traceability, we support optional 'x-flespi-trace' and 'x-flespi-app' HTTP headers, which you can use in your REST API requests to flespi. The values passed in these headers will be attached to any flespi entity log related to the API call. For example, in a device log, you’ll be able to trace who was responsible for specific actions — such as queuing a command or updating a device configuration.
Wialon has informed us that they now support their video telematics module features, including live streaming directly from the video-enabled devices that are connected to Walon via flespi. This significantly improves the transparency of video operations in Wialon and simplifies troubleshooting.
We conducted an interesting test comparing the behavior and configuration of older (FMC920) and newer (FTC921) Teltonika devices. If you're considering migrating to the new generation of Teltonika devices, this article is definitely worth your attention.
In the last week of February, we upgraded codi with the latest Claude 3.7 Sonnet model from Anthropic. This incredibly smart model, powered by our AI assistant architecture, has once again raised an already high bar. After switching the primary agentic model to 3.7 Sonnet, I reviewed chats to assess the impact — and, frankly speaking, I was impressed. Now, codi is capable of solving really tough issues and performing highly complex diagnostics. Some users have already discovered its device diagnostics capabilities, while others are yet to explore them. But trust me, when correctly instructed and supplied with the right tools, it’s a whole new level.
To give you an example of the kind of problems codi resolves for our team, take a look at the screenshots of the communication below. One of our experienced users complained about a discrepancy in the set of parameters reported by different firmware versions.
Typically, resolving such cases requires diving into protocol documentation, analyzing device telemetry, and inspecting raw traffic from the device. Since the user had their chat mode set to AI responses, codi acted as an intermediary between the flespi engineer and the user, handling the entire conversation.
Initially, codi escalated the request to our team for investigation. As the support engineer on duty, I asked codi to obtain the real device IDs before proceeding further. Interestingly, the user had already provided them while I was typing my request, and I didn’t even notice it — until codi pointed it out:
Once codi checked the traffic, I requested it to perform diagnostics. A few minutes later, it delivered a detailed analysis of the issue, using 1.8M tokens and costing around $0.20 in total:
As you can see, this was a deep dive into the situation. To generate this report, codi called various tools 22 times — retrieving and comparing device logs, analyzing traffic, inspecting messages and telemetry, reading documentation, and checking the existing protocol implementation. After that, I asked codi to send the report to the user, effectively resolving the issue.
This is just one of many examples of how we use codi in our daily operations. Whenever a user contacts us with a complex, non-trivial issue, our first step is to leverage codi for diagnostics and recommendations. Believe it or not, support work has actually become fun. Now, as an engineer, you’re more like a manager — sitting at your desk, making decisions, and overseeing AI as it does the heavy lifting. Sure, we could even create another AI for this managerial role, but then we’d lose all the fun.
Codi has quickly captured 80% of the communication between our engineers and users, firmly protecting its position, as shown in the chart for 2024 and the first two months of 2025.
With the enhanced intelligence of Claude 3.7 Sonnet model in complex problem resolution, I believe codi’s share will continue to grow and may reach even higher numbers by the end of 2025.
In March, we’re continuing to develop the assets system, which you’ll soon be able to use for drivers, trailers, vehicles, and assets management. We’ve already defined the architecture and capabilities of the new system and are in the implementation phase. I believe we'll be able to release the API by the end of April, with the remaining and most important automation features coming shortly after.