DEV Community: Smrati

10 IoT terms every developer encounters in asset tracking — explained simply

Smrati — Wed, 27 May 2026 09:07:26 +0000

From the first exposure to a piece of IoT asset tracking code, you are confronted by the barrage of terms, including MQTT, RTLS, RSSI, geofencing, and digital twin. This piece will provide clear explanations without any buzzwords or technical assumption. It will give practical examples to illustrate your understanding of each term.

01

MQTT
Protocol

An open communication protocol used for devices that have little bandwidth and computing power. All devices in the system broadcast messages on certain topics. The message is received by other connected systems interested in these topics.

Analogy
Imagine a radio station. The GPS tracker acts as the broadcaster. The broker functions as the radio tower, while your back end becomes the listening device on that frequency. The tracker doesn't matter who receives its transmissions as long as it is transmitting.

02

RSSI
Signal

The abbreviation for "Received Signal Strength Indicator". Indicates the strength of wireless signal received at a particular place, measured in dBm (always negative — more towards zero value indicates greater strength). Utilized in BLE indoor positioning technology to gauge the distance between the device and an antenna in a fixed location.

Analogy: Think of someone speaking in the same room. If their voice sounds more prominent, the chances are that they are standing closer to you. RSSI measures the same thing with radio waves.

03

Geofencing
Location

A zone established virtually based on a specific physical location that triggers an action once crossed. An asset that crosses this boundary either while leaving or entering this geofenced location will trigger an action event. There can be circular (based on center point and radius) and polygon geofences.

Analogy: You may draw a line on a map with a marker to represent your warehouse boundaries. Geofencing represents this line digitally — but invisibly and it notifies you instantly once anything enters this invisible zone.

04

Digital Twin
Architecture

It is an instance of a physical asset in a virtual world — that is, a digital entity which represents the exact current state of your physical asset through your backend system. Location, temperature, battery life, and status — everything gets updated as soon as the sensors update data. Your digital twin will always be in sync with your physical asset.

Analogy: The digital twin of your mobile device on the "Find my" app of your smartphone works in the same way, except that instead of a phone, your asset can be something like a fork lift or some medical equipment.

05

RTLS
System

Real-Time Locating System. An infrastructural technology used to track the location of the asset inside a building where global positioning systems cannot operate. Gateways or readers pick up signals from tags fitted on your assets and determine their position using RSSI, Ultra Wideband (UWB), and RFID.

Analogy: While GPS relies on satellites which are outside of the buildings, RTLS replaces the satellites with fixed anchors which can be inside of the building.

06

QoS (Quality of Service)
Protocol

In the MQTT protocol, QoS refers to the efforts that are put in by the broker in delivering the message. QoS 0 = fire and forget (message not guaranteed). QoS 1 = message delivery at least once (possible duplication). QoS 2 = exactly one-time message delivery (slowest but safest). Most asset management systems rely on QoS 1 for location pings and QoS 2 for alerts.

Analogy: QoS 0 – Texting without expecting to hear back (no confirmation of receipt). QoS 1 – Sending a message repeatedly until you are sure the receiver got it. QoS 2 – A registered letter; signed, sealed, and delivered precisely once.

07

Dead Letter Queue (DLQ)
Architecture

This is where the failed attempts at processing the messages end up when no more retries are possible. Rather than deleting the failed IoT messages (and losing the data silently), they are routed to a special queue for debugging purposes.

Analogy: It works just like the dead letter office in a post office; instead of deleting the mail that didn’t reach the receiver, it ends up here where the user can collect it and retry.

08

Edge Computing
Architecture

Processing of information locally in the device itself or at a gateway nearby without routing it to a distant cloud first. When talking about asset tracking, it allows a smart tag to check whether a temperature threshold is violated and to raise an alarm instantly within milliseconds, instead of waiting for the cloud round trip which would take several seconds.

Analogy: As opposed to contacting headquarters each time in order to get an answer to something trivial, edge computing is similar to empowering the people who are on site to be able to make decisions by themselves, leaving only critical cases for the higher-ups.

09

Telemetry
Data

The constant stream of data sent by a particular device to its backend infrastructure. Within the asset tracking domain, the information transmitted consists of location coordinates, sensor readings (temperature, humidity, shock), battery life, and overall health of the device – depending on the frequency of transmission.

Analogy: Telemetry feed of a race car consisting of speed, tyre pressure, fuel level, and engine temperature. Exactly the way your IoT device works, just applied to your assets.

10

Cold Start
Hardware

Time taken by the GPS equipment to initialize and receive a satellite fix from scratch. A cold start may take 30-90 seconds since there are no previous satellites in the device memory. This process is much quicker during a warm start, which takes 5-15 seconds. A hot start will only require a fraction of this time.

Analogy: Think of turning on your map application after being off for one week – it may take some time to determine your location. However, if you simply lock and unlock your device, it would show your location immediately.

Each of these 10 key concepts will pop up all the time once you get started building your asset tracking solution. The good news is that none of them will seem quite as scary at first glance as they do now – each is simply an analogy to something you probably already know about from web application development.

The best way to understand any new set of technology concepts is to see them put into practice – and that means checking out a real asset tracking platform.

AssetTrackPro uses MQTT for its telemetry ingest; RTLS and RSSI for locating assets; geofences for triggering notifications on the digital twin; and even has edge computing capabilities, in addition to everything else covered here. You can find all of that and more on assettrackpro.com.

See all of these concepts in action with AssetTrackPro's production IoT platform.
Learn More About AssetTrackPro ↗

The difference between polling, webhooks, and WebSockets — and when asset tracking uses each

Smrati — Wed, 27 May 2026 08:48:45 +0000

Three methods of data transfer from the server to the client. They're all correct. They're all used in asset tracking systems, though for totally different purposes. Ever wonder which one to choose and why? Here's that article.

The common problem that all of them solve

All patterns of data transmission try to solve one single problem: how does the client know when there's been an update? They're just solving the same problem using different methodologies depending on how frequently updates occur and how quickly they need to be received.

Polling

Client asks server continuously: "anything new?"
Pull Model

Client polls server at a set interval of every 5 seconds, every 30 seconds, or every minute. Server responds with latest information regardless of any change. Easy, dependable, and works anywhere. Inefficient – server wastes processing power returning empty replies because you paid for the call no matter what.

Comparison: Checking your email for new messages by refreshing your inbox every 30 seconds. Effective but inefficient as you waste effort refreshing even when there are no emails to check.

✓ Ideal for situations where

Updates rarely occur (a few times a minute)
Minimal network requirements
Operating behind restrictive firewalls

✗ Difficulties arise when

Frequent data updates occur
Latency is critical
Large scale (10,000 clients polling creates server headaches)

📍 For asset tracking
Not appropriate for live updates — retrieving daily usage reports, pulling maintenance schedules, verifying fleet status from a management dashboard that updates every couple of minutes. Not good for anything that needs to be urgent.

Webhooks

Your server gets called when an event happens
Push-based

You give the server an endpoint URL. The server will send an HTTP POST to your URL whenever the relevant event happens. You don't poll — you just wait for your server to get the event message. Efficient, since it only sends HTTP messages when something interesting has occurred. Requires that your receiving end is publicly reachable and capable of handling HTTP messages.

Comparison: setting up email notifications rather than constantly refreshing your email inbox. No action on your part until you have something to act upon.

✓ Ideal for situations where

Event happens once in a while
When communicating with other services
Event triggers some workflow

✗ Difficulties arise when

Lots of events firing per second
Receiving end does not accept HTTP messages
Two-way communication is required

