Asset tracking

Organisations rarely lose assets. They lose track of them, which costs the same and is harder to argue about. Carts, cages, tools, trolleys, test equipment and bins migrate through a site all day, and the questions that get asked about them are almost never about coordinates:

• How many carts are in this corral right now, and does anyone need to restock it?
• Has this trolley left the site?
• Which of these forty items has not moved in a month, and why are we renting more?
• Where was it last seen, and by what?

All four are answered from position data, but none of them is answered by a position. Turning a stream of coordinates into a count per zone is the work, and it is the part a map alone does not do.

Getting a position at all

There is no single method that works everywhere, and the choice is usually decided by whether the asset spends its life outdoors.

Method	Where it fits	What it costs you
On-board GNSS	Yards, car parks, open sites, anything that sees sky	Power. A fix is the most expensive thing a battery tracker does, which is why reporting is usually motion-triggered rather than periodic
Wi-Fi MAC scanning	Indoors, where GNSS does not reach. The tracker reports the access points it can hear and the position is resolved from those	Depends on a reasonably stable AP estate
Proximity to a known point	Corrals, bays, gates, docks. The asset hears a beacon at a zone and reports which one, above a signal threshold	Tells you the zone, not the metre. For counting, that is usually the answer anyway
Gateway position	LoRaWAN sensors with no positioning hardware at all	Rough. The set-lnglat-from-gateway-location-chirpstack translator fills the node's position in from the nearest gateway, which is often good enough to say "on site"

Sensative's own Square Tracker and the ruggedised Xtreme variant cover the first three, and Yggio takes any other vendor's tracker through a translator the same way. The deployment pattern below does not depend on which you pick.

The loops matter more than they look. A tracker goes on with adhesive, cable ties or screws through a mounting frame, so fitting a fleet needs no power, no cabling and no drilling into anything structural - which is what makes tagging a few hundred carts a shift's work rather than a project.

A point worth making early: accuracy is a budget, not a target. A tracker that reports every minute to five metres will not last the year on a battery, and a count per corral does not need five metres. Decide what the question tolerates before choosing hardware.

Zones are what you actually query

A geofence is a polygon, and Yggio compares each incoming position against the geofences that exist. That comparison is not part of the default path a report takes, so a tracker is put on the geo query flow - see Data flows, timers and geofences. The flow belongs to the device, so trackers can run it while the temperature sensors on the same connector do not.

The comparison produces an access event:

Event
access: enter	The tracker entered a geofence
access: inside	It reported a new position while already inside
access: exit	It left

The logic lives on the geofence rather than on the tracker. A geofence is connected to an IoT node of its own, the geofence reference node, and the counting is done by a translator on that node. The zone holds the state, because the zone is what the question is about.

general-geofence is that translator. On each access event it maintains the list of assets inside and produces:

Output
assets	How many assets are inside
trackers	How many of those are the type you are counting
assetList	Everything inside, with name, id, position, floor, access state and timestamp
assetUpdate	The asset that just entered, exited or moved

The distinction between assets and trackers is the one that makes this usable on a real site. A corral may hold baggage carts and wheelchairs; the restocking question is only about carts. Matching on a contextual field, for example assetType = Baggage Cart, counts the ones you care about while still reporting everything present.

What a zone does when an asset goes quiet

An asset only leaves a zone by reporting that it left. A tracker whose battery dies inside a corral never sends an exit, so without some other mechanism the count would drift upwards and stay there.

The translator handles this with two retention windows: assets that stop reporting are dropped after removeIdleAssetsAfterHours (minimum 24 h), and assets that have exited are dropped after removeExitedAssetsAfterHours. This is worth understanding rather than leaving at the default, because it is what decides how long a bad count persists. It is a self-healing mechanism, not a correctness guarantee: if a write is lost somewhere upstream, the count is wrong until the idle window expires.

There is also forwardAccuracyLimit, which ignores events whose reported position accuracy is worse than a limit. A poor GNSS fix at the edge of a polygon will otherwise produce enter and exit events that nothing physically did.

What gets built on it

Once assets are ordinary Yggio devices with positions and zone membership, the rest is the platform:

• Counts per zone on a dashboard, per corral, bay or floor. See Dashboards.
• Restocking and escalation through the Rule Engine - a corral below a threshold for longer than a few minutes raises a task, and escalates if nobody acknowledges it.
• A map of where things are, filtered by type, contextual parameter or custom query. See Map. (Not Location Manager - that is deprecated and should not be used for new installations.)
• Utilisation over time, which is usually what justifies the deployment. An asset that has not moved in a month is either broken, hoarded, or evidence that the fleet is larger than it needs to be. That last one is the finding that pays for the project.
• Into the systems people already use - the open API and MQTT into a WMS, ERP or maintenance system, and Grafana or Power BI for reporting.

The red, amber and green bands on a dashboard like that are the operator's own targets rather than anything shipped as a default, which is what makes a tile worth looking at instead of decorative.

Reporting against a service level

Where the counts are contractual, the same numbers settle the contract. Reports run scheduled or on demand as Excel, CSV or HTML, and carry the columns a service agreement is actually argued over: target against actual, and how long an area spent under target. See Reports.

Numbers against an agreed target, rather than charts alone, is the distinction that matters. The same figures then serve three audiences without being re-derived: the shift that has to restock an area today, the monthly management review, and the contract review.

Because assets are ordinary devices, access rights apply normally: a contractor responsible for one terminal sees that terminal's assets and nobody else's.

Running it at scale

• Name zones after the place, not the device. An alarm that says "Aisle 14" is actionable; one that says a geofence reference node id is not.
• Track tracker health as its own signal. Battery and last-seen per tracker, so a unit that has gone quiet is raised as a fault rather than silently distorting a count.
• Expect to reconcile occasionally. Counting systems that depend on paired enter and exit events accumulate error over long periods, and a periodic reset is cheaper than trying to make drift impossible.
• Start with the zones that have a decision attached. A geofence around the whole site tells you little. A geofence around the place someone has to walk to tells you whether they need to.

How to get started

The fastest route to a business case is one asset class, in one area, measured properly.

1 - Pilot. One asset class, one building or one terminal area. A limited batch of trackers, LoRaWAN coverage checked, a Yggio tenant, and the map and rules your team actually needs. Measure it against a baseline agreed up front - search time, utilisation or losses - because a pilot without a stated baseline cannot be argued about afterwards.

2 - Operate. Tune zones, alarms and reports together with the people using them, not before. Add the field workflow on a phone: scan, inspect, hand over. Integrate into your existing systems through the API where that earns its place, rather than everywhere at once.

3 - Scale. More asset classes, more buildings, more sites, on the same platform, roles and data model. Deployed trackers are re-tasked over the air rather than replaced, and other domains - energy, climate, occupancy - join the same tenant.

What to have ready before the pilot starts:

• The asset classes that hurt most, and roughly how many units.
• A site or floor plan, and a view of the existing Wi-Fi and LoRaWAN coverage.
• One operational owner who can say what "good" looks like.

That last one decides more than the hardware does.

Related

• Data flows, timers and geofences - the geo query flow and access events
• Map - where devices are, filtered and clustered
• Rule Engine - turning a count into a task
• Reports - scheduled reporting against a service level
• Square Tracker - the tracker hardware
• Warehouse racking - the same trackers, running the Impact app instead
• Office utilization - measuring space rather than things
• Internal mail collection - demand-driven rounds instead of a fixed schedule