Qualcomm is a familiar name in connected hardware. But even when a device comes from a technology leader, getting it into a telematics ecosystem still requires the right software and integration layer. Usually, we forward new vendors to complete integration steps in order for their protocol to appear on the platform. But is it possible to connect a new piece of hardware skipping the common path?
For Embedded Works, a distributor of embedded wireless components with a 20-year history, this meant bringing data from two Qualcomm Aware tracking devices. And the result is a working HTTP integration that makes location, sensor readings, battery status, and events available in a telematics backend. Let’s see how it works, and what any hardware manufacturer can learn from it.
Today, the company works across the IoT stack, from hardware and connectivity to software integration and customer-facing solutions. Its customers include field service companies, grocery chains, factories, and businesses across other industries. This experience organically shaped the approach: a tracking device is only one part of the solution, while its data must also find its way into the software.
Two trackers, two approaches
The devices at the center of this story are the Qualcomm Aware QTS110 and QTS112 trackers. Both are designed for IoT applications, but they take different approaches to tracking and sensing.
The QTS110 is a multi-sensor tracker with a 2,600 mAh rechargeable battery and an IP65-rated enclosure. It combines GNSS, Wi-Fi, and cellular positioning with temperature, humidity, pressure, light, tilt, and motion-related sensors.
This makes it suitable for applications where sensing is just as important as location – from cold chain monitoring to long-term asset tracking and environmental data collection.
The QTS112 takes a different approach. It is a thin, credit-card-sized Cat 1 bis LTE tracker, weighing approximately 25 grams. Instead of GNSS, it uses Wi-Fi and cellular positioning. It also includes motion detection and light sensing, along with a rechargeable battery and docking cradle.
Its compact form factor makes it suitable for smaller packages, equipment, and other assets where size and discretion matter.
These devices include a global eSIM and operate through Qualcomm Aware cloud services. Different form factors, sensor sets, and positioning technologies – but how can their data become available in a telematics backend?
Bringing data into flespi
Both devices are cloud-managed. They communicate with Qualcomm Aware rather than connecting directly to a traditional telematics server over TCP or UDP. That means the integration starts at the cloud level – the Embedded Works team used a standard flespi HTTP channel to receive data from Qualcomm Aware. No custom Qualcomm protocol implementation was required.
The data flow looks like this:
The team configured the channel to receive incoming JSON and map relevant fields into flespi parameters.
For example:
| Qualcomm Aware data | flespi parameter |
| Device serial number | ident |
| Location latitude | position.latitude |
| Location longitude | position.longitude |
| Temperature | temperature |
| Pressure | pressure |
| Humidity | humidity |
| Battery percentage | battery.percent |
| Tilt | tilt |
| Light | light |
| Location technology | sensing.type |
| Alert details | event.type, trigger, value |
The mapping makes incoming information available in a format our backend can process. For Embedded Works, one of the most useful capabilities was packet analysis.
“The ability to do packet analysis, and ultimately formulate the schema for JSON, was very helpful in our efforts.”
Inspecting incoming packets and understanding their structure helped the team build the mapping required to turn Qualcomm Aware responses into usable telemetry.
Why this matters for hardware manufacturers
This is not a complex integration. But it shows how IoT hardware can connect to telematics software without requiring a native device protocol.
Many devices already operate through their own cloud platform or IoT service. When that platform exposes data through HTTP or webhooks, HTTP ingestion provides a practical way to bring the information into flespi.
For hardware manufacturers, this means they can:
Keep using their existing IoT platform.
Forward data to flespi through HTTP.
Map fields into a telematics data structure.
Make location, sensor readings, battery data, and events available to downstream applications.
Use flespi’s telematics capabilities without developing a new device protocol.
The same approach can also work with other cloud platforms that expose data through HTTP or webhooks.
A practical integration layer for IoT
For Embedded Works, the value goes beyond receiving JSON. The company works with hardware from different manufacturers and understands how much effort is involved in making devices ready for use. The ability to inspect incoming data, debug integrations, and quickly validate device behaviour is an important part of that process.
“Having these devices on flespi gives our developers rapid testing, rapid debugging, and assures the devices will be market-ready. This is an invaluable tool in our telematics business.”
Once device data is available in flespi, it can be handled within the same telematics backend as information from other hardware and IoT sources. This makes it easier to work with different devices and manufacturers without building a separate backend for each product.
“The value of working with Flespi is that they come from a telematics background, so they understand the many nuances of parsing telematics data across a variety of manufacturers.”
That is the practical value of this integration. You don’t always need a native device protocol to bring hardware into flespi. If your devices already send information to a cloud platform, HTTP can be the bridge.
And with the integration in place, one telematics backend can work with data from a wide range of devices and manufacturers.