📍 For asset tracking
Ideal for zone exit alerts, maintenance reminders, threshold violations, and ERP integrations. If a truck leaves a defined area or if a sensor crosses a critical threshold — trigger a webhook to Slack, an ERP, or a paging service. Once-off event, once-off POST action, problem solved.

WebSockets

Continuous two-way communication through an open connection
Two-Way

One persistent TCP connection established between client and server which allows both ends to communicate without requesting another connection. The fastest and most efficient way of communicating — ideal for streaming data. Requires more coding than polling or webhooks but is unparalleled for dashboard purposes.

Comparison: Imagine a phone conversation rather than text messaging where the connection remains open allowing both participants to communicate anytime with no need to establish a new connection each time.

✓ Ideal for situations where

When data updates constantly
Need for less than second latency
Client-side sends data as well

✗ Difficulties arise when

When corporate firewalls block connections that aren’t HTTP
When stateful load balancers aren't available
When updates are rare and connection overhead becomes pointless

📍 For asset tracking
A crucial component of live dashboards – live map with dynamic vehicle pin markers, live sensor data, and live alert feeds. All updates from the IoT devices get passed through WebSockets to live dashboards in just milliseconds.

Comparison

Criterion	Polling	Webhooks	WebSockets
Direction	Client → Server	Server → Client	Both-way communication
Speed (latency)	Poll interval in seconds	Real-time (event-triggered)	response time sub-seconds
Effectiveness	Low (empty results)	win – only triggered by events	High (always connected)
Ease of use	simple	somewhat complex	balanced (more complex)
Firewall friendliness	passes firewall	passes firewall	sometimes firewalled
Ideal for asset tracking	reports	notifications	live dashboards

The interplay of the three together in one system
The best asset tracking solutions don’t choose – they implement all three for distinct purposes:

A full asset tracking communication pipeline

Polling – dashboard polls for summary information about fleet every 5 minutes. Live updates are not required, just a snapshot.
Webhooks – violation of geofence triggers a POST to Slack, ERP, and another custom URL simultaneously. Event-driven, loosely coupled, instant.
Websockets – live ops dashboard displays continuous real-time asset locations, sensor data, and alerts to authenticated users.

Hybrid tip – if you can't use Websockets because of corporate proxy, Server-Sent Events (SSE) is a great alternative to Websockets when it comes to the live dashboard – HTTP, built-in reconnection logic, uni-directional server -> client message protocol, covers almost all use cases of dashboards.

AssetTrackPro utilizes all three approaches in production – Websockets are used for live dashboard functionality, webhooks for integrating alerts into ERP and Slack, and REST APIs for reporting/historical data access. Learn more →

Planning to develop a real-time asset tracking solution? AssetTrackPro’s platform provides WebSocket streaming capabilities, webhook delivery, and APIs for your reports – everything is ready to use out-of-the-box.

Discover AssetTrackPro ↗

How Geofencing Actually Works in Enterprise Asset Tracking

Smrati — Tue, 26 May 2026 17:38:43 +0000

Often geofencing is presented quite simply like this:

"Receive alerts when an asset leaves an area."

This definition isn't incorrect, but it doesn't convey all that much about the complexity of the technology itself.

When using geofencing as part of enterprise asset tracking systems, the process involves not only defining boundaries on the map but also managing movement events, taking automated actions, boosting security, and minimizing any possible blind spots in the process.

Then, how does geofencing really work?

What Is Geofencing?

A geofence represents a virtual boundary set up for some location in reality.

Depending on your use case, this area can be:

Warehouse
Construction site
Distribution center
Office park
Delivery territory
Prohibited area

Each time the asset either enters or leaves this predefined area, an event can take place.

Example:

Alert: Equipment was taken out of the construction site after work time
Notification: Package was delivered to the right destination
Automate: Asset status update
Security: Report about unauthorized movement

However, the virtual boundary needs to be identified first.

Step 1: Collecting Location Data

Geofencing requires collecting data regarding asset location.

Sources may vary depending on your particular use case.

GPS

Popular outdoors.

The devices with GPS technology provide latitude and longitude data, usually at periodic intervals.

Appropriate for:

Vehicle tracking
Construction machines
Cargo containers
Outdoor property

Constraints:

Lower accuracy indoors
Battery usage

BLE (Bluetooth Low Energy)

Utilized indoors.

BLE beacons determine relative distance instead of actual GPS locations.

Applicable to:

Warehouses
Hospitals
Manufacturing plants

RFID

Unlike GPS, RFID does not track locations constantly but identifies when items cross certain checkpoints.

Applicable to:

Inventory movement
Entrance/exit tracking
Wi-Fi or RTLS

Most companies employ RTLS for indoor positioning purposes.

These devices use several signals to calculate an estimated location.

Each environment has unique needs in terms of tracking technology.

Which is the reason why GPS is seldom utilized as a sole tracker for enterprise assets.

Step 2: Comparing the Position to Geofences

After receiving location data, the software will check if:

Is that asset inside the pre-set zone?

Essentially, the process entails:

Comparing the coordinates of the asset in question
To stored geofence coordinates

If the position moves across the border:

Event triggered

Such events will log:

Date/time
Location
Identification of the item
Moving direction (entrance/exit)

The result will become part of the asset's motion history.

Step 3: Automated Actions Initiated by Geofences

The main advantage of geofencing lies in automation, not detection.

Examples of actions performed:

Security Monitoring

In case the expensive equipment moves out of the building:

→ Alerts sent instantly

Inventory Management

Upon the arrival of shipments into warehouses:

→ Update status automatically

Workflows for Maintenance

In case assets enter maintenance areas:

→ Activate inspection tasks

Compliance

Some business sectors need proof of asset location and timing information. Geofences allow to generate audit logs. Without automation, geofencing will remain just another notifications solution. Automation transforms it into a workflow generator.

Why Geofencing Is Important Besides Anti-theft Purposes

People tend to associate geofencing with theft prevention alone.

However, a large number of companies employ it to find answers to operational questions:

Why do our assets spend much time at some locations?
Which routes are responsible for delays?
How often are our assets moving between different locations?
Where is our inefficiency?

Motion information becomes operational insights.

The Future: Geofencing + Predictive Analytics

The combination of geofencing with lifecycle intelligence is becoming commonplace in modern asset tracking solutions.

Whereas traditional systems focused on answering such question as:

“Where is my asset right now?”

New platforms enable you to analyze your motion data:

"What is the meaning of this particular pattern of movement?"

This turns geofencing into a business analysis solution.

Solutions like AssetTrackPro offer you the possibility to integrate geofencing and overall asset visualization capabilities.

Because, within corporate environments, it is important not only to know where an asset is but also to understand why.

What Happens to Asset Data After Collection? A Look at Lifecycle Intelligence

Smrati — Tue, 26 May 2026 17:17:58 +0000

Asset tracking tends to be condensed down to one single question:

"Where is my asset?"

But mere location is just a first step.

True value arises from the collection of data and then its transformation by organizations into insights around maintenance, utilization, lifecycle management, and potential risks. It is a stage which modern businesses refer to as lifecycle intelligence.

Data Collection vs Insight Generation

Modern tracking devices gather asset information non-stop:

Location
Number of uses
Environmental factors
History of maintenance procedures
Movement patterns
Records of ownership
Performance metrics

Alone, these figures are not very informative.

But combined, they form certain patterns.

For instance, assets that have recently been used more often than usual while their maintenance history has been deferred may signal increased risk of malfunctioning. Similarly, equipment moving across several locations too frequently might point at misuse.

The objective here is not merely collecting data.

The objective is predicting future events.

Why Predictive Maintenance Makes a Difference

Classical maintenance is done based on set time periods:

Check equipment each six months. Replace equipment after X number of years.

