intermediate
auftraege
rule-engine
automatisierung

Rule Engine Setup

Schreiben Sie Regeln, die Tasks automatisch aus Live-Telemetrie erstellen. Sieben Trigger-Typen, JSON-Konfiguration und Dry-Run-Tests.

Levy Fleets TeamMay 18, 20268 min read

Rule Engine Setup

Die Rule Engine ist das, was Levy Service von einem generischen CMMS unterscheidet. Regeln beobachten Live-Telemetrie und erstellen Tasks automatisch. Eine gut abgestimmte Flotte erreicht innerhalb weniger Wochen nach Go-Live mehr als 50% automatisch erzeugter Tasks.

Dieser Artikel behandelt die sieben Trigger-Typen, die Form der JSON-Konfiguration und wie Sie eine Regel im Dry-Run testen, bevor Sie sie aktivieren.

Wo Regeln liegen

Regeln werden unter /dashboard/task-rules verwaltet. Jede Zeile in der Tabelle zeigt:

  • Name (Ihr Label)
  • Trigger Type (einer der sieben unten)
  • Action Summary (welchen Task sie erstellt)
  • Last Run und Last Match Count
  • Einen Enabled-Toggle

Regeln werden in der Tabelle task_rules gespeichert und respektieren RLS - jede Regel gehoert zu einem Subaccount.

Die sieben Trigger-Typen

1. mileage

Feuert, wenn der Kilometerstand eines Fahrzeugs eine Schwelle relativ zum letzten Close desselben Typs ueberschreitet.

{
  "trigger_type": "mileage",
  "trigger_config": {
    "interval_km": 2000,
    "last_task_type": "scheduled_maintenance"
  },
  "task_type": "scheduled_maintenance",
  "default_priority": "medium"
}

Der Cron /api/cron/task-rule-mileage evaluiert das stuendlich.

2. time

Kalenderbasiert. Laeuft taeglich um 06:00 UTC.

{
  "trigger_type": "time",
  "trigger_config": { "every_days": 90 },
  "task_type": "inspection",
  "default_priority": "low"
}

Paaren Sie das mit mileage fuer "alle 2000 km ODER alle 90 Tage, je nachdem was zuerst eintritt", indem Sie zwei Regeln schreiben.

3. condition_report

Feuert, wenn ein Post-Ride Condition Report ueber einer KI-Schweregradschwelle liegt.

{
  "trigger_type": "condition_report",
  "trigger_config": { "min_ai_severity": 4 },
  "task_type": "repair",
  "default_priority": "high"
}

Das ist ein Event-Trigger: Das Insert in condition_reports durch die Rider App ruft sofort onConditionReportCreated auf, sodass der Task innerhalb von Sekunden nach Fahrtende auf dem Board landet.

4. low_battery

Akkustand faellt unter eine Schwelle UND das Fahrzeug steht laenger als ein konfiguriertes Fenster geparkt. Verhindert, dass Tasks waehrend einer laufenden Fahrt erstellt werden.

{
  "trigger_type": "low_battery",
  "trigger_config": {
    "battery_threshold": 20,
    "parked_minutes": 360
  },
  "task_type": "battery_swap",
  "default_priority": "medium",
  "action_config": { "assign_by_proximity": true }
}

Evaluiert durch /api/cron/task-rule-low-battery alle 30 Minuten.

5. rider_issue

Ein Rider sendet ein Issue ueber den ReportIssue-Flow der Mobile App. Event-basiert.

{
  "trigger_type": "rider_issue",
  "trigger_config": { "category": "mechanical" },
  "task_type": "repair",
  "default_priority": "high"
}

Wenn der Rider ein Foto anhaengt und die KI es als Schweregrad 4+ einstuft, wird die Prioritaet unabhaengig vom Default der Regel auf critical gehoben.

6. iot_fault

Ein Fehlercode landet in iot_events. Das deckt Queclink Fault Flags, OKAI W0,4 BMS Errors und Accelerometer Crash Events ab.

{
  "trigger_type": "iot_fault",
  "trigger_config": { "fault_codes": ["ACCEL_CRASH", "BMS_FAULT"] },
  "task_type": "inspection",
  "default_priority": "critical"
}

Kritische Crash Events flippen das Fahrzeug ueber den Auto-Flip-Trigger sofort auf maintenance.

7. geofence

Fahrzeug verlaesst die Betriebszone laenger als N Minuten. Erstellt einen retrieve-Task.

{
  "trigger_type": "geofence",
  "trigger_config": { "outside_zone_minutes": 30 },
  "task_type": "retrieve",
  "default_priority": "high",
  "action_config": { "assign_by_proximity": true }
}

Evaluiert durch /api/cron/task-rule-geofence stuendlich.

Action Config

action_config liegt neben trigger_config und steuert Zuweisung, Benachrichtigung und Folgeeffekte.

KeyEffekt
assign_by_proximityNaechstgelegenen verfuegbaren Tech ueber users.last_lat/last_lng waehlen
assign_roleProximity auf eine Rolle einschraenken, z.B. chargehand fuer battery_swap
assign_team_idAn eine bestimmte Team-Queue pushen
change_vehicle_statusFahrzeug auf maintenance flippen, auch wenn Priority unter high
notify_slackSlack Webhook bei Regel-Match feuern

Dry-Run vor dem Aktivieren

Jede Regel hat einen Test-Button, der POST /api/task-rules/[id]/test aufruft. Der Dry-Run evaluiert die Regel gegen Ihre aktuelle Flotte und gibt die treffenden Fahrzeuge zurueck ohne Tasks zu erstellen. Nutzen Sie das, bevor Sie eine neue Regel aktivieren, um zu verifizieren, dass sie nicht die gesamte Flotte trifft.

Wenn low_battery zum Beispiel 240 Treffer in einer 250-Fahrzeug-Flotte liefert, ist Ihr parked_minutes vermutlich zu kurz.

Rule Loops und Deduplikation

Regeln koennen denselben Task nicht zweimal erstellen. Der Helper createTaskInternal prueft auf einen bestehenden offenen Task desselben task_type gegen dasselbe Fahrzeug und gibt skipped_duplicate: true zurueck, falls vorhanden. Das wird in task_rule_runs fuer Audit geloggt, erzeugt aber keine neue Zeile.

Damit verhindern Sie die klassische Schleife, in der eine Regel feuert, die Action das Fahrzeug auf maintenance flippt, die Statusaenderung dieselbe Regel erneut triggert und Sie vor dem Mittagessen 10.000 Phantom-Tasks haben.

Die Audit-Tabelle

Jeder Regel-Run wird in task_rule_runs mit den treffenden Fahrzeugen, den erstellten Task-IDs und allen uebersprungenen Duplikaten protokolliert. Nutzen Sie das, um eine Regel zu debuggen, die "nicht feuert" - sie laeuft vielleicht und trifft null Fahrzeuge, oder trifft alle und wird dedupliziert.

Starten Sie mit drei Regeln, nicht dreissig

Der haeufigste Fehler ist, alle Regeln am ersten Tag zu aktivieren. Starten Sie mit low_battery, einer condition_report-Regel und einer mileage-Regel. Fuegen Sie weitere hinzu, sobald die ersten eine Woche sauber gelaufen sind.