Levy Vision Fehlerbehebung

Dieser Artikel ist Ihre erste Anlaufstelle, wenn etwas verkehrt aussieht. Die folgenden Diagnosen decken die häufigsten Probleme bei Helm, Parken und Gehwegerkennung ab. Wenn nichts davon es löst, kontaktieren Sie den Support mit den relevanten Ereignis-IDs.

Helm-Selfie erscheint für Fahrer nie

Der Fahrer tippt auf Unlock, aber kein Selfie-Screen erscheint.

Unterkonto-Schalter prüfen

1. Öffnen Sie Dashboard > Safety > Safety settings.
2. Bestätigen Sie, dass Sie im richtigen Unterkonto im Wechsler sind.
3. Verifizieren Sie, dass Helmet check enabled an ist. Speichern, falls Sie umgeschaltet haben.

AXA-Bypass prüfen

Falls das Fahrzeug ein AXA-Helmschloss hat und der Fahrer den Helm gerade entriegelt hat (innerhalb 60 Sekunden), überspringt der Bypass automatisch das Selfie. Suchen Sie nach einem Ereignis mit status='bypassed' in Safety > Events. Wenn Sie eines sehen, funktioniert das System wie geplant.

App-Version des Fahrers prüfen

Der Helm-Selfie-Screen wird ab Fahrer-App-Version 1.8.0 ausgeliefert. Falls der Fahrer eine ältere Version hat, drängen Sie ihn zum Update. Der App Store hat normalerweise die neueste Version innerhalb eines Tags nach Release.

IL-Einverständnis-Toggle prüfen

Falls die Rechnungsadresse des Fahrers Illinois ist und er das BIPA-Einverständnis-Toggle in seinen Account-Einstellungen nicht akzeptiert hat, wird der Selfie-Flow übersprungen. Lassen Sie ihn die Rider-App öffnen, zu Profile > Privacy gehen und das Toggle akzeptieren.

Helm-Selfie zeigt sich, scheitert aber immer

Der Fahrer macht ein sauberes Selfie mit Helm, aber das Ergebnis ist immer fail.

Konfidenz prüfen

Öffnen Sie Safety > Events, finden Sie das fehlgeschlagene Ereignis, klicken Sie die Zeile. Schauen Sie den Inferenz-Reasoning-String an. Häufige Probleme:

• "low_light" — der Fahrer ist in schwachem Licht. Er muss in besseres Licht wechseln.
• "face_occluded" — der Helm sitzt zu tief auf der Stirn. Häufig bei Vollvisier-Helmen.
• "headwear_not_helmet" — das Modell hält ihn für einen Hut. Manche Pendlerhelme sehen dem Modell hut-förmig aus.

Für den letzten Fall markieren Sie das Ereignis als False-Positive. Das Modell lernt mit der Zeit aus diesen Markierungen.

Strict Mode aus versuchen

Falls Sie Strict Mode an haben und der Fahrer nicht über den Screen kommt, schalten Sie Strict vorübergehend aus (Safety > Safety settings), lassen den Fahrer erneut versuchen und schalten Strict dann wieder an. Mit Strict aus startet ein ambiguous-Ereignis trotzdem die Fahrt — das entsperrt den Fahrer, während Sie debuggen.

Gemini-Status prüfen

Falls viele Fahrer über viele Flotten hinweg scheitern, könnte unser Gemini-Provider ausgefallen sein. Prüfen Sie Sentry auf helmet_classifier_inference_failed-Fehler. Falls Sie eine Spitze sehen, ist Fail-Open aktiv (inference_failed-Ereignisse starten die Fahrt trotzdem), Fahrer sollten also nicht blockiert sein.

Parkpose-Ergebnisse erscheinen nie

Der Fahrer macht das End-of-Ride-Foto, aber keine Zeile erscheint in Safety > Parking reviews oder Safety > Events.

Unterkonto-Schalter prüfen

Bestätigen Sie in Safety > Safety settings, dass Parking validation enabled an ist. Aus bedeutet, das Foto wird gesammelt, aber nicht bewertet.

Ein paar Sekunden warten

Der Klassifikator kann auf Gemini bis zu 5 Sekunden brauchen und auf Captur länger (async). Geben Sie ihm eine Minute, dann aktualisieren Sie.

Das Foto prüfen

Falls das Foto beschädigt ist (Netzwerkabbruch während Upload), läuft keine Inferenz. Schauen Sie im Fahrtdetail nach dem Parkfoto. Falls es fehlt oder kaputt ist, sollte der Fahrer wiederholen — es gibt eine "Retake parking photo"-Option in seiner App für die letzte Fahrt.

Storage-Bucket prüfen

Der cv-evidence-Bucket muss mit privatem Zugriff und Signed-URL-Reads existieren. Falls er gelöscht wurde oder seine Policies geändert wurden, scheitert die Klassifizierung stumm. Kontaktieren Sie den Support, falls Sie das vermuten.

Es fließen keine Gehweg-Ereignisse

Sie haben Vendor-Hardware installiert, Geräte provisioniert und erwartet, dass Ereignisse erscheinen — aber Safety > Events hat keine sidewalk_entry-Zeilen.

Das ist das häufigste Problem. Arbeiten Sie es der Reihe nach durch:

Bestätigen Sie, dass das Gerät zugeordnet ist

Öffnen Sie Safety > Vendor devices. Die Geräteseriennummer muss in der Liste sein und mit einem echten Fahrzeug verknüpft. Falls sie fehlt, feuert der Webhook, aber wir können sie nicht zuordnen.

Bestätigen Sie, dass Durchsetzung an ist

Verifizieren Sie unter Safety > Safety settings, dass Sidewalk detection enabled an ist. Mit aus werden Ereignisse trotzdem protokolliert, aber das Dashboard versteckt sie standardmäßig. Nutzen Sie den "Show all event types"-Filter auf der Events-Seite zur Verifizierung.

Bestätigen Sie, dass der Webhook bei uns ankommt

Im Vendor-Dashboard finden Sie das "Webhook delivery log" oder Äquivalent. Suchen Sie nach Zustellversuchen an unsere URL. Sie sollten 200 OK sein. Falls 401, ist die Signatur falsch — prüfen Sie das Webhook signing secret in den Safety-Settings.

Falls sie Timeouts haben (504), ist unser Endpunkt unter Last möglicherweise langsam. Sentry hat es erfasst; kontaktieren Sie den Support.

Bestätigen Sie das Signatur-Schema

Drover nutzt t=<ts>,v1=<hex> HMAC-SHA256. Luna nutzt flaches Hex HMAC-SHA256. Falls der Vendor mit einem anderen Schema signiert (manche haben ältere Endpunkte), lehnen wir ab. Lassen Sie den Vendor das Schema bestätigen.

Bestätigen Sie, dass es eine Fahrt gibt

Wir ordnen Gehweg-Ereignisse der aktuellen Fahrt des Fahrzeugs zu. Falls das Fahrzeug untätig ist (keine aktive Fahrt), wird das Ereignis protokolliert, aber nicht durchgesetzt und erscheint möglicherweise nicht in der Fahrer-UI. Prüfen Sie Safety > Events mit dem "vehicle: idle"-Filter an.

Throttle-Cut hat nicht gefeuert

Sie haben erwartet, dass ein Fahrzeug nach der Schwelle abgeschaltet wird, aber der Fahrer ist weitergefahren.

Schwellen-Zählung prüfen

Öffnen Sie die Fahrt. Zählen Sie die Gehweg-Ereignisse. Falls der Fahrer 2 Ereignisse hatte und Ihr Cut threshold 3 ist, sollte kein Cut feuern. Bestätigen Sie Schwellen in den Safety-Settings.

Throttle-Cut-Hauptschalter prüfen

Throttle cut enabled ist ein separater Hauptschalter zusätzlich zur Schwelle. Falls aus, feuert unabhängig von der Schwelle kein Cut.

Protokoll prüfen

Manche IoT-Protokolle unterstützen kein Mid-Ride-Throttle-Disable. Schauen Sie auf den iot_type des Fahrzeugs. Falls acton-legacy, wird Throttle-Cut nicht unterstützt — nur Warn feuert. Siehe die OEM-Kompatibilitätsmatrix in Throttle-Cut-Policy.

