Frigate und Home Assistant: Kamerameldungen mit klaren Bedingungen

Frigate kann auf Kamerabildern Objekte wie Personen erkennen. Home Assistant kann daraus eine Benachrichtigung ableiten, etwa nachts für die Einfahrt. Eine Objektklasse belegt jedoch weder eine unbefugte Person noch einen Einbruch. Auch ein hoher Erkennungswert schließt Fehlalarme nicht aus.

Diese Anleitung richtet zunächst eine überprüfbare Meldung ein. Voraussetzung sind eine laufende Frigate-Installation, Home Assistant, ein gemeinsamer MQTT-Broker und eine eingerichtete Companion-App. Kamera, Zone und Benachrichtigungsdienst müssen zur tatsächlichen Installation passen.

1. Verbindung und Zuständigkeiten klären

Frigate verarbeitet die Kamerabilder. MQTT überträgt Statusänderungen an Home Assistant; die Automation entscheidet über die Meldung. Die Frigate-Integration aus HACS ergänzt Kamera- und Medienfunktionen, installiert aber nicht den Frigate-Server. Der MQTT-Broker nimmt Nachrichten entgegen und verteilt diese an abonnierende Systeme. Beide Systeme benötigen Zugriff auf denselben Broker. Der hier verwendete Topic-Präfix frigate ist bei abweichender Konfiguration anzupassen.

Für eine Verbindung über das Netzwerk ist der authentifizierte Frigate-Endpunkt auf Port 8971 vorgesehen. Port 5000 ist ein interner, nicht authentifizierter Endpunkt und gehört nicht frei ins Netz. HTTPS benötigt ein von Home Assistant akzeptiertes Zertifikat; ein selbst signiertes Standardzertifikat kann die Verbindung verhindern. Zugangsdaten und Broker-Rechte sollten nur die benötigten Verbindungen erlauben.

2. Eine sinnvolle Alarmregel in Frigate festlegen

Für die Kamera driveway wird zunächst eine Zone driveway_zone im tatsächlichen Kamerabild angelegt. Entscheidend für die Zonenzuordnung ist der untere Mittelpunkt des Objektkastens. Ein bloßes Überlappen mit der Zone genügt nicht. Ein Testgang bei Tageslicht und nachts zeigt, ob Perspektive, Schatten oder Scheinwerfer die Erkennung beeinflussen.

In der kamerabezogenen Review-Konfiguration werden Alerts auf das Label person und die erforderliche Zone driveway_zone beschränkt. Die Objekterkennung muss person tatsächlich verfolgen; eine Review-Auswahl aktiviert keine zusätzliche Objektklasse. Diese Regel betrifft erkannte Objekte. Manuell über die API erzeugte Ereignisse haben andere Regeln und dürfen nicht ungeprüft in dieselbe Alarmkette gelangen.

Ein Wert wie top_score: 0.8 bedeutet keine 80-prozentige Wahrscheinlichkeit für einen Einbruch. Schwellenwerte werden anhand tatsächlicher Fehl- und Nichterkennungen eingestellt. Bewegungsmasken ersetzen weder Objektfilter noch eine passend gewählte Zone.

3. Änderungen eines Review-Eintrags auswerten

Für Benachrichtigungen empfiehlt Frigate das Topic frigate/reviews. Ein Review bündelt einen Aktivitätszeitraum einer Kamera und kann mehrere Objekte enthalten. Die Review-ID bezeichnet deshalb keine einzelne Person. Die Nachricht enthält den vorherigen Zustand unter before und den neuen Zustand unter after.

Das folgende Beispiel reagiert auf einen neuen Alert oder den Wechsel von detection (erfasste Aktivität ohne Alarmstufe) zu alert (Aktivität, die die eingestellten Alarmregeln erfüllt). Weitere Aktualisierungen eines bereits als Alert eingestuften Reviews lösen keine neue Meldung aus. Das ist eine bewusste Begrenzung: Eine später hinzukommende Person innerhalb desselben Reviews löst damit keine eigene Benachrichtigung aus.