In contrast, predictive maintenance utilizes the asset telemetry as well as the history of the maintenance process to determine when the procedure is really necessary.

This results in:

Downtime avoidance
Over-maintenance savings
Early replacement prevention
Efficiency improvements

Servicing too soon is inefficient while servicing too late increases risk of malfunction.

The key here is striking a balance between servicing and downtime through asset lifecycle intelligence.

Asset Data Can Identify Underutilization Too

Sometimes, one of the biggest issues is not utilization at all – but underutilization.

Many companies acquire new equipment due to perceptions of shortages, even if current assets are sitting idly on shelves.

Lifecycle analytics can pinpoint:

Underutilized assets
Overworked equipment
Redundant purchases
Trends towards underutilization

Often, just being aware can result in cost savings before any unnecessary acquisitions take place.

Beyond Asset Management: Building a More Intelligent Operation

The development of asset management moves beyond:

Tracking → Monitoring → Predicting → Optimization

More organizations want their asset management systems to be able to:

Which equipment will most likely fail in the next quarter?
Which pieces of equipment are overcosting our organization?
Which maintenance schedule needs to be adjusted?
Are there new efficiencies we can optimize for?

These answers aren’t based on mere data – they're based on intelligence.

Tools like AssetTrackPro have been built with this holistic approach in mind – bringing together tracking, analytics, and lifecycle intelligence within one platform.

Since data collection is no longer the hard part.

How to Implement OTA Firmware Updates for IoT Asset Tracking Devices

Smrati — Mon, 25 May 2026 15:24:40 +0000

Distribution of firmware updates to thousands of GPS trackers and BLE beacons installed in warehouses, vehicles, and installations is a very difficult aspect of operations in IoT solutions. Do it wrong, and you brick the devices in the field. Do it right, and you deliver new features, security patches, and other improvements to all your fleet while they continue working normally. This is how it works in detail.

Why OTA updates are mandatory once you have a fleet

Once you deploy several dozen of IoT devices in the field, manual updates become impossible from an operational perspective. Imagine manually updating a fleet of 500 GPS trackers located in 10 different sites in the field – it will take you weeks. During those weeks your fleet will be running with different versions of firmware, exhibiting inconsistent behavior and being vulnerable to security threats.

OTA updates solve this problem by sending a firmware update to the device over the air through its connection. This could be either MQTT, cellular connection, WiFi or even LoRaWAN connections.

OTA update process – Four steps for safety

📦Package
Create, sign, and version the firmware binary. Distribute over CDN with a checksum.

📡Notify
Inform the device about availability of a newer version using MQTT protocol. The device verifies its eligibility to receive an update.

⬇️Download and verify
Downloads the binary in chunks and verifies the SHA-256 hash and digital signature.

🔄Apply and rollback
Applies the update by flashing the firmware binary to the inactive partition. Boots to the new firmware version. Performs a rollback if health-check fails.

Dual-partition design (A/B)

The safest OTA update pattern includes two partitions, one which contains the active version of firmware while the other is used to store the new firmware version. This is referred to as the inactive partition.

Step 1
Device runs from Partition A
Normal operation. Partition B is empty or holds the previous version.

Step 2
OTA notification received
Device downloads new firmware into Partition B in chunks, verifies hash on completion.

Step 3
Reboot into Partition B
Bootloader switches boot target to Partition B. Device boots new firmware.

Step 4a
Health check passes → commit
Device reports successful boot. Partition B becomes the new active partition.

Step 4b
Health check fails → rollback
Bootloader detects failed boot attempts. Reverts to Partition A automatically. Device stays online.

Step 1 - Back End: Server and notify

OTA back end will do two things: server and notify the eligible devices. Notify using MQTT: devices have a persistent connection anyways:

// Node.js OTA notification — push to eligible devices via MQTT
async function pushOTANotification(firmwareVersion, targetFleet) {
  const payload = {
    version: firmwareVersion,
    url: `https://cdn.yourdomain.com/firmware/${firmwareVersion}.bin`,
    sha256: await getFileHash(firmwareVersion),
    size: await getFileSize(firmwareVersion),
    releaseNotes: 'Fix GPS drift bug + improved cold start'
  }

  // Publish to fleet topic — only devices in targetFleet receive it
  await mqttClient.publish(
    `fleet/${targetFleet}/ota/available`,
    JSON.stringify(payload),
    { qos: 1, retain: true }  // retain so offline devices get it on reconnect
  )
}

Step 2 - Device: Receive & Download

At the device level, subscribing to OTA topic and performing updates on Python (Raspberry Pi tracker):

import hashlib, requests, json
import paho.mqtt.client as mqtt

CURRENT_VERSION = '1.4.2'
FIRMWARE_PATH = '/firmware/update.bin'

def on_ota_message(client, userdata, msg):
  update = json.loads(msg.payload)

  # Skip if already on this version
  if update['version'] == CURRENT_VERSION:
    return

  # Download firmware in chunks
  print(f"Downloading firmware {update['version']}...")
  r = requests.get(update['url'], stream=True)
  with open(FIRMWARE_PATH, 'wb') as f:
    for chunk in r.iter_content(4096):
      f.write(chunk)

# Verify SHA-256 hash before applying
  if not verify_hash(FIRMWARE_PATH, update['sha256']):
    report_failure(client, 'HASH_MISMATCH')
    return

  # Hash verified — apply and reboot
  apply_firmware()

def verify_hash(path, expected):
  sha256 = hashlib.sha256()
  with open(path, 'rb') as f:
    for chunk in iter(lambda: f.read(4096), b''):
      sha256.update(chunk)
  return sha256.hexdigest() == expected

Step 3 - Sign firmware for security purposes

Hash verification for the purpose of corruption detection and signature verification for preventing malicious updates. Only your signed firmware can be updated:

# Build pipeline — sign firmware binary before uploading
# Generate signing key (once, store private key securely in CI secrets)
openssl genrsa -out firmware_signing.key 4096
openssl rsa -in firmware_signing.key -pubout -out firmware_signing.pub

# Sign the firmware binary
openssl dgst -sha256 -sign firmware_signing.key \
  -out firmware_v1.5.0.bin.sig firmware_v1.5.0.bin

# On device — verify signature before applying
openssl dgst -sha256 -verify firmware_signing.pub \
  -signature firmware_v1.5.0.bin.sig firmware_v1.5.0.bin

Step 4 - Health checks and Rollback mechanism

Once the device reboots into the new firmware, it needs to send out a successful health check message within the time limit. Otherwise, the bootloader will roll back to its old state, in case the new firmware doesn't work (causes crashes, can't connect):

// Post-boot health check — report to backend within 60 seconds
async function postBootHealthCheck() {
  const checks = {
    mqttConnected: await checkMQTTConnection(),
    gpsLock: await checkGPSLock(),
    sensorReadings: await checkSensors(),
    memoryOk: process.memoryUsage().heapUsed < 50_000_000
  }

  const passed = Object.values(checks).every(Boolean)

  // Report result to backend
  mqttClient.publish(`devices/${DEVICE_ID}/ota/status`, JSON.stringify({
    version: CURRENT_VERSION,
    status: passed ? 'SUCCESS' : 'FAILED',
    checks,
    ts: new Date().toISOString()
  }))

  // If failed — trigger rollback to previous partition
  if (!passed) triggerRollback()
}

Never do OTAs across all your fleet simultaneously; otherwise, if something goes wrong and a whole 10,000 devices get bricked, it's an unrecoverable scenario. Use staged rollouts from 1% → 10% → 50% → 100%, confirming health check after each step.

Staged rollout strategy

