Empowering Real-World IoT with MQTT – Lessons from a Fleet Tracking Project

TL;DR

An engaged service provider from Australia once asked for help in the HiveMQ forum. He wanted to connect his fleet of GPS trackers and build a modern, secure platform around it. As a private project, I decided to help him because it sounded exciting and meaningful.

I helped him get HiveMQ up and running, properly configured, securely set up, and ready for production. He was thrilled by how HiveMQ allowed only authorized devices to connect and how easy it was to monitor progress through the admin UI.

We started connecting the first trucks. Their GPS trackers spoke a proprietary binary protocol over pure TCP. To bridge that gap, I wrote a couple of small Python scripts that converted the incoming data into clean JSON and published it to HiveMQ under structured topics.

For visualization, I used Telegraf to pull the MQTT data into InfluxDB, and from there into Grafana dashboards. The entire setup was containerized and could be started and stopped easily with Docker Compose.

The Problem: Real-Time Fleet Tracking with Legacy GPS Devices and Protocol Challenges

The company’s goal was simple but critical: track and manage their trucks in real time. In their world, when the trucks stop, Australia stops. This was not just a side project—it was essential infrastructure.

The main challenge was that the GPS devices all used different, sometimes very limited communication protocols. Some could only speak TCP while others would later support MQTT. We needed a way to unify everything, make it reliable, and ensure the system could grow over time without breaking apart.

The Approach: Using MQTT and HiveMQ for Data Ingestion

That is where MQTT came in.

HiveMQ became the backbone for a clean, secure, and scalable data ingestion layer. Each connected device had its own access control, and only authorized clients could exchange data. The topic structure was designed as a Unified Namespace, separating manufacturers and message types.

This approach made it possible to grow the system step by step, and the switch from pure TCP to MQTT-ready trackers would later be seamless. MQTT acted as the reliable middle layer, the translator and traffic controller, ensuring that data was clean, structured, and protected from the chaos of raw network noise.

The Results: Reliable IoT Fleet Monitoring with MQTT

The platform went live with the first batch of trucks, and the data flowed in smoothly.

Dashboards lit up in Grafana, showing locations, movements, and historical data trends.

Each MQTT topic represented a clear piece of the system: one for the manufacturer, one for telemetry data, one for status updates. It was tidy, logical, and efficient.

Best of all, it just worked. This is a simplified outline; the real system was fully containerized and built with DevOps principles in mind.

Lessons Learned: Why MQTT Outperforms TCP for IoT Projects

The biggest lesson I took away from this project is what MQTT really saves you from.

When you work with pure TCP, you spend an incredible amount of time and energy just keeping the system safe and stable. You get random scans, malformed packets, and bad data that can crash your entire stack if you are not careful.

MQTT removes so much of that burden. Once we moved from raw sockets to MQTT, the system immediately felt calmer, more controlled, and simply right.

If I had to give one piece of advice to anyone in the IoT or telemetry space: