---
title: Erste Schritte
id: "de:tpm:firststeps:firststeps.adoc"
site: de
component: tpm
module: firststeps
version: 3.0
lang: de
url: "https://help.rtlscloud.io/de/tpm/3.0/firststeps/firststeps.html"
source_repo: "https://github.com/iot-invent/rtlscloud-tpm.git@3.0.x"
source_path: docs/de/modules/firststeps/pages/firststeps.adoc
---

# Erste Schritte

Am Ende dieser Anleitung empfängt ein Fremdsystem die Positionen eines Tags.

Alle Schritte sind **Zuordnungen**, keine Geräteinbetriebnahme. Das Gerät selbst meldet sich von allein, sobald es Strom und Mobilfunkempfang hat — Sie müssen es nicht anlegen, nicht anmelden und nicht konfigurieren.

Der Ablauf:

1.  Der Tag erscheint von selbst

2.  Eine Gruppe anlegen

3.  Mandant und Gruppe zuordnen

4.  Einen Client für das Fremdsystem anlegen

5.  Meldungen prüfen

6.  Bei Bedarf eigene Positionen ergänzen

Die Reihenfolge ist nicht beliebig: die Gruppe muss existieren, bevor Tag und Client auf sie verweisen können.

## 1. Der Tag erscheint

Sobald das Gerät zum ersten Mal über Mobilfunk meldet, entsteht sein Datensatz automatisch — im Standard-Mandanten, weil die Meldung nichts darüber aussagt, zu welchem Kunden das Gerät gehört.

Nachsehen können Sie in [Tags (Administration)](../admin/tags.md). Filtern Sie nach der IMEI des Geräts oder nach **Erstellt am**, um eine neue Lieferung zu finden.

> **NOTE:** Erscheint der Tag nicht, erreichen seine Meldungen den Server nicht. Das ist dann kein Problem dieser Anwendung, sondern eines der Erreichbarkeit: zu prüfen sind die Endpunkte, die Portfreigaben und die im Gerät hinterlegte Serveradresse.

## 2. Eine Gruppe anlegen

Wechseln Sie in den Arbeitsbereich des Mandanten und legen Sie unter [Gruppen](../tag_groups.md) eine Gruppe an.

| Feld | Beschreibung | Beispiel |
| --- | --- | --- |
| Name | Anzeigename der Gruppe | `Halle Nord` |
| Notizen | Wofür die Gruppe da ist | `Ladungsträger Standort Nord` |

Warum zuerst: Gruppen sind die Einheit, über die Clients berechtigt werden. Ohne Gruppe können Sie später weder den Tag sinnvoll zuordnen noch dem Client etwas erlauben.

Eine Gruppe genügt für den Anfang. Mehrere sind sinnvoll, wenn verschiedene Fremdsysteme unterschiedliche Teilmengen der Tags sehen sollen.

## 3. Mandant und Gruppe zuordnen

Zwei Schritte, in zwei verschiedenen Bereichen.

**Mandant** — in [Tags (Administration)](../admin/tags.md) den Tag auswählen und über das Kontextmenü **Neuen Mandanten zuweisen** dem Zielmandanten zuordnen.

**Gruppe** — anschließend im Arbeitsbereich dieses Mandanten unter [Tags](../tags.md) den Tag auswählen und über das Kontextmenü **Neue Gruppe zuweisen** der Gruppe aus Schritt 2 zuordnen.

Vergeben Sie bei dieser Gelegenheit einen sprechenden Namen. Ohne Namen zeigt die Liste die MAC-Adresse, was bei mehreren Geräten schnell unübersichtlich wird.

> **IMPORTANT:** Nach dem Zuweisen des Mandanten ist der Tag noch keiner Gruppe zugeordnet. Seine Meldungen werden verarbeitet und aufgezeichnet, erreichen aber kein Fremdsystem. Der Gruppen-Schritt ist deshalb nicht optional.

## 4. Einen Client anlegen

Unter [Clients](../clients.md) einen Client für das empfangende System anlegen.

| Feld | Beschreibung | Beispiel |
| --- | --- | --- |
| Name | Das System, das den Client nutzt | `WMS Produktion` |
| Gruppen | Die Gruppen, deren Meldungen es empfangen darf | `Halle Nord` |
| Client Secret | Das Kennwort des Clients | ein langes, zufälliges Kennwort |
| Notizen | Ansprechpartner, Zweck | `Anbindung Lagerverwaltung` |

> **IMPORTANT:** Die Client-ID wird beim Speichern erzeugt. Das Client Secret ist danach nicht mehr einsehbar — hinterlegen Sie beides sofort im Zielsystem. Ist das Secret verloren, setzen Sie ein neues.

Ohne zugewiesene Gruppe verbindet sich der Client erfolgreich und empfängt nichts. Das ist die häufigste Ursache für „verbunden, aber keine Daten“.

## 5. Meldungen prüfen

Zwei Kontrollen, in dieser Reihenfolge:

**Kommen Positionen an?** — In [Decision events](../decision_events.md) den Zeitraum auf die letzten Stunden setzen und auf den Tag filtern. Für jede Meldung sehen Sie im Detaildialog, ob eine Position zustande kam und woher sie stammt.

**Ist das Fremdsystem verbunden?** — In [Clients](../clients.md) muss die Spalte **Status** für den Client `Connected` zeigen. Steht dort `Disconnected`, liegt es am Zielsystem oder an den Zugangsdaten, nicht an der Zuordnung.

Zeigen beide Kontrollen das Erwartete, ist die Einrichtung abgeschlossen.

## 6. Eigene Positionen ergänzen

Optional, aber in der Praxis der Schritt mit dem größten Effekt.

Sehen Sie in [Decision events](../decision_events.md) nach, woher die Positionen kommen:

-   Steht dort immer ein Online-Dienst, obwohl das Gerät stets an denselben Orten ist, legen Sie über das Kontextmenü **WiFi anpassen** für einen der gemeldeten Zugangspunkte eine eigene Position an. Künftige Meldungen aus dieser Umgebung brauchen dann keine Abfrage mehr.

-   Springen Positionen zwischen weit entfernten Orten, ist meist ein mobiler Hotspot beteiligt. Setzen Sie den betreffenden Zugangspunkt auf **Ignored** — siehe [Benutzerdefinierte Standorte](../custom_locations.md).

-   Soll ein Bereich genau geortet werden, montieren Sie dort einen Beacon und tragen ihn als **Gateway** ein. Alle Geräte in Reichweite erhalten dann dessen Position.

Wie die Anwendung ihre Quellen befragt, steht unter [Wie eine Position bestimmt wird](../positioning.md).

## Weiter

| Thema | Seite |
| --- | --- |
| Was auf welcher Grundlage entschieden wurde | [Decision events](../decision_events.md) |
| Die Reihenfolge der Positionsquellen | [Wie eine Position bestimmt wird](../positioning.md) |
| Eigene Positionen pflegen | [Benutzerdefinierte Standorte](../custom_locations.md) |
| Den gemeinsamen Positions-Cache pflegen | [Positions-Cache](../admin/geo_cache.md) |