// Staged rollout controller
const ROLLOUT_STAGES = [
  { percent: 1,  waitHours: 2,  label: 'canary' },
  { percent: 10, waitHours: 12, label: 'early' },
  { percent: 50, waitHours: 24, label: 'majority' },
  { percent: 100,waitHours: 0,  label: 'full' }
]

async function runStagedRollout(version, fleet) {
  for (const stage of ROLLOUT_STAGES) {
    const devices = sampleFleet(fleet, stage.percent)
    await pushOTAToDevices(devices, version)

    // Wait and check success rate before next stage
    await sleep(stage.waitHours * 3600000)
    const successRate = await getSuccessRate(version, devices)

    if (successRate < 0.95) {
      // Less than 95% success — halt and investigate
      await haltRollout(version)
      throw new Error(`Rollout halted at ${stage.label} — success rate: ${successRate}`)
    }
  }
}

Scheduling Tip: Schedule OTA pushes in a known period of low activity for your fleet - nighttime for warehouses devices, off shift time for manufacturing. Do not schedule pushes at peak operational time since rebooting cycles costs are much higher then.

OTA Safety Checklist

✓ Dual partition (A/B) - update image flashed to inactive partition, rollback is possible at any moment
✓ SHA-256 hash check - do verification before flashing, reject corrupt images
✓ Cryptographic signature - use RSA/ECDSA and keep secret keys in CI system secrets only
✓ Auto-rollback on health check failed in timeout
✓ Staged deployment: canary -> 10% -> 50% -> 100% with success rates controls
✓ MQTT message retain - device receives push even if disconnects during OTA push
✓ Version pinning - the ability to push update for particular device or fleet by specified version number
✓ Update logs - keep record of update process for every single device firmware
✗ NEVER push update to whole fleet at once - one bad update can brick thousands of units
✗ NEVER ignore hash verification - data integrity problems during download happens way more often than you think on cellular

Recommended stack

MQTT (Mosquitto)
AWS S3 / Cloudflare R2
Node.js backend
Python (device)
OpenSSL (signing)
PostgreSQL (audit log)

When it comes to large-scale OTA that is managed for you, AWS IoT Jobs or Azure IoT Hub take care of all the orchestration of the OTA process. If you’re hosting your own systems, the above combination is sufficient to support OTA to thousands of devices.

Our own IoT device fleet uses the dual-partition OTA model, rolling out to our GPS and Bluetooth Low Energy tracking devices using a fully automated process where we don’t have to touch any of the devices in the field manually. Check out our platform →

Are you working with a device fleet of IoT trackers? Then AssetTrackPro will provide you with OTA functionality, device management, and firmware updates. Discover AssetTrackPro →

BLE Indoor Positioning: How RSSI Trilateration Works (With Math and Code)

Smrati — Mon, 25 May 2026 15:02:43 +0000

RSSI and distance

Each BLE beacon sends out a signal which is picked up by fixed points and then the strength of the signal measured, which gives the Received Signal Strength Indicator (RSSI), measured in dBm. Higher strength means higher proximity. According to the Log-Distance Path Loss Equation:
d = 10 ^ ((TxPower − RSSI) / (10 × n))
Where:

d = Distance in metres
TxPower = RSSI at 1 m (usually calibrated, around −59 to −65 dBm)
RSSI = current RSSI in dBm
n = path loss exponent (typically 2.0 for free space, 2.5 to 4.0 indoors)

function rssiToDistance(rssi, txPower = -59, n = 2.5) {
  if (rssi === 0) return -1
  const ratio = (txPower - rssi) / (10 * n)
  return Math.pow(10, ratio)
}

rssiToDistance(-59) // → ~1.0m
rssiToDistance(-70) // → ~3.5m
rssiToDistance(-85) // → ~14m

⚠️ RSSI is noisy. A single reading varies ±10 dBm from interference. Never feed raw RSSI into trilateration — smooth first with a Kalman filter.

class KalmanFilter {
  constructor(R = 0.125, Q = 0.5) {
    this.R = R; this.Q = Q
    this.x = null; this.P = 1
  }
  filter(z) {
    if (this.x === null) { this.x = z; return z }
    const K = this.P / (this.P + this.R)
    this.x = this.x + K * (z - this.x)
    this.P = (1 - K) * this.P + this.Q
    return this.x
  }
}

// One filter per anchor per tag
const filter = new KalmanFilter()
const distance = rssiToDistance(filter.filter(rawRssi))

Trilateration — the math

With distances from 3+ anchors at known positions, solve:
(x − x₁)² + (y − y₁)² = d₁²
(x − x₂)² + (y − y₂)² = d₂²
(x − x₃)² + (y − y₃)² = d₃²
Subtract equation 1 from equations 2 and 3 → eliminates x² and y² → two linear equations → solve for x and y.

Full implementation

const anchors = [
  { id: 'A1', x: 0,  y: 0 },
  { id: 'A2', x: 10, y: 0 },
  { id: 'A3', x: 5,  y: 8 },
  { id: 'A4', x: 0,  y: 8 },
]

function trilaterate(anchors, distances) {
  const ref = anchors[0]
  const A = [], b = []

  for (let i = 1; i < anchors.length; i++) {
    const a = anchors[i]
    A.push([2*(a.x-ref.x), 2*(a.y-ref.y)])
    b.push(
      distances[i]**2 - distances[0]**2
      - a.x**2 + ref.x**2
      - a.y**2 + ref.y**2
    )
  }
  const [x, y] = leastSquares(A, b)
  return { x: Math.round(x*100)/100, y: Math.round(y*100)/100 }
}

function leastSquares(A, b) {
  let AtA = [[0,0],[0,0]], Atb = [0,0]
  for (let i = 0; i < A.length; i++) {
    const [a0,a1] = A[i]
    AtA[0][0]+=a0*a0; AtA[0][1]+=a0*a1
    AtA[1][0]+=a1*a0; AtA[1][1]+=a1*a1
    Atb[0]+=a0*b[i];  Atb[1]+=a1*b[i]
  }
  const det = AtA[0][0]*AtA[1][1] - AtA[0][1]*AtA[1][0]
  return [
    (AtA[1][1]*Atb[0] - AtA[0][1]*Atb[1]) / det,
    (AtA[0][0]*Atb[1] - AtA[1][0]*Atb[0]) / det
  ]
}

Real World Accuracy

Environment	Path Loss n	Accuracy	Notes
Open Office	2.0 - 2.5	1 – 2m	Best conditions
Warehouse	2.5 – 3.0	2 – 4m	Metal shelving multipath
Hospital	3.0 – 3.5	2 – 5m	Lots of dense walls, equipment
Manufacturing	3.0 – 4.0	3 – 6m	Heavier machinery, RF-dense

Tip for Calibration: calibrate txPower individually at each anchor point in your environment. Stand 1m away, take 100 RSSI samples. Calibration increases accuracy by 30-40% over manufacture default values.

What to Build on Top

Place the trilaterated coordinate system onto a SVG floor plan – correlate the meters from the real world to pixels using scale factor. Asset pin locations are updated based on incoming RSSI coordinates received via Server-Sent Events or WebSocket.

AssetTrackPro's BLE indoor positioning technology is based on calibrated RSSI trilateration + Kalman Filtering, delivering accurate positions

Explore AssetTrackPro ↗

Why your warehouse is losing money you can’t see on any report

Smrati — Fri, 22 May 2026 14:52:05 +0000

Why is Financial Loss in Warehousing Not Recognized by Traditional Accounting?

While the profit and loss account seems good enough, and the operations staff is actively involved, money is slowly slipping away from the business in the time interval between these two events.

The warehousing managers understand the problem of shrinkage, damaged products, and delayed shipments. The problem leads to an investigation, process adjustment, and changes in the accounting data.