IoT-Befehlslog prüfen

Öffnen Sie das Fahrtdetail. Der "IoT commands"-Abschnitt sollte einen disable_throttle-Versuch mit Grund cv_sidewalk_repeated zeigen. Falls er fehlt, hat die Policy-Engine nicht gefeuert — prüfen Sie den Events-Feed auf eine cv_violation_actions-Zeile.

Falls der Befehl versucht wurde, aber fehlschlug (queued + abgelaufen), war das Fahrzeug offline. Die Policy-Engine versucht es 60 Sekunden lang erneut, dann gibt sie auf.

Throttle stellt sich nicht wieder her

Ein Fahrer wurde abgeschaltet und kann den Antrieb auch nach Tippen auf I'm back on the road nicht zurückbekommen.

Telemetrie prüfen

Der Restore-Endpunkt erfordert 30 Sekunden saubere Telemetrie (keine Gehweg-Ereignisse). Falls der Fahrer laut Vendor noch auf einem Gehweg ist, wird die Wiederherstellung verweigert. Schauen Sie im Events-Feed der Fahrt nach.

IoT-Pfad prüfen

Falls das Fahrzeug offline ist, kann der Enable-Befehl es nicht erreichen. Warten Sie, bis das Fahrzeug zurückmeldet, und lassen Sie den Fahrer erneut versuchen.

Manuelles Wiederherstellen

Falls Sie übersteuern müssen, öffnen Sie das Ereignis in Safety > Events und klicken auf Restore throttle. Das Dashboard sendet enableVehicleThrottle() direkt und umgeht die Telemetrie-Prüfung.

Latenz fühlt sich langsam an

Fahrer beschweren sich, dass Helm-Selfie oder Parkvalidierung zu lange braucht.

Latenz-Diagramm prüfen

Die Seite Safety > Overview hat p50- und p95-Latenz für jede Fähigkeit. Spezifikationsziel:

• Helm: 2s p50, 4s p95
• Parken (Gemini): 3s p50, 6s p95
• Parken (Captur): async, keine Fahrerwartezeit

Falls Sie durchgängig über diesen Zahlen liegen, kontaktieren Sie den Support.

Mobilfunk-Verbindung des Fahrers prüfen

Die meisten "langsame Inferenz"-Berichte sind langsame Uploads. Der Klassifikator selbst braucht 1–2 Sekunden; der Rest ist Bild-Upload und Netzwerk-Round-Trip. Fahrer mit schlechter Verbindung sehen die Verzögerung.

False-Positives sind zu hoch

Fahrer werden abgeschaltet oder bezahlt, wo sie es nicht sollten.

Flag false positive verwenden

Jeder False-Positive sollte in der Ereigniszeile markiert werden. Das speist die Modellverbesserungs-Pipeline. Diesen Schritt nicht überspringen.

Schwellen erhöhen

Erhöhen Sie in den Safety-Settings die Warn-/Speed-Reduce-/Cut-Schwellen um eins. Das Modell ändert sich nicht, aber die Policy-Engine wird weniger aggressiv.

Geofence-Allow-List hinzufügen

Gehwege, die keine echten Gehwege sind (geschützte Radwege, Plätze) — fügen Sie ein kind=allow-Polygon in Sidewalk hotspots hinzu.

An Support eskalieren

Falls Ihre False-Positive-Rate nach einer Woche Tuning über 5 % liegt, ist das ein Signal, dass das Modell schlecht auf Ihre Geografie oder Ihren Fahrzeugmix kalibriert ist. Sagen Sie es dem Support — wir können Pro-Unterkonto-Konfidenz-Untergrenzen anpassen.

Immer noch hängen geblieben?

Öffnen Sie ein Support-Ticket aus dem Hilfecenter oder mailen Sie an support@levyelectric.com. Geben Sie an:

• Unterkonto-ID
• Eine spezifische Ereignis-ID (aus dem Events-Feed)
• Was Sie erwartet haben vs. was passiert ist
• Zeitspanne des Problems