On paper, asset tracking is simple: stick a tracker on a thing, see the thing on a map.
In practice, you end up with equipment hopping between sites, pallets moving through warehouses, trucks crossing regions, and a few assets that need someone watching their temperature. Each of those wants a different tracking method, and getting a coordinate back is the easy part. The hard part is making that data trigger something useful.
Here's how I'd approach designing one of these systems, roughly in the order I'd make decisions.
Ask about the asset before you pick the tech
It's tempting to start with "let's use GPS" or "let's do BLE." Resist that. Start with questions like these:
What are we tracking?
Where does it normally live and move: indoors, outdoors, both?
How fresh does the location need to be? Every second, every 15 minutes, once a day?
Does its condition matter, or just its position?
How long do we keep the data?
When something goes wrong, what should actually happen?
A delivery van crossing cities and a pallet shuffling around a warehouse have almost nothing in common as requirements. Your answers to the questions above will narrow the tech choices quickly.
GPS: mobile, outdoor, wide-area
GPS makes sense when you need to know where something is across a big geographic area: fleet vehicles, trailers, construction equipment, mobile machinery, high-value gear.
The typical pipeline:
text
GPS device → cellular/network → tracking platform → location processing → dashboard + alerts
You get coordinates, movement, stops, and routes. But a dot moving on a map isn't an operational answer by itself. What people actually want to know is:
Did the vehicle enter (or leave) the area it was supposed to?
Has this machine been idle for too long?
Did an asset leave a permitted location?
Was a scheduled movement supposed to happen and didn't?
Those are the questions that turn raw location into something an ops team cares about.
RFID: "this thing just passed this point"
RFID works differently. Instead of continuously computing coordinates, it tells you an asset was seen by a reader at a checkpoint. That fits warehouses, distribution centers, factories, and other controlled spaces well.
text
RFID tag → reader → event → database/asset platform → inventory/workflow update
Say you want to know when an item enters a warehouse, leaves a storage area, or reaches a processing station. RFID gives you that event without putting a GPS unit on every single item, which is a big deal for cost.
BLE: when GPS stops being useful indoors
Indoors, GPS gets unreliable, and you often need finer detail anyway. Bluetooth Low Energy (BLE) with beacons, tags, and gateways is a common answer. Typical uses are tools, medical equipment, containers, warehouse inventory, and access-related workflows.
text
BLE tag → beacon/gateway → location calculation → tracking platform → dashboard/alert/workflow
One caveat: "use BLE" is not a design. Accuracy depends on building layout, gateway placement, interference, battery life, and how precise you actually need to be. Room-level and shelf-level tracking are very different projects.
Sensors: from "where" to "what's happening"
Location answers where is it? Sensors help with what's going on with it? Depending on the use case you might track temperature, humidity, vibration, shock, door status, motion, or battery.
If you're moving something temperature-sensitive, knowing it's in the right city doesn't help much if it's been warm for three hours. A richer data model looks more like this:
text
Asset
├── Location
├── Temperature
├── Movement
├── Battery
└── Time
You'll probably combine several of these
Big deployments rarely pick just one technology:
text
┌── GPS ─────── Outdoor location
Asset ───────────┼── RFID ────── Checkpoint events
├── BLE ─────── Indoor location
└── Sensors ─── Asset condition
↓
Data platform
↓
Rules / analytics
↓
Alerts + actions
The hard part then becomes integration. If every source emits its own format, you need a normalization layer that turns them all into one event shape. Something like:
json
{
"asset_id": "trailer-0042",
"source": "gps",
"type": "location",
"timestamp": "2026-09-21T09:14:03Z",
"payload": { "lat": 5.6037, "lon": -0.1870 }
}
The same envelope can carry an RFID read, a BLE position, or a temperature reading. Downstream rules and dashboards then don't have to care where the event came from.
From events to actions
A platform gets valuable when it does more than store events. Here's a basic geofence flow:
text
Asset leaves approved area
→ geofence event detected
→ rule checks asset status
→ alert generated
→ responsible person notified
→ action taken
And the rule itself can be pretty small:
python
def on_geofence_exit(event, asset):
if asset.status == "in_transit_approved":
return # expected, don't bother anyone
notify(asset.owner, f"{asset.id} left {event.zone} unexpectedly")
The point of that early return is that you're not trying to generate thousands of notifications. You're trying to surface the few events that need a human. Too many low-value alerts train people to ignore all of them, and then the important one gets missed.
Design for scale early
A system that's fine for 50 assets can fall over at 50,000. Things worth thinking about up front:
Device provisioning and unique asset IDs
Data ingestion and API design
Database architecture and data retention
Authentication and access control
Battery management
Monitoring and alert processing
Connectivity failures
That last one deserves extra attention. Devices go offline, batteries die, readers miss tags, networks drop. Build for that from day one instead of assuming every event arrives on time and in order. Late and duplicate events are normal, so make ingestion idempotent and let the system say "last seen 3 hours ago" rather than pretending it knows more than it does.
The dashboard isn't the goal
It's easy to treat the dashboard as the finish line. It's really just a window onto the data. What matters is what people do after they look.
Data: This equipment has been stationary for six hours.
Insight: It might be underutilized, or waiting on another process.
Action: Ops looks into the delay and decides whether to reassign it.
text
Data → Context → Insight → Decision → Action
If you stop at the first step, you end up with an impressive tracking system that generates lots of data and changes nothing.
A rough checklist for choosing an architecture
There's no one-size-fits-all setup, so I'd start by mapping assets and workflows:
Which assets matter most?
Where do they move?
What information do you need about them?
How often do you need it?
What connectivity is available?
Which events deserve an alert?
Which existing systems need this data?
How will it scale?
If you're comparing approaches to location, monitoring, and tracking, [Asset Track Pro] is one platform worth a look.
Wrapping up
Asset tracking is shifting from "put a tracker on it" toward building a connected information system. GPS covers outdoor location, RFID gives you identification events, BLE handles indoor positioning, and sensors tell you about condition. Designed around a real operational problem, that combination is far more useful than a location dashboard.
The question I'd keep coming back to: what does the business need to know, and what should happen when it knows it?
A few notes:
Disclosure: since the post links to a product, DEV readers tend to respond better if you add a line like "Disclosure: I work on / am affiliated with Asset Track Pro" near the end, and it keeps you on the right side of their guidelines.
Make it yours: the strongest DEV posts include something from real experience, such as a failure you hit or a tradeoff you made. If you have one, drop it in after the RFID or scale section.
Cover image and tags: I set published: false so you can preview it first.
I can also put this in a .md file, tighten it to a shorter read, or swap the Python for another language if you'd like.
Top comments (0)