On the contrary, there are losses that are not measured; in other words, if one does not measure these losses, their number will only increase over the years. Such losses will not appear in any row of the balance sheet and continue to exist due to the difference between theoretical and real performance of the business.

These are the places where the financial leakage occurs.

The Five Invisible Drains

01
Unproductive Equipment Unmonitored

In regular warehousing procedures, equipment usage averages between 60–70%, which means that the leftover percentage of equipment remains unutilized at the warehouse site. Otherwise, there could be extra costs associated with the rental of the forklifts and the pallet jacks due to the lack of tracking. Owned equipment is simply idle in a specific bay of the company such as bay #7. Lack of tracking hampers any improvement processes since the purchases are done based on hearsay.

02
Hours Spent by Employees Looking Instead of Working

According to some research studies, employees waste about 1–2 hours daily on the search for equipment and tools in warehouses that do not use real-time tracking. In a workforce of 50 people, up to 100 hours daily will be lost. This cost is not shown as an expense but is manifested as busyness among the staff.

03
Cost of carrying inventory because it cannot be located

When inventory cannot be located immediately, the default procedure is to reorder it. This way, there will be two identical items: located and ordered one, hence, double spending on it. The first item will become accessible, become overstocked, and will either be stored or written down. Phantom inventory ordering is one of the most popular and undertracked sources of losses in medium-scale warehouse businesses.

04
Reacting to problems that could have been predicted

If an unexpected stoppage occurs on a conveyor belt, then the cost does not include only the expense of repairs but also the loss of every hour of disruption — undelivered orders, trucks waiting, and labor wasted. Reaction to problems is three times more costly than preventive maintenance. Without usage meters, preventive maintenance can only happen either calendar or reactionary.

05
Inefficient cycle counting, causing production time loss

To conduct a full cycle inventory count can take up to 2–5 days when it comes to a big warehouse, which causes significant downtime. Thus, many warehouses decide to conduct such a count once a quarter or once a year because of the disruption it causes. With continuous monitoring, this count can be done routinely, and inventory will always be visible.

The biggest expenses incurred in a warehouse aren’t the ones listed on any official report; instead, they’re the ones that go unseen.

Why are these losses invisible?

The underlying issue with them not being reported in the first place is very simple: Reporting is based on measurement. Hours worked are not recorded as “time spent looking for a pallet jack.” Costs associated with reordering products are not reported as “phantom inventory.” Repair bills don’t differentiate between repairs that could have been prevented and repairs that were inevitable.

Therefore, the income statement can reflect a realistic picture of how well or poorly the company is doing financially while completely ignoring an entire category of operational loss. Financial experts will see the numbers and think they make sense, while the operations department sees problems constantly cropping up, yet nobody sees the need to analyze the situation because there are no integrative processes in place to identify the cause-and-effect relationships.

In other words, real-time visibility into assets doesn’t just reduce the losses but allows them to be seen for what they are so that steps can be taken to address them.

What happens when you can see it all

Warehouses that can monitor assets in real time see gains in all five areas: utilization rates increase as idle equipment is reallocated, labour hours are moved from searching to productive work, reorder decisions are made using actual inventory data, maintenance is planned instead of reactive, and cycle counts are reduced from days to hours.

The compounding effect is what counts. If a warehouse gains just 30 minutes per worker per day, across a team of 50 people, it gains 25 hours of productive labour weekly — the equivalent of one full-time employee’s work, every week, forever. That was never listed as a cost on any report. It won’t show up as a saving either, unless you start measuring it.

AssetTrackPro enables warehouse and logistics operations to build real-time asset visibility from the ground up. RFID, BLE and IoT sensor based tracking that converts invisible losses into measurable, fixable numbers. How it works ->

Where to begin

Choose any one of the five drains above, whichever takes your fancy, and spend a fortnight measuring it by hand. Count the hours, record the incidents, monitor the reorders. No matter what number you come up with, it is almost certainly larger than you think. That is your business case. So build the tracking system around closing that gap first and then grow from there.

There have always been losses. Now you know where to find it.

Ready to find out what your warehouse is really losing? AssetTrackPro develops real-time tracking systems for warehouses and distribution centers, beginning with the metrics that matter most for your operations.
> Learn more about AssetTrackPro

WebSockets vs Server-Sent Events: which is better for live asset dashboards?

Smrati — Fri, 22 May 2026 14:40:33 +0000

Both technologies transfer real-time data to your browser; both work great. However, when it comes to developing dashboards for tracking assets in real time, which is constantly receiving data from thousands of devices and where there is only one direction of data flow, the decision should be made wisely. Here is an overview of both.

Functionality of each technology

WebSockets

Full-duplex persistent connection
One TCP connection which is opened both ways. Data exchange between client and server is possible anytime. Protocol upgrade over HTTP at the very beginning of connection; then works independently.

Bidirectional
Binary or text
Custom protocol

SSE

One-directional HTTP event stream
HTTP connection is kept open, but there is only the server pushing the events to the client. Client can not send data to the server over this connection, but sends HTTP requests instead.

Server -> client only
Text only
HTTP-native

Comparing Asset Dashboards

Feature	WebSockets	SSE
Message direction	Bidirectional — greater flexibility	Single-direction (Server to Client)
Overhead	Larger overhead due to framing (2–14 bytes per message)	Small HTTP overhead (~100 bytes) one-time
Auto-reconnect	Manual configuration needed	Built-in browser functionality — automatic
Firewalls/proxies	May not work through proxies	Equivalent to standard HTTP — guaranteed
Load balancing	Needs sticky session support	Browser does the job well
Support for binary data	Native support	Basic support — no binary messages
Browser compatibility	All browsers	All browsers except IE
Server implementation	difficult — stateful sessions	easy — standard HTTP handlers gains

Implementing SSE – asset location stream

SSE is vastly easier to implement compared to WebSockets for read-only dashboards. Here's how to create an SSE stream on Node.js, where we emit events as assets are updated by our Redis service:

// Node.js SSE endpoint — streams live asset state
app.get('/stream/assets', async (req, res) => {
  // SSE headers — keep connection open
  res.setHeader('Content-Type', 'text/event-stream')
  res.setHeader('Cache-Control', 'no-cache')
  res.setHeader('Connection', 'keep-alive')
  res.flushHeaders()

  // Subscribe to Redis pub/sub channel
  const sub = redis.duplicate()
  await sub.subscribe('asset-updates', (msg) => {
    res.write(`data: ${msg}\n\n`)  // SSE format: data: {json}\n\n
  })

  // Cleanup on client disconnect
  req.on('close', () => sub.unsubscribe())
})

And here's the same stream in action on the client side in React:

// React — consuming SSE asset stream
const [assets, setAssets] = useState({})

useEffect(() => {
  const source = new EventSource('/stream/assets')

  source.onmessage = (e) => {
    const asset = JSON.parse(e.data)
    setAssets(prev => ({ ...prev, [asset.id]: asset }))
  }

  // Browser auto-reconnects on disconnect — no code needed
  return () => source.close()
}, [])

WebSockets implementation

– when two-way communication is needed

When your read-only dashboard starts sending requests – panning, zooming a map, requesting asset groups, firing events – you start needing the full WebSockets setup. Here it is on the server and client sides:

// Node.js WebSocket server with selective subscriptions
const { WebSocketServer } = require('ws')
const wss = new WebSocketServer({ port: 8080 })

