Frigate i Home Assistant: powiadomienia z kamer z jasnymi warunkami

Frigate rozpoznaje na obrazie z kamer obiekty, na przykład osoby. Home Assistant może wykorzystać wynik do wysłania powiadomienia o nocnej aktywności na podjeździe. Klasa obiektu nie dowodzi jednak nieuprawnionego wejścia ani włamania. Wysoki wynik detekcji również nie wyklucza fałszywego alarmu.

Instrukcja zaczyna się od powiadomienia z możliwymi do sprawdzenia warunkami. Wymagane są działająca instalacja Frigate, Home Assistant, wspólny broker MQTT i skonfigurowana aplikacja Companion. Nazwy kamery, strefy oraz usługi powiadomień muszą odpowiadać konkretnej instalacji.

1. Połączenia i podział zadań

Frigate analizuje obraz, MQTT przekazuje zmiany, a Home Assistant decyduje o powiadomieniu. Integracja Frigate z HACS udostępnia funkcje kamer i multimediów, ale nie instaluje serwera Frigate. Broker MQTT odbiera wiadomości i przekazuje je systemom, które subskrybują dany temat. Oba systemy potrzebują dostępu do tego samego brokera. Przykład używa domyślnego prefiksu tematów frigate; inna konfiguracja wymaga odpowiedniej zmiany.

Uwierzytelniany interfejs Frigate do połączeń sieciowych działa na porcie 8971. Port 5000 jest wewnętrznym interfejsem bez uwierzytelniania i nie powinien być ogólnodostępny. HTTPS wymaga certyfikatu akceptowanego przez Home Assistant; domyślny certyfikat samopodpisany może uniemożliwić połączenie. Dane dostępowe i uprawnienia brokera powinny dopuszczać tylko potrzebne połączenia.

2. Reguła alertu dla kamery

Dla kamery driveway należy najpierw wyznaczyć strefę driveway_zone na rzeczywistym obrazie. O przynależności do strefy decyduje środek dolnej krawędzi prostokąta obiektu. Samo nakładanie się prostokąta ze strefą nie wystarcza. Przejście testowe w dzień i po zmroku pokazuje wpływ perspektywy, cieni oraz reflektorów.

W ustawieniach Review danej kamery alerty zostają ograniczone do etykiety person i wymaganej strefy driveway_zone. Śledzenie obiektów musi rzeczywiście obejmować person; wybór etykiety Review nie włącza nowej klasy obiektów. Reguły dotyczą śledzonych obiektów. Zdarzenia tworzone ręcznie przez API podlegają innym zasadom i wymagają osobnego sprawdzenia przed włączeniem do ścieżki alarmowej.

Wartość top_score: 0.8 nie oznacza 80-procentowego prawdopodobieństwa włamania. Dobór progów opiera się na zaobserwowanych fałszywych i pominiętych detekcjach. Maski ruchu nie zastępują filtrów obiektów ani właściwie wyznaczonej strefy.

3. Reakcja na zmianę klasyfikacji Review

Frigate zaleca temat frigate/reviews do wyzwalania powiadomień. Review obejmuje okres aktywności jednej kamery i może zawierać kilka obiektów. Identyfikator Review nie identyfikuje zatem pojedynczej osoby. Wiadomość przekazuje poprzedni stan w before, a nowy w after.

Przykład reaguje na nowy alert lub zmianę z detection (zarejestrowana aktywność bez poziomu alarmowego) na alert (aktywność spełniająca ustawione reguły alarmowe). Kolejne aktualizacje istniejącego alertu nie powodują następnego powiadomienia. Oznacza to świadome ograniczenie: dodatkowa osoba pojawiająca się w tym samym Review nie wywoła osobnego powiadomienia.

Przed użyciem edytora YAML pojedynczej automatyzacji Home Assistant wymagane jest utworzenie pomocnika input_boolean.camera_notifications oraz zastąpienie notify.mobile_app_replace_device rzeczywistą usługą urządzenia. Pomocnik służy do ręcznego włączenia powiadomień; nie jest systemem sygnalizacji włamania. Warunek czasu korzysta ze strefy czasowej 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

Treść wiadomości opisuje ogólną klasyfikację alertu, której znaczenie zależy od wcześniej sprawdzonych ustawień Frigate. Przykład nie włącza syreny. Oświetlenie i inne działania wymagają osobnych warunków, ograniczenia czasu działania oraz testów.

4. Powtórzenia i awarie

mode: queued wykonuje zaakceptowane wywołania kolejno. max: 10 ogranicza łączną liczbę uruchomionych i oczekujących wywołań; nadmiarowe zgłoszenia mogą zostać pominięte. Kolejka automatyzacji nie jest trwałym magazynem wiadomości i nie zapewnia zachowania zadań po restartach.

Powtarzający się tag powiadomienia może zastąpić wcześniejszą wiadomość na telefonie. Nie gwarantuje jednak jednokrotnego wykonania ani pojedynczego sygnału dźwiękowego. Powtórzone lub ponownie dostarczone wiadomości MQTT mogą jeszcze raz uruchomić tę samą zmianę stanu. Zapobieganie ponownemu przetwarzaniu wymaga rejestru obsłużonych identyfikatorów Review, który przetrwa restart. Rejestr potrzebuje limitu rozmiaru lub czasu przechowywania oraz zasad postępowania przy błędach dostarczania. Przykład nie sprawdza wieku wiadomości; ponowne dostarczenie starych danych może wywołać nieaktualne powiadomienie.

mode: single odrzuca następne wywołania wyłącznie podczas aktywnego wykonania. Krótka akcja szybko się kończy, więc kolejna wiadomość może uruchomić nową. Długa blokująca przerwa może natomiast zgubić zgłoszenia dotyczące innych zdarzeń.

5. Oddzielne testy multimediów i dostarczania

Pierwszym krokiem jest poprawne dostarczanie tekstu. Późniejsze dodanie miniatury wymaga identyfikatora zdarzenia obiektu z after.data.detections, a nie identyfikatora Review. Przy kilku obiektach pierwszy element listy nie musi oznaczać właściwej osoby. Gotowy klip lub migawka mogą jeszcze nie być dostępne w chwili powiadomienia. Telefon potrzebuje działającego adresu pobierania z odpowiednią kontrolą dostępu.

Lokalna detekcja nie oznacza automatycznie lokalnego dostarczania push. Standardowe powiadomienia mogą korzystać z usług Apple lub Google; Local Push zależy od platformy, ustawień i połączenia z Home Assistant. Test bez internetu powinien zatem oddzielnie sprawdzać detekcję, MQTT, automatyzację, telefon oraz ewentualne lokalne urządzenia wykonawcze.