3 November, 2025

October 2025 change log

Major flespi improvements in October 2025.

In October 2025, flespi operated with 100% uptime for the third month in a row with zero incidents detected.

As you probably know, this month was a total disaster for Big Cloud Computing services such as AWS and Azure. A couple of months ago, Google Cloud Platform experienced a large outage due to a NULL pointer exception, and now two other major providers followed the same track, although each one with their own reasons. In mid-October Amazon Web Services platform experienced a multi-hour outage due to DNS issues. And a few days ago, it was Microsoft that followed this after the Azure Front Door service was misconfigured.

The consequences of the Azure outage are still being estimated, but even for AWS, we may count hundreds of billions of dollars in losses, and to date, the most highlighted IoT-related incident is related to expensive smart beds, which started malfunctioning with uncontrollable heating and position changes due to the incident.

The quality of software produced nowadays is really low, according to my personal benchmarking, and being the one who brings cloud services such as flespi into the world, I’m very scared and conservative when it comes to IoT cloud services in my personal life – cars, kitchenware, house, etc. In big corporations, everybody is pushing the pace, infrastructure systems are complex, and it’s impossible to keep quality at a high level. So whenever your car is connected (and almost all new cars are), most probably you can be tracked and controlled.

I do not have a simple answer on how to protect from this. My personal strategy is to rely on small and mid-size organically grown companies, which connect the business success with their staff and maintain a high level of personal responsibility within their team when a company employee binds the success and pains of the company with their own success and pains. This simply does not work in corporations.

Now back to flespi.

The Telematics and Connected Mobility Conference was a really great and successful event. We invested as much as possible to attract a diverse group of industry experts and gather all competing (even with Gurtam) companies under the same roof. We moderated all the content to avoid marketing and sales speeches, and in fact, the content turned out to be the gem. And as for me personally, I was really proud of those flespi users presenting their stories (not always even connected to flespi, but always about telematics), proud that we have such great partners to work with together to make this world better (and safer!).

We decided to organize the second such conference in the autumn of 2027 and are already reserving the venue. The exact dates will be announced in 2026; keep this in mind for your calendar. ;)

We integrated into flespi two new manufacturers: Gosuncn and BSJ Technology, and enhanced the Squarell protocol with tachograph functionality.

With grants, we implemented a simple possibility to share top-level account access at various levels up to “operate-as” to another subaccount. This can be efficiently used together with realms for your support and engineering staff to maintain a dedicated HelpBox chat (often with focused AI assistance) for each user, but operating with the same flespi entities you have in your top-level or production account.

We adapted the media-upload-s3 stream to Oracle Cloud Object Storage together with the initial AWS S3 implementation.

For tachograph functionality, besides the support of new manufacturers, we are constantly improving the integration level for all devices to ensure .ddd file retrieval is an absolutely durable and efficient process. This is a long way, and we are somewhere in the middle of it, but even today, the tacho functionality in flespi is quite good, often providing much better performance compared to native server implementations by device manufacturers. We are now working on parsing .ddd files to extract some valuable information from it directly into the meta field of the media file.

We are currently in the process of standardizing id field formatting in the ble.beacons array across all device types. The logic for the id field for the beacon will be to register the id value from theuuid, if it is available, or from the mac field if not. And together with id that will be registered original beacon parameters, such as uuid or mac, depending on the beacon connection type. The update of each particular protocol is reflected in our changelog, with the first 17 protocols already having this logic implemented.

In our roadmap for this year, we promised to work towards OEM integration. We actually did, but until now, they were unbelievably slow and not that flexible for such integrations. You may not believe it, but for one OEM, it took 6 months (sic!) to coordinate the minimal contract changes and return to us with a response. It seems that the telematics service is something they are totally not interested in selling, except maybe directly to fleet owners. So, after a few unsuccessful attempts at direct integrations and even maybe packing their telematics as part of the flespi product offering, we decided to change the idea and search for partners providing similar services that are already integrated with OEMs.