wss.on('connection', (ws) => {
  let subscribedFleets = []

  // Client tells server which fleets to subscribe to
  ws.on('message', (msg) => {
    const { action, fleets } = JSON.parse(msg)
    if (action === 'subscribe') subscribedFleets = fleets
  })

  // Push updates only for subscribed fleets
  const interval = setInterval(async () => {
    const updates = await getFleetUpdates(subscribedFleets)
    if (ws.readyState === WebSocket.OPEN) {
      ws.send(JSON.stringify(updates))
    }
  }, 1000)

  ws.on('close', () => clearInterval(interval))
})

SSE reconnection tip: When reconnecting after a network outage, the browser will attempt reconnect using the same EventSource instance – and pass the Last-Event-ID request header containing the most recent event ID number. Use it on your backend to fetch missed events from your cache and close potential gaps in data streams between reconnects. Just add id: {eventId}\n to each SSE event.

The asset dashboard-specific answer

With a normal asset tracking dashboard that consists of a live mapping display, location pins for each tracked asset, statuses, alert feed – almost all data transfer is from server to client. The server receives the updates to asset locations via IoT events, and these get consumed by the dashboard that displays them to the user.

A classic scenario for Server-Sent Events. Built-in reconnect functionality. Regular HTTP load balancer support. No need for sticky sessions. No custom protocol required. Way simpler server-side logic compared to keeping thousands of stateful WebSocket connections.

WebSockets become a necessity once you introduce interactivity into the picture - filtering data on behalf of the users, issuing commands for selected assets, displaying alerts based on the user's roles. For data display purposes, SSE beats WebSockets hands down, but for user interaction, the latter is better suited.

Fast guide to decision making

Map, board, alerts with read-only interface → SSE
Easier deployment with no proxies involved → SSE
Auto-reconnect without developing anything yourself → SSE
User sending commands and subscribing to feeds → WebSockets
Binary data transfer required or chat-like interactions → WebSockets
Dashboard doing read/write operations → SSE for stream, REST for control

Preferred Stack

Node.js / Express
EventSource API
ws (WebSockets)
Redis pub/sub
React + useState

The most practical approach for most asset dashboards is SSE for the live data stream plus REST POST for all user-driven actions. You have the easy approach of SSE for 95% of the use cases, while REST allows for sending any data to the server in the 5% of actions that require such actions.

AssetTrackPro’s live dashboard follows a SSE-first approach to handle asset location streaming with WebSockets acting as the secondary approach for fleet management.
Check out the live asset dashboard of AssetTrackPro →

Building your own live asset dashboard? With AssetTrackPro’s solution, you just focus on building the user interface, not setting up the infrastructure.

Discover more about AssetTrackPro →

The ROI of smart asset tracking: what businesses in logistics are getting wrong

Smrati — Thu, 21 May 2026 13:12:44 +0000

Most businesses tend to measure the wrong metrics — hence their confusion and inability to achieve satisfactory results.

When logistics firms invest in smart asset tracking technology, they have one goal in mind: stopping their losses. Sure enough, they will succeed in doing that — but that’s not where the biggest ROI is. Most businesses tend to miss out on the bigger picture by focusing solely on asset recovery metrics.

Here’s the discussion you need to have regarding ROI calculation, and what most business leaders get wrong.

The three ways in which you fail to calculate your ROI

01
Calculating only the return on asset recovery

Recovery is quantifiable and tangible. However, greater value lies in hours of labor recovery, lower maintenance costs, and reduced billing times, which don’t appear in a mere “recovered assets” tally.

02
Overlooking utilization information

Fleet operations average utilization of 60–70%. Tracking allows you to know which assets are underutilized, which are overloaded, and which assets you’re renting when you already have them, making the tracking system’s cost exceed its price tag.

03
Neglecting the savings in subsequent time

The hours saved by dispatchers, warehouse supervisors, and drivers not looking for assets multiply quickly. A ten-person operations team saving thirty minutes a day is equivalent to recovering twenty-five hours weekly.

Where the real money is made

The logistics companies maximizing the use of smart tracking technology have the following KPIs in place: asset utilization ratio, maintenance expenses per asset, dwell time at each point, and invoicing precision. Once the assets are tracked from pick-up through delivery, disputes on invoicing virtually disappear — and this factor alone helps to recoup thousands of dollars monthly for even mid-sized fleet owners.

Another underestimated approach to maximizing profitability is predictive maintenance. By having sensors continuously monitoring usage hours and environmental factors, maintenance becomes an issue of scheduling instead of emergency repairs. The industry standard ratio between emergency repair vs. preventive maintenance costs is 3:1.

How AssetTrackPro does it differently: Unlike other tracking solutions providers who sell generic trackers, AssetTrackPro develops customized end-to-end IoT tracking systems for logistics, manufacturing, and healthcare facilities. Its implementations focus on delivering tangible results starting Day One, rather than merely installing tracking hardware.

The right way to make your business case

Before committing to any tracking solution, create a list of the top five pain points in your operations, including financial estimates. Asset loss may be third on your list. The first two are likely tied to underutilized assets or unexpected equipment downtime. Base your business case on that list, rather than on a vendor’s marketing materials.

The logistics companies that are seeing ROI from their smart tracking solutions are not the ones using the fanciest technology. They are the ones who openly admitted to their financial losses and measured accordingly.

Looking to achieve ROI with your asset tracking solution? AssetTrackPro helps logistics and manufacturing facilities across North America deploy tracking solutions based on measurable business results.
Visit AssetTrackPro ↗

How to design a fault-tolerant IoT data pipeline for asset tracking at scale

Smrati — Thu, 21 May 2026 13:02:15 +0000

A pipeline that is designed to work with 100 devices is not a pipeline that can work with 10,000 devices. Furthermore, a pipeline that works on Tuesday morning is not a pipeline that works in a case of network disruption, database failover, or MQTT broker crash. Fault tolerance should be taken into consideration when developing the architecture. Here’s how.

Failure modes to take into account while designing fault tolerant infrastructure

Loss of device connection
Devices lose network connections because of network disruptions. The data has to be buffered and then replayed upon connection restoration.

Crash of a broker
Restarting an MQTT broker during processing. Persistent sessions and Quality-of-Service levels 1 & 2 provide the solution to this issue.

Lagging consumer
Processing is delayed by various reasons. In the absence of a backpressure mechanism, the pipeline will stop working due to increasing pressure.

Database failure
The failover process occurs while writing events. Absence of a retry mechanism will cause event loss forever.

The fault-tolerant pipeline architecture

Layer 1
Device-side local buffer

Tags cache events when disconnected. Events cached will be replayed sequentially prior to new events being sent. No data loss occurs when there is no network connectivity.

Layer 2
MQTT with persistent sessions & QoS = 1

Persistent sessions preserve broker session state upon disconnection. QoS 1 provides at-least-once guarantee, meaning broker retries till an acknowledgement from the device is received. No message drops happen silently.

Layer 3
Kafka with replication & DLQ

Event writes into Kafka with replication factor three. If any event fails to be processed, the event is sent to the DLQ - no data gets lost here.

Layer 4
Idempotent consumers with retry

Idempotent consumers handle events exactly once with help of deduplication keys. If writing to database fails, exponential backoff is used to retry. Nothing gets silently dropped or duplicated.

Layer 5
TimescaleDB with read replicas

All writes happen to the primary DB. Reads and dashboard are served by read replicas. The primary DB failing does not affect the running dashboard due to read replica.

Step 1 – Buffering on Device Side

Buffer the events locally in the device (Raspberry Pi, or embedded MCU), in case of broker unavailability, and send them back to the broker on reconnect:

# Python device client with local SQLite buffer
import sqlite3, json, paho.mqtt.client as mqtt

db = sqlite3.connect('buffer.db')
db.execute('CREATE TABLE IF NOT EXISTS queue (id INTEGER PRIMARY KEY, payload TEXT, ts REAL)')

