Automationen¶

Mittels Automationen sind Geräte in der Lage, miteinander zu kommunizieren und aufeinander zu reagieren, ohne dass ein Nutzer eingreifen oder die Geräte direkt steuern muss. Die Plattform übernimmt die Vermittlung zwischen den Geräten und sorgt dafür, dass Aktionen ausgelöst werden, sobald bestimmte Bedingungen erfüllt sind. Es lassen sich einfache Regeln wie Wenn das Gerät A eine Bewegung registiert, dann schalte das Gerät B ein abbilden.

Frontend

Diese Seite beschreibt die serverseitige Mechanik: das Datenmodell einer Regel, die Auswertung durch die Rule-Engine und die verwaltenden REST-Endpunkte. Wie ein Nutzer Regeln in der App zusammenstellt, steht im Kapitel Automationen (Frontend).

IFTTT-Prinzip¶

Das Konzept der Automationen orientiert sich am IFTTT-Prinzip (If This Then That). Dabei folgen die Regeln dem Muster Wenn dies, dann das: Wenn ein bestimmtes Ereignis eintritt, dann führe eine bestimmte Aktion aus.

In der Plattform müssen Trigger und Akteur zwingend zwei verschiedene Geräte sein, da sonst die Regel auch in der Implementierung des Gerätes selbst umgesetzt werden könnte.

Weil sowohl Trigger als auch Aktion über Capabilities formuliert werden, bleiben Regeln unabhängig vom konkreten Gerätetyp: Jede Capability, die ein Gerät im Thing Model besitzt, kann als Auslöser oder als Aktion dienen.

Datenmodell einer Regel¶

Eine Regel besteht aus einem Trigger und einer Aktion sowie beschreibenden Metadaten. Trigger und Aktion referenzieren jeweils ein Gerät und eine seiner Capabilities mit einem Vergleichswert:

Trigger – { device_uuid, capability, operator, value }: An welchem Gerät, bei welcher Capability, mit welchem Vergleich und gegen welchen Vergleichswert soll geprüft werden.
Aktion – { device_uuid, capability, value }: An welches Gerät soll bei Auslösung welcher Wert für welche Capability gesendet werden.

Dazu kommen name, eine optionale description, das Flag enabled zum Aktivieren/Deaktivieren sowie der automatisch gesetzte Zeitpunkt der letzten Auslösung (last_triggered_at). Persistiert werden Regeln in der Tabelle rules (siehe Datenbank – Regeln). Die beiden JSONB-Felder trigger und action halten das Modell dabei flexibel.

Operatoren¶

Der Operator bestimmt, wie der aktuelle Telemetrie-Wert mit dem hinterlegten Vergleichswert verglichen wird. Die Engine unterstützt Vergleichs-, Mengen- und Änderungsoperatoren:

Operator	Bedingung erfüllt, wenn …
`EQ`, `NEQ`	Wert gleich / ungleich dem Vergleichswert
`GT`, `GTE`, `LT`, `LTE`	Wert größer / größer-gleich / kleiner / kleiner-gleich
`IN`, `NIN`	Wert ist / ist nicht in einer Werteliste enthalten
`CHANGED`	Wert hat sich gegenüber dem vorherigen geändert

Rule-Engine¶

Die Rule-Engine wertet Regeln unmittelbar bei eingehender Telemetrie aus. Sie ist als Singelton im Backend implementiert und überwacht jeden Telemetrie-Datenpunkt, den ein Gerät meldet.

Für jeden Datenpunkt läuft folgender Ablauf:

Die Engine lädt die aktiven Regeln, deren Trigger-Gerät der Absender ist. Deaktivierte Regeln (enabled = false) werden von vornherein ignoriert.
Für jede Regel prüft sie, ob die getriggerte Capability im Datenpunkt enthalten ist, und wertet den Operator gegen den aktuellen Wert aus.
Ist die Bedingung erfüllt, löst sie die Aktion aus: Ein Befehl wird an das Aktionsgerät über MQTT gesendet. Anschließend wird das Datenbankenfeld last_triggered_at der entsprechenden Regel aktualisiert.

flowchart TD
    T["Telemetrie eines Geräts"] --> L["Aktive Regeln<br/>für dieses Trigger-Gerät laden"]
    L --> C{"Capability im<br/>Datenpunkt enthalten?"}
    C -->|nein| Skip["überspringen"]
    C -->|ja| E{"Operator-Bedingung<br/>erfüllt?"}
    E -->|nein| Skip
    E -->|ja| CD{"Regel im<br/>Cooldown?"}
    CD -->|ja| Skip
    CD -->|nein| A["Aktion senden<br/>(Befehl per MQTT)"]
    A --> M["last_triggered_at setzen"]

Erreichbarkeit

Da die ganze Logik der Automationen im Backend liegt, funktionieren die Reglen nur, wenn beide Geräte vom Backend erreichbar sind.

Schutz vor Rückkopplungen¶

Damit sich Regeln nicht gegenseitig in einer Schleife hochschaukeln – etwa wenn eine Aktion wieder Telemetrie erzeugt, die dieselbe Regel erneut auslöst – gilt pro Regel eine kurze Sperrzeit (Cooldown) von zwei Sekunden. Innerhalb dieser Zeit wird dieselbe Regel nicht erneut ausgelöst.

Verwaltung über die REST-API¶

Regeln werden vollständig über die REST-API verwaltet. Neben dem Anlegen, Ändern und Löschen lässt sich eine Regel gezielt aktivieren bzw. deaktivieren (PATCH /rules/:id/toggle) und zu Testzwecken manuell auslösen (POST /rules/:id/trigger), ohne auf das Eintreten des Triggers zu warten.

Grenzen¶

Eine Regel besitzt derzeit genau einen Trigger und genau eine Aktion. Verkettungen von Regeln mit mehreren Triggern und bedinungen sind nicht möglich.

Auch die Möglichkeit an bestimmten Zeitpunkten oder nur an bestimmten Wochentagen zu triggern, ist derzeit nicht implementiert.