In Europe, we found such a company – High Mobility. We validated their pricing, which was not too much different from what OEMs offered to us. So initially it looked like from the cost perspective there won’t be too much difference for fleet owners to operate with OEM telematics either directly through flespi or passing the data stream via High Mobility. Given all the complexities OEMs require in their contract, we decided to give High Mobility a try and did integrate with them. And finally, in October, we see that increasing traffic flows from High Mobility towards flespi, so this integration is now adapting to the reality and improving. So whenever you have a fleet owner who wants to use OEM telematics services directly without installing aftermarket devices, you can safely try this with High Mobility. For the US and Canada, we are still searching for similar hubs to integrate with.

One more feature announced in our roadmap and postponed for next year is real-time video streaming via WebRTC. Still in our plans, but unfortunately, it is not possible to implement this year.

However, what we will implement instead, and what was not in our roadmap, is that the channel protocol upgrade process will be softer and during the routine protocol upgrade process we will close channel connections much more softly within a certain period of time (it can be minutes or even hours) to prevent this instant connection close/open spikes like we have now. We even have some ideas to implement a real-time seamless replacement of the parsing module to avoid connection closure at all.

One important change that will affect users of video telematics in flespi is that we decided to revert a hack introduced in May 2024 regarding media connection traffic to be excluded from channel traffic. Initially, we had a problem reported by a few users that the device video traffic upload was blocking a channel due to the traffic per minute limit. This obviously was expected because devices were uploading large (100MB+) files quite quickly, and once the traffic counter passed above limits, channels were blocked, cutting all connections. The only solution here was to upgrade to a higher flespi plan (for video telematics, the initial recommended plan was Pro) or configure more channels and split devices between them.

So, as a quick solution in 2024, we decided to avoid counting device media traffic as channel traffic and announced this, which actually opened the possibility to work with video telematics even on a Free plan.

And now we have decided to implement better logic for channel blocking. Instead of closing all established connections when the channel is operating above its allowed limits, we will prevent any new connection to the channel and close only the most consuming traffic or messages connections. It will efficiently cut only devices that are sending too much traffic or messages, leaving unaffected “normal” ones.

We already implemented such a mechanism with channels for connections limit, and soon will do the same with device messages/traffic counting. So right now, we recommend all video telematics users either upgrade plans to Pro/Enterprise or create more channels. The change with traffic counting will be applied in mid-November.

And as a side-effect of this, now there is a dedicated last-minute traffic and messages counter fields in the devices API.

And finally, for AI-related operations, we have internally implemented the MCP technology stack and are currently evaluating how to give access to flespi via MCP to your AI agents – support consultants, sales representatives, developers, etc. I believe we will have some MCP available for you either this month or next one.

And last but not least. Immediately after the publishing of the gen4 AI platform architecture this summer, we started to work on a totally different AI system. The new system is a kind of autonomous process capable of moving step by step towards some North Star Mission. North Star Mission is unreachable and depends on the process AI is working on. For example, for protocol development tasks, it is one, for flespi platform administration, it is another, and for flespi users consulting services, it is the third.

It took us around 3 months of focused work in PoC mode and a few evolved versions to finally define the architecture of this system and try it on real tasks. And it seems that the results are pretty amazing, especially in the development domain. Yes, a lot to implement to make it mature, but even on the current level, this system will definitely change the way we are working.

How can it affect you? Well, actually a lot. From making protocol development work much quicker and cheaper, up to proactive monitoring of telematics-related parts of your business, and informing you of possible opportunities and threats in advance. Do not expect it too soon, but somewhere in the second half of 2026, it can sound realistic.

GenAI technology is fundamentally changing the way we do our business. Maybe not that quick as it is hyped, and the transformation will take a decade or even two. But it happens right now. And we are lucky to live today to be the witnesses of this transformation.