def buffer_event(payload):
  db.execute('INSERT INTO queue (payload, ts) VALUES (?, ?)', [json.dumps(payload), time()])
  db.commit()

def flush_buffer(client):
  rows = db.execute('SELECT id, payload FROM queue ORDER BY ts ASC').fetchall()
  for row_id, payload in rows:
    result = client.publish('assets/+/telemetry', payload, qos=1)
    if result.rc == mqtt.MQTT_ERR_SUCCESS:
      db.execute('DELETE FROM queue WHERE id = ?', [row_id])
  db.commit()

Step 2 – MQTT Persistent Sessions

Use the clean_session=False broker setting, making sure that the broker buffers unacknowledged messages and sends them back on reconnect:

# Persistent session — broker retains state across disconnects
client = mqtt.Client(
  client_id='asset-tag-7821',
  clean_session=False  # key setting — retain session on reconnect
)
client.reconnect_delay_set(min_delay=1, max_delay=60)

def on_connect(client, userdata, flags, rc):
  if flags['session present']:
    print('Session resumed — broker has queued messages')
  flush_buffer(client)  # replay local buffer on reconnect

Step 3 – Kafka DLQ

Any event that cannot be processed after N attempts lands up in a Kafka DLQ instead of getting dropped altogether. The operations team can then examine, fix, and replay them without losing any data:

const MAX_RETRIES = 3

async function processWithRetry(event, producer) {
  let attempts = 0

  while (attempts < MAX_RETRIES) {
    try {
      await processEvent(event)
      return  // success — exit loop
    } catch (err) {
      attempts++
      const delay = Math.pow(2, attempts) * 1000  // exponential backoff
      await sleep(delay)
    }
  }

  // All retries failed — send to DLQ
  await producer.send({
    topic: 'iot-events-dlq',
    messages: [{ value: JSON.stringify({ event, failedAt: new Date() }) }]
  })
}

Step 4 – Idempotent Writes & Dedupe
Your QoS1 messages will lead to duplicate messages. Therefore, your write calls need to be idempotent; i.e., the same message processed twice needs to give you the same output, no duplicates:

-- Idempotent insert using ON CONFLICT DO NOTHING
-- event_id is a hash of (asset_id + timestamp)
INSERT INTO asset_locations
  (event_id, asset_id, lat, lng, temp_c, time)
VALUES
  ($1, $2, $3, $4, $5, $6)
ON CONFLICT (event_id) DO NOTHING;

-- Generate event_id in application layer
-- const eventId = crypto.createHash('sha256')
-- .update(`${assetId}:${timestamp}`).digest('hex')

Tip for deduplication window: When you have assets that update every few seconds and produce events continuously, cache latest event_ids in Redis with 60 sec TTL to avoid database look-up for deduplication on each insert operation. You can use Redis SET NX command to do sub-millisecond deduplication checks.

Production Fault Tolerance Checklist

✓ Device local buffer: SQLite or Flash-based storage; will replay events when reconnecting in order.
✓ MQTT sessions with clean_session=False, and minimum QoS 1.
✓ Kafka replication factor = 3. Survives single broker failure with zero messages lost.
✓ Dead Letter Queue. Failed events are captured, inspectable and re-playable.
✓ Exponential back-off during retries to avoid thundering herd effect.
✓ Idempotent database writes ON CONFLICT DO NOTHING. Deduplicate by event_id
✓ Read Replicas for dashboards. Write and read paths don’t interfere with each other
✓ Health Checks and alerts: Consumer lag, DLQ depth, and broker health are always monitored.

The most frequent mistake: Implementing retry mechanism without implementing idempotent writes. Retry mechanism without idempotence turns transient error into duplicate data - a much more difficult problem to solve than the one you've faced before.

Stack recommendations

Mosquitto / HiveMQ
Kafka (RF=3)
KafkaJS / confluent-kafka
Redis (for deduplication)
TimescaleDB & replica
Prometheus & Grafana

Three key metrics to watch for in production: Kafka consumer lag (higher lag means a bottleneck in consumption), DLQ queue size (all messages in here require immediate attention), and MQTT reconnection rates (high numbers mean device connectivity problems). You should set alerts on all three.

The IoT data pipeline of AssetTrackPro is based on this exact fail-proof architecture — device-side buffering, Kafka ingestion, idempotent writes, and DLQ monitoring. Find out more →

Working on your IoT pipeline? Get the reliability and scalability of AssetTrackPro's infrastructure that takes care of everything under the hood, allowing you to focus on product development.

Learn more about AssetTrackPro ↗

From reactive to predictive: how AI-powered asset tracking reduces downtime

Smrati — Wed, 20 May 2026 14:16:48 +0000

Most importantly, the maintenance decision you make too late is also your most expensive maintenance decision.

For most of the era of industrialization, maintenance was an operation that proceeded from a basic model: things break; someone repairs. If you were really advanced, then you might perform preventative maintenance based on a set schedule — you changed your oil every 3,000 miles and inspected the conveyor belt every three months. Not bad but still, ultimately, reactionary.

What artificial intelligence-based asset monitoring offers is the ability to shift this paradigm completely — which neither calendars nor Excel sheets have ever been able to do, because they require pre-planning.

Reactive maintenance versus predictive: what’s really different

Reactive maintenance

You know when it breaks
Unexpected failure occurs
Spontaneous downtime and emergency maintenance
Scrambling for replacement parts and stopping production
Guesses made about the root of the issue

Predictive maintenance

You know before it breaks
Anomalies detected weeks in advance
Maintenance planned for convenient times
Parts obtained before needed
Exact chain of events documented

Transforming Tracking Data into Predictions through AI

1
Collecting continuous sensor data

IoT tags provide data on vibration, temperature, runtime hours, pressure, current load, from each and every asset in real-time — not sporadic checks but constant data flow to establish operational history for each machine.

2
Creating a baseline

AI-based models learn normal operational patterns for each individual asset and create the corresponding baseline, which takes into account the specifics of its work at hand — it learns the unique characteristics of your 7-year-old conveyor motor, not your factory’s standards.

3
Detecting anomalies

Once sensor values deviate from those recorded during baseline creation — an insignificant vibration shift or a rise in temperature up by 3°C compared to the norm — it will be detected. Much earlier than a human being.

4
Predicting failure probability

Failure probability and time-to-failure range are assigned for each anomaly, providing maintenance personnel with prioritized assets. So, they know which asset is most likely to fail next — say, an 87% probable versus 12%.

“Predictive maintenance is about more than minimizing downtime; it changes the nature of operations team and machines relationships.”

The numbers which make the business case

30–50% cost savings on maintenance versus reactive approach
70% decrease in equipment failures reported by early adopters
3–5x return on investment on predictive maintenance spend in 18 months
$260K cost of each hour of planned downtime for manufacturers

Most things operation departments get wrong

What’s the common error companies commit trying to go predictive? Looking at it as a tech challenge and not a data challenge. It’s impossible to make sense of any machine learning algorithms with insufficient coverage of sensors and lack of historical data. Applying predictive maintenance on only 20% of your assets will be like summarizing a book without having read it yourself.

The other thing to remember is the people component. Any predictive system would be generating alarms and scores for the operator or maintenance person to react on. What sets apart those who derive maximum value out of the predictive solutions is that they have set up solid alarm management protocols and achieved initial alignment with their maintenance personnel.

AssetTrackPro’s IoT-enabled tracking leverages real-time sensor data with predictive analytics, providing operations teams with failure likelihood metrics, maintenance windows, and asset health dashboards in logistics, manufacturing, and healthcare solutions.

