---
title: Periodische Regeln
id: "de:tracking:admin:periodical-rules.adoc"
site: de
component: tracking
module: admin
version: 3.0
lang: de
url: "https://help.rtlscloud.io/de/tracking/3.0/admin/periodical-rules.html"
source_repo: "https://github.com/iot-invent/xCloud.git@3.0.x"
source_path: "tracking/docs/de/modules/admin/pages/periodical-rules.adoc"
---

# Periodische Regeln

Periodische Regeln werden vom Tracking-System in festen Zeitabständen automatisch ausgeführt. Anders als ereignisbasierte Regeln, die auf eingehende Lokalisierungsdaten reagieren, bewerten periodische Regeln den aktuellen Zustand der Assets unabhängig von neuen Ereignissen – etwa anhand des letzten Tag-Updates, der aktuellen Lokation oder der Asset-Metadaten.

Typische Anwendungsfälle:

-   Assets erkennen, die nicht mehr melden

-   automatische Umlagerungen auslösen

-   Lokalisierungsereignisse erzeugen

Das Ausführungsintervall legt der Parameter **Periode** (in Minuten) fest. Bei `period = 5` wird die Regel alle fünf Minuten ausgeführt.

## Aufbau einer Regel

Eine periodische Regel besteht aus einer Zeitplanung und einer Konfiguration, die das Verhalten beschreibt. Die Konfiguration wird als YAML hinterlegt und bei jeder Ausführung ausgewertet.

| Parameter | Beschreibung |
| --- | --- |
| name | Name der Regel |
| period | Ausführungsintervall in Minuten |
| configuration | YAML-Konfiguration, die die Regel-Logik beschreibt |

## Regeltypen

Derzeit ist ein Regeltyp verfügbar:

| Typ | Beschreibung |
| --- | --- |
| timeout | Erkennt Assets, die innerhalb einer festgelegten Zeit kein Tag-Update erhalten haben |

Weitere Typen können in künftigen Versionen hinzukommen.

## Timeout-Regel

Die Timeout-Regel prüft Assets in den konfigurierten Ausgangs-Lokationen. Liegt das letzte Tag-Update eines Assets länger zurück als die eingestellte Zeit, wird eine Aktion ausgelöst. So lassen sich inaktive Assets, fehlende Tag-Updates oder Geräte erkennen, die nicht mehr senden.

Beispiel-Konfiguration

```yaml
ruleType: timeout
sourceLocations:
  - storage
targetLocation: quarantine
timeout: 10
fireLocalizationEvent: true
```

| Parameter | Typ | Beschreibung |
| --- | --- | --- |
| ruleType | Text | Regeltyp; für die Timeout-Regel `timeout` |
| sourceLocations | Liste | Lokationen, deren Assets überwacht werden. Untergeordnete Lokationen werden einbezogen. |
| targetLocation | Text | Lokation, die dem Asset zugewiesen wird, wenn die Bedingung eintritt |
| timeout | Zahl | Zeit in Minuten. Die Regel greift, wenn das letzte Tag-Update älter ist. |
| fireLocalizationEvent | Ja/Nein | `true` erzeugt ein Lokalisierungsereignis, `false` setzt die Lokation des Assets direkt. |

> **TIP:** Enthält sourceLocations eine übergeordnete Lokation (z. B. warehouse), werden auch die Assets in allen untergeordneten Lokationen (zoneA, zoneB …) ausgewertet.

## Ablauf

Bei jeder Ausführung lädt die Regel ihre Konfiguration, löst die Ausgangs- und Ziel-Lokationen auf, sucht Assets mit zugewiesenem Tag in den Ausgangs-Lokationen, deren letztes Tag-Update älter als der Timeout ist, und führt die konfigurierte Aktion aus. Im Beispiel werden Assets, die seit zehn Minuten kein Update mehr hatten, so behandelt, als wären sie in `quarantine` erkannt worden.

## Gültige Konfiguration

Eine Konfiguration ist gültig, wenn `targetLocation` gesetzt und `sourceLocations` nicht leer ist.

## Fehlersuche

Die Regel wird nicht ausgeführt

-   Ist die Regel aktiv?

-   Ist `period` größer als 0?

-   Ist die YAML-Konfiguration gültig?

Assets werden nicht erkannt

-   Sind den Assets Tags zugewiesen?

-   Liegen die Assets in den konfigurierten `sourceLocations`?

-   Ist der Timeout-Schwellwert erreicht?