Vor dem Einfügen in den YAML-Editor einer einzelnen Home-Assistant-Automation sind der Helfer input_boolean.camera_notifications anzulegen und notify.mobile_app_replace_device durch den vorhandenen Gerätedienst zu ersetzen. Der Helfer ist eine manuelle Meldefreigabe, keine Einbruchmeldeanlage. Die Zeitbedingung verwendet die Zeitzone von Home Assistant.

alias: Frigate driveway night notification
triggers:
  - trigger: mqtt
    topic: frigate/reviews
conditions:
  - condition: state
    entity_id: input_boolean.camera_notifications
    state: "on"
  - condition: time
    after: "22:00:00"
    before: "06:00:00"
  - condition: template
    value_template: >-
      {% set p = trigger.payload_json | default({}) %}
      {% set a = p.get('after') if p is mapping else none %}
      {% set b = p.get('before') if p is mapping else none %}
      {{ p is mapping and p.get('type') in ['new', 'update']
         and a is mapping and a.get('camera') == 'driveway'
         and a.get('id') is string and a.get('id') | length > 0
         and a.get('severity') == 'alert'
         and a.get('end_time') is none
         and (p.get('type') == 'new'
              or (b is mapping and b.get('severity') == 'detection')) }}
actions:
  - action: notify.mobile_app_replace_device
    data:
      title: "Camera alert"
      message: "Driveway: activity classified as alert."
      data:
        tag: "frigate-{{ trigger.payload_json['after']['id'] }}"
mode: queued
max: 10

Die Meldung ist bewusst allgemein formuliert: Die tatsächliche Klassifizierung hängt von der zuvor geprüften Frigate-Konfiguration ab. Das Beispiel schaltet keine Sirene. Für Licht oder andere Aktionen sind gesonderte Bedingungen, Laufzeitbegrenzungen und Tests erforderlich.

4. Wiederholungen und Ausfälle berücksichtigen

mode: queued verarbeitet akzeptierte Aufrufe nacheinander; max: 10 begrenzt laufende und wartende Aufrufe zusammen. Bei Überlast können weitere Meldungen entfallen. Die Warteschlange einer Automation speichert ausstehende Meldungen nicht dauerhaft und übersteht Neustarts nicht zuverlässig.

Der gleiche Notification-Tag kann eine vorhandene Meldung auf dem Telefon ersetzen. Das garantiert weder eine einmalige Ausführung noch genau einen Signalton. Wiederholte oder erneut zugestellte MQTT-Nachrichten können den gleichen Übergang nochmals auslösen. Damit bereits verarbeitete Meldungen nicht nochmals verarbeitet werden, müssen die zugehörigen Review-IDs auch nach einem Neustart bekannt sein. Dieser Speicher braucht eine Größen- oder Aufbewahrungsgrenze sowie klare Regeln für fehlgeschlagene Zustellungen. Das Beispiel enthält auch keine Altersprüfung und kann bei erneut zugestellten alten Nachrichten eine veraltete Meldung senden.

mode: single würde lediglich weitere Aufrufe während einer laufenden Ausführung verwerfen. Eine kurze Aktion ist schnell beendet; eine nachfolgende Nachricht kann erneut starten. Eine lange Pause zur Sperrung kann dagegen Meldungen zu anderen Vorgängen verschlucken.

5. Bilder und Zustellung getrennt prüfen

Zuerst sollte die Textmeldung zuverlässig eintreffen. Für ein später ergänztes Vorschaubild wird eine Objekt-Ereignis-ID aus after.data.detections benötigt, nicht die Review-ID. Bei mehreren Objekten ist der erste Listeneintrag nicht automatisch die gewünschte Person. Ein fertiger Clip oder Snapshot steht zudem nicht in jedem Moment zur Verfügung. Die Abrufadresse und deren Zugriffsschutz müssen vom Telefon aus funktionieren.

Lokale Erkennung bedeutet nicht automatisch lokale Push-Zustellung. Standard-Push kann Dienste von Apple oder Google benötigen; Local Push hängt von Plattform, Einstellungen und Verbindung zur Home-Assistant-Instanz ab. Ein Offline-Test muss deshalb Erkennung, MQTT, Automation, Telefonzustellung und gegebenenfalls lokale Aktoren getrennt betrachten.