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.
| Key | Effekt |
|---|---|
assign_by_proximity | Naechstgelegenen verfuegbaren Tech ueber users.last_lat/last_lng waehlen |
assign_role | Proximity auf eine Rolle einschraenken, z.B. chargehand fuer battery_swap |
assign_team_id | An eine bestimmte Team-Queue pushen |
change_vehicle_status | Fahrzeug auf maintenance flippen, auch wenn Priority unter high |
notify_slack | Slack 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.