---
title: Decision events
id: "en:tpm:ROOT:decision_events.adoc"
site: en
component: tpm
module: ROOT
version: 3.0
lang: en
url: "https://help.rtlscloud.io/en/tpm/3.0/decision_events.html"
source_repo: "https://github.com/iot-invent/rtlscloud-tpm.git@3.0.x"
source_path: docs/en/modules/ROOT/pages/decision_events.adoc
---

# Decision events

For every single positioning decision an entry shows which data was available and where the position came from. This is the view you use to investigate a wrong or missing position.

-   List groupable by tag, newest events first

-   Filters by period, tag and event properties

-   Detail dialog with the decision tree, the raw data and the map

-   Create a position of your own directly out of an event

## Reference

![Decision events](_images/tpm_app_decision_events.png)

| Module | Description |
| --- | --- |
| ![refresh](_images/refresh.svg) Refresh | Reloads the list |
| ![filter](_images/filter.svg) Filter | Period, tags and event properties |
| ![sort](_images/asset_sort.svg) Group by tag | Switches between a flat list and grouping per tag |
| ![info](_images/info.svg) Info | Number of events shown. At most 1000 are loaded |
| Action column | Opens the detail dialog for the selected event |

## Display

| Column | Description |
| --- | --- |
| Tag Id | The MAC address of the device |
| Tag name | Display name, if set |
| Time | Time of the decision. Pre-sorted, newest first |
| Type | Kind of decision. In this application usually a position determination |
| Trigger | Why the device reported: on motion start, on motion end, or on schedule |
| Lon, Lat | Longitude and latitude of the determined position |
| Accuracy | Radius in metres for which the position is claimed to be valid |
| Valid | Whether a usable position resulted. No means the decision was recorded but there is no position |

> **IMPORTANT:** Decisions without a position are recorded too. That is exactly what makes this view useful: the question "why does my device have no position?" is answerable here, not only the question about a wrong one.

## Detail Dialog

A double click or the action column opens the detail dialog with three areas:

| Area | Content |
| --- | --- |
| Decision | Where the position came from and how certain the match was. The source is either a position you maintained yourself, the position cache, or an online service |
| Raw data | What the device reported: mobile network cell, WiFi access points with signal strength, observed BLE devices. Excluded access points are marked as such |
| Map | The determined position with its accuracy radius |

The raw data is the key to troubleshooting. If a position is wrong, this is where you see what it was based on — and from that follows what to do. The order in which the application consults its sources is described in [How a Position is Determined](positioning.md).

## Filter

| Filter | Description |
| --- | --- |
| Period | From–to. The most important filter, since otherwise the list only shows the most recent events |
| Tags | Restriction to individual tags, groups or labels |
| Properties | Only valid or only invalid decisions, restriction to one trigger |

## Context Menu

| Action | Description |
| --- | --- |
| Customize Cell | Creates a position of your own from the mobile network cell contained in the event. You give its known position on the map; future events from that cell are then resolved without an online request |
| Customize WiFi | The same for one of the reported WiFi access points. Also the way to set a disruptive access point to **Ignored** — see [Custom Locations](custom_locations.md) |
| Create request | Issues a one-off request to an online service with the data of this event and shows the result, without changing the stored position |

## Retention

Decision events are deleted automatically after 30 days. The period is configurable; the setting belongs to the installation, not to this view.

Whoever needs positions permanently stores them in the receiving system — this view is a diagnostic window, not an archive.