First Steps
The sequence:
-
The tag appears on its own
-
Create a group
-
Assign tenant and group
-
Create a credential for the third-party system
-
Check the events
-
Add custom positions if needed
The order is not arbitrary: the group has to exist before the tag and the credential can reference it.
1. The Tag Appears
As soon as the device reports over the cellular network for the first time, its record comes into existence automatically — in the default tenant, because the message says nothing about which customer the device belongs to.
You can find it in Tags (Administration). Filter by the device’s IMEI or by Created at to find a new shipment.
|
If the tag does not appear, its messages are not reaching the server. That is then not a problem of this application but one of reachability: check the endpoints, the port forwarding, and the server address configured in the device. |
2. Create a Group
Switch to the tenant’s work area and create a group under Tag Groups.
| Field | Description | Example |
|---|---|---|
Name |
Display name of the group |
|
Notes |
What the group is for |
|
Why first: groups are the unit by which credentials are authorized. Without a group you can neither assign the tag meaningfully nor grant the credential anything later.
One group is enough to start. Several make sense when different third-party systems are meant to see different subsets of tags.
3. Assign Tenant and Group
Two steps, in two different areas.
Tenant — in Tags (Administration), select the tag and use Assign new Tenant from the context menu to assign it to the target tenant.
Group — then, in that tenant’s work area, under Tags, select the tag and use Assign new Group from the context menu to assign it to the group from step 2.
While you are there, give it a meaningful name. Without one the list shows the MAC address, which becomes hard to read once there are several devices.
|
After assigning the tenant, the tag is not yet assigned to any group. Its events are processed and recorded but do not reach any third-party system. The group step is therefore not optional. |
4. Create a Credential
Under Clients, create a credential for the receiving system.
| Field | Description | Example |
|---|---|---|
Name |
The system that uses this credential |
|
Groups |
The groups whose events it may receive |
|
Client Secret |
The credential’s password |
a long, random password |
Notes |
Contact, purpose |
|
|
The client ID is generated when you save. The client secret cannot be viewed again afterwards — store both in the target system immediately. If the secret is lost, set a new one. |
Without an assigned group, the credential connects successfully and receives nothing. This is the most common cause of "connected, but no data".
5. Check the Events
Two checks, in this order:
Are positions arriving? — In Decision events, set the period to the last few hours and filter by the tag. For every event, the detail dialog shows whether a position resulted and where it came from.
Is the third-party system connected? — In Clients, the Status column for
the credential must show Connected. If it shows Disconnected, the issue is with the target system
or its credentials, not with the assignment.
If both checks show what is expected, the setup is complete.
6. Add Custom Positions
Optional, but in practice the step with the largest effect.
Look in Decision events to see where positions are coming from:
-
If an online service is always shown even though the device is always at the same places, use Customize WiFi from the context menu on one of the reported access points to create a position of your own. Future events from that environment then need no request at all.
-
If positions jump between distant places, a mobile hotspot is usually involved. Set the access point in question to Ignored — see Custom Locations.
-
If an area needs to be located precisely, mount a beacon there and register it as Gateway. Every device in range then receives its position.
How the application consults its sources is described in How a Position is Determined.