Getting started
You don’t need to install sensors on all your assets from the get-go. You can start with the assets that represent the highest criticality and the highest cost of failure. It is those pieces of equipment where an unplanned downtime will cause the most harm. Collect at least 6–12 months of sensor data on those assets, allow predictive models to create baselines, and assess the results before rolling out further. Predictive maintenance builds up momentum as your history grows.

Are you tired of reactionary management? AssetTrackPro’s IoT tracking systems come with predictive capabilities built-in, allowing your maintenance team to go beyond solving problems and start preventing them.

Learn more about AssetTrackPro ↗

Integrating asset tracking data with ERP systems: a developer's guide

Smrati — Wed, 20 May 2026 14:01:30 +0000

Data for asset tracking in its own silo is valuable. But asset tracking data entering your ERP – updating inventory management data, generating purchase orders, creating maintenance workflows – is truly revolutionary. This is how you can make such an integration without adding to the already heavy maintenance burden.

Why you should consider such integration

Most often asset tracking systems and ERP systems are created independently of each other and serve entirely different goals. Asset tracking systems have information about locations of assets and their condition. ERP systems, in turn, contain all data on cost, ownership, and workflows associated with those assets. Both types of systems complement each other perfectly.

Properly done, such integration makes it possible to automatically reconcile inventory, do usage-based depreciations, generate maintenance workflows, and kick off purchasing processes.

The four touchpoints of integration

Location synchronization

Positioning data being synchronized into ERP inventory management — exact positioning in real time of the asset based on SKU or asset identifier

Maintenance initiation

Thresholds or usage hours automatically initiating a maintenance order on the ERP CMMS module

Inventory sync

Tracking data continuously synchronizing inventory counts to the ERP — no cycle counts necessary

Depreciation & lifecycle

Usage hours automatically populating ERP asset register records — actual usage depreciation rather than linear

Three ways of achieving the integration

Approach	Implementation	Description
Direct API	Tracking system invokes ERP API REST/SOAP on each event	Small number of events, simple environment, high coupling tolerable
Event queue	Tracking events written to Kafka or RabbitMQ event queue	Large numbers of events, ERP rate limits, replay required
Middleware	ERP connection done via MuleSoft/Boomi or custom middleware	multiple ERP modules, enterprise-level requirements

Step 1 – Normalize the Asset Data Model

There has to be a single standard data model for your assets before you start making API calls. The ERP system IDs and tracking system IDs of your assets are most likely different. Create a mapping layer first.

// Asset ID mapping — tracking system ID → ERP asset number
const assetMap = {
  'tag-7821': { erpId: 'ASSET-00421', erpModule: 'fixed-assets' },
  'tag-7822': { erpId: 'ASSET-00422', erpModule: 'inventory' },
}

function normalizeEvent(trackingEvent) {
  const mapping = assetMap[trackingEvent.assetId]
  if (!mapping) throw new Error(`No ERP mapping for ${trackingEvent.assetId}`)

  return {
    erpAssetId: mapping.erpId,
    erpModule: mapping.erpModule,
    location: trackingEvent.location,
    condition: trackingEvent.sensors,
    timestamp: trackingEvent.ts,
    source: 'asset-tracking'
  }
}

Step 2 – Post asset location updates to ERP inventory

ERP systems have evolved enough today to allow RESTful API calls for inventory updates (SAP, Oracle, Microsoft Dynamics, etc.). Here is a way of pushing the asset location information through API calls to your ERP system’s warehouse management module:

// Push location update to ERP — SAP-style REST endpoint
async function syncLocationToERP(normalizedEvent) {
  const { erpAssetId, location, timestamp } = normalizedEvent

  const response = await fetch(`${ERP_BASE_URL}/api/v1/assets/${erpAssetId}/location`, {
    method: 'PATCH',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': `Bearer ${ERP_TOKEN}`,
      'X-Source-System': 'asset-tracking'
    },
    body: JSON.stringify({
      warehouseLocation: location.zone,
      coordinates: { lat: location.lat, lng: location.lng },
      lastSeen: timestamp
    })
  })

  if (!response.ok) {
    await queueForRetry(normalizedEvent)  // never drop failed syncs
  }
}

Step 3 – Create maintenance work orders automatically
Upon the occurrence of breaches of the threshold values of the sensors or service intervals due to usage hour counts of your assets, the software integration solution can automatically create work orders in the ERP system’s maintenance module:

// Triggered when asset tracking fires a maintenance alert
async function createWorkOrder(alert) {
  const { erpAssetId } = normalizeEvent(alert)

  const workOrder = {
    assetId: erpAssetId,
    type: 'PREVENTIVE',
    priority: alert.severity === 'critical' ? 'HIGH' : 'MEDIUM',
    description: `Auto-generated: ${alert.triggerReason}`,
    triggeredBy: 'iot-sensor',
    sensorData: alert.sensorSnapshot,
    scheduledFor: getNextMaintenanceWindow()
  }

  await fetch(`${ERP_BASE_URL}/api/v1/work-orders`, {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${ERP_TOKEN}` },
    body: JSON.stringify(workOrder)
  })
}

Idempotence tip: Most ERP systems’ API endpoints are not designed to tolerate duplicate API requests. Be sure to include an idempotency key such as “X-Idempotency-Key: ” on each request.

Step 4 - Manage ERP rate limits through a queue
ERPs are not designed to withstand the ingestion volume from IoT systems. The default API rate limit from SAP is usually 100-500 requests per minute, while your IoT tracking system might be generating 10x more. Queue layer will buffer spikes and write records intelligently.

// Queue-based ERP sync — batches events, respects rate limits
const erpQueue = []
let processing = false

async function flushToERP() {
  if (processing || erpQueue.length === 0) return
  processing = true

  const batch = erpQueue.splice(0, 50)  // process 50 at a time
  await Promise.allSettled(batch.map(syncLocationToERP))

  processing = false
  setTimeout(flushToERP, 1000)  // 1 req/sec rate limiting
}

// Called every time a tracking event arrives
function queueERPSync(event) {
  erpQueue.push(normalizeEvent(event))
  flushToERP()
}

Do NOT call ERP API from your MQTT handler directly. If the ERP is slow or rate-limited, your entire IoT data ingestion process would be halted. You should always decouple your ingestion with a queue, even if it is an in-memory queue for small-scale deployment.

Popular ERPs and their APIs

SAP S/4HANA
RESTful OData v4 endpoints. Well documented, rate limited. Use SAP Integration Suite for complex mapping. Asset Management module supports usage-based record update.

Oracle ERP Cloud
REST APIs for the Fixed Assets and Inventory module. Allows bulk import using FBDI endpoint for location update at scale. Offers webhook support for outgoing messages.

MS Dynamics 365
Dataverse (OData) API. Asset Management module works well with IoT Hub out-of-the-box. Use Power Automate for IoT tracking -> ERP processes with no code.

NetSuite
SuiteScript REST API. Lightweight and friendly to developers. Good choice for midmarket solutions, when other ERPs have too much overhead.

Recommended technology stack

Node.js / Python
Kafka / RabbitMQ
Redis (de-duplication cache)
REST / OData
MuleSoft / Boomi
PostgreSQL (audit logs)

Always keep an audit log of all ERP sync attempts made — whatever was synced, what did the ERP reply with, and whether a retry was required. If a data discrepancy in your ERP is detected six months down the line, this is how you will be able to track what went on and when.

AssetTrackPro's integrations come with out-of-the-box connectors for SAP, Oracle, and Microsoft Dynamics, so all your tracking data is connected to your ERP right off the bat. Check out our integrations →

Are you connecting asset tracking with your ERP? Leave the integration layer to AssetTrackPro.
Learn more about AssetTrackPro →