We are gradually updating the concept and terminology used in Tags, the GPS-Trace solution for asset tracking. The update introduces a clearer structure for working with gateways, sensors, and physical assets.

Access to Tags is managed through registered GPS-Trace Console users.

Previously, Tags was based on two main entities: gateways and assets. In practice, this model did not always reflect how users work with physical objects.
For example, a BLE (Bluetooth Low Energy) beacon attached to a tool and the tool itself are not the same thing. The beacon can be moved, replaced, or reused, while the tool remains a separate asset with its own history.

To make this logic clearer, Tags will now use three key entities:

Gateway
Sensor
Asset

Gateway

A gateway is a device that collects data and sends it to the platform.
In most cases, this is a GPS tracker that can receive data from:

BLE tags and beacons;
wired sensors connected to the gateway;
the gateway’s own parameters.

The gateway remains the technical entry point through which data is sent to Tags.

Gateways may work differently depending on the technology used:

With Mobile technology, a GPS tracker acts as a mobile gateway. It collects data from nearby BLE sensors and sends this data to the GPS-Trace platform together with its own GPS coordinates.

With Mesh technology, gateways are part of a stationary infrastructure consisting of gateways and anchors.

Sensor

A sensor is a source of data that can be linked to an asset.

A sensor can be:

a BLE tag or beacon;
a wired sensor connected to a gateway;
a gateway parameter, such as fuel level, temperature, or ignition status;
several gateway parameters grouped into one entity.

In the updated model, many entities that were previously called assets will now be called sensors.

For example:

a BLE tag attached to a hospital defibrillator is a sensor;
a temperature parameter received from a gateway can be created as a separate sensor;
a group of gateway parameters selected by the user can also be created as a sensor.

Asset

An asset is the physical object that has value for the user and needs to be tracked.

An asset can be:
- a container;
- a trailer;
- a tool;
- a piece of equipment;
- cargo;
- luggage;
- another physical object.

A sensor can be linked to an asset to provide data about its location, condition, or selected parameters.

An important change is that an asset can exist without a linked sensor. This means users can create assets in advance and link them to sensors later when the physical object is ready for use.

For example, a company can create records for 100 containers before BLE tags are attached to them. Later, when the containers are prepared, the user can link each container to the correct sensor.

Why the model is changing

The main purpose of this update is to separate physical objects from the data sources used to track them.

Previously, an asset often meant “a tag attached to an object.” However, in many real scenarios, the tag and the object have different roles.

For example, in a hospital:

stretchers are assets;
BLE tags attached to stretchers are sensors;
devices that collect data from BLE tags are gateways.

If one stretcher is taken out of service, the BLE tag can be removed and attached to another stretcher. With the updated model, the user does not need to recreate everything from the beginning. They can unlink the sensor from one asset and link it to another.

This helps keep history connected to the physical asset, not only to the tag. Users can see a more accurate record for each asset, even if the linked sensor changes over time.

This approach is useful when:

sensors are reused for different assets;
assets are created in advance and linked to sensors later;
some assets are temporarily not in use;
a sensor is replaced, but the asset history must remain connected to the physical object;
users need to keep separate records for physical objects and technical devices.

Additional examples

Example 1: Rental tools

A rental company works with drills, generators, and other tools.

Each tool is an asset.
A BLE tag attached to the tool is a sensor.
A tracker installed in a service vehicle or storage area can work as a gateway.

The company can create asset records for new tools before assigning BLE tags to them. When the tools are prepared for use, sensors can be linked to the correct assets.

Example 2: Containers and cargo

A logistics company tracks containers and cargo.

A container is an asset.
A BLE tag or beacon attached to the container is a sensor.
A tracker installed in a vehicle or at a facility is a gateway.

If a BLE tag is removed from one container and attached to another, the user only needs to update the link between the sensor and the asset.

Example 3: Gateway parameters as sensors

A user may need reports based on data received directly from a gateway, for example:

fuel level;
temperature;
engine hours;
another selected parameter.

In this case, the user can create a sensor based on one or several gateway parameters. This sensor can then be used for history and reports.

Interface updates

Because of the updated terminology and logic, the Tags interface will also change gradually.

New and updated interface elements will be introduced for:

managing gateways, sensors, and assets;
linking and unlinking sensors and assets;
viewing sensor/asset history and reports;

History, reports and real-time tracking

In the updated concept, history, reports, and tracking-related features will be available for sensors and assets.

This includes:

movement history;
reports;
events related to tracked objects;
status changes based on linked sensors.

In future updates, Tags will also be expanded with additional tracking tools for sensors and assets, such as trips, parameter-based notifications, and other features that help users track movement, status, and events.

Gateways will remain technical entities used mainly for data collection and transmission. If a user needs to track a gateway itself, get history, reports, or other tracking features, they can create a sensor based on the required gateway parameters. After that, this sensor can be used in Tags in the same way as other sensors.

This separates billing for data collection from billing for tracking-related features. Gateways stay inexpensive when they are used only for data collection and transmission, while advanced tracking features are billed only when the user decides to create a sensor based on gateway parameters.

Pricing changes

Pricing will also be aligned with the updated terminology.

Billing will be based on two entities:

gateways;
sensors.

There will be no charge for assets.

In practice, the billing logic remains close to the current model. The main change is that the entities will now be named more accurately.

The gateway price remains unchanged:

1 gateway — 0.1 EUR per gateway / per month.

The sensor price also remains unchanged:

1 sensor — from 0.1 EUR to 0.5 EUR per sensor per month, depending on the selected plan

A sensor is the entity that was previously often referred to as an asset.

This model allows users to manage physical objects separately from the devices and data sources used to track them, without changing the basic pricing approach.
Updated limits

The limits for one Tags account will also be updated.

The maximum limits will be:

500 gateways
500 sensors

To keep the interface convenient and the application stable for real-time tracking scenarios, gateways and sensors need clear account-level limits.

At the same time, assets are now separated from sensors. This means users can create asset records for physical objects independently from the number of gateways and sensors used to collect data.

If a user needs to work with a larger number of gateways or sensors, they can use multiple Tags accounts and quickly switch between them.

When the changes start

The global updates will begin on June 10, 2026.

From the start of the update process, information about the new terminology, limits, interface, and Tags functionality will be gradually updated across GPS-Trace resources over approximately two weeks.

The updated Tags model will make it easier to describe real asset tracking processes, manage links between physical objects and sensors, and keep history connected to the assets that matter to users.