Levandor

Runbook: Camera alerts not firing (no Telegram person/car alerts)

3 min read

Cameras are live but no person/car alerts arrive in the Telegram group Telephely biztonsági riasztások (bot “Dezsi az őr” @tlphlyortbot, chat_id -1004475187307). There is no failure alarm, so this can go unnoticed for weeks — the last real outage ran ~17 days silently.

Symptoms

  • A camera is visibly live on the camwall, but no Telegram alerts fire on person/car.
  • frigate-notify logs flood with Already notified on this zone (zones= empty) + Review dropped - No events eligible, and no Alert sent lines.

The dedup flood is a RED HERRING

Already notified on this zone almost always means a failed Telegram send, NOT a zones/dedup misconfig. frigate-notify caches an event (1 h TTL, keyed by event ID) before the send; a failed send leaves it cached, so every 15 s poll re-logs “Already notified”. Do not touch zones/dedup config — find the buried delivery error first (step 2).

Diagnose → Fix

On telep-mainframe (ssh levander@100.115.209.87):

  1. Confirm no alerts are going out:

    docker logs --tail 200 frigate-notify | grep 'Alert sent'

    Empty / stale timestamp = alerts are dead. Continue.

  2. Find the buried delivery error (this is the real diagnosis):

    docker logs --tail 4000 frigate-notify | grep WRN
    • ... lookup api.telegram.org on 127.0.0.11:53: server misbehaving → container DNS is broken → go to fix A. (This was the 2026-08-15 outage.)
    • ... 401 Unauthorized / chat not found → bot token or chat_id problem → go to fix B.
    • Nothing / connection refused → check the container is up: docker ps | grep frigate-notify.

  3. Confirm the DNS theory (if step 2 showed server misbehaving):

    docker exec frigate curl -s -o /dev/null -w '%{http_code}\n' https://api.telegram.org   # 000 = container DNS dead
curl -s -o /dev/null -w '%{http_code}\n' https://api.telegram.org                        # from HOST = 200 (bot/net fine)
cat /etc/resolv.conf                                                                      # nameserver 100.100.100.100 = MagicDNS (the trap)

    Host works but container returns 000 while /etc/resolv.conf points at 100.100.100.100 (Tailscale MagicDNS) = confirmed.

Fix A — container external DNS broken (MagicDNS)

Pin an explicit resolver on the frigate-notify service in /home/levander/nvr/docker-compose.yml:

  frigate-notify:
    dns:
      - 192.168.1.1   # router dnsmasq (external + .lan)
      - 1.1.1.1       # public fallback
cd /home/levander/nvr
docker compose up -d --force-recreate frigate-notify
docker logs --tail 50 frigate-notify | grep 'Alert sent'   # should fire within a detection or two

Internal frigate service-name resolution is unaffected — only external lookups use the new upstream. Backup: docker-compose.yml.bak-dns. Full write-up: 2026-08-15-camera-alerts-dead-tailscale-magicdns-docker-dns.

Fix B — bot/token/chat problem

Verify the bot from the host (it should work if DNS is fine):

source ~/telep/telegram-bot.env
curl -s "https://api.telegram.org/bot${BOT_TOKEN}/getMe"
curl -s "https://api.telegram.org/bot${BOT_TOKEN}/getChat?chat_id=-1004475187307"

getMe 401 = bad token; getChat error = bot removed from the group / wrong chat_id. Fix creds in ~/telep/telegram-bot.env and the frigate-notify config, then docker compose up -d --force-recreate frigate-notify.

Don’t chase these (verified healthy in the 2026-08-15 outage)

  • Zones / dedup config — the flood is a symptom, not the cause (see red-herring callout).
  • frigate-notify labels/zones config — person/car allowed, zones.unzoned allow, no min_score.
  • Snapshots — snapshot.jpg?bbox=1 returns 200 independently.
  • The bot itself — getMe/getChat from the host were fine throughout.

Expected scope (so you don’t “fix” a non-bug)

  • Alerts are wanted only on DÉL / South (192.168.30.119 = telep_cam1/telep_cam2).
  • ÉSZAK / North (192.168.30.139 = telep_cam3/telep_cam4) is excluded on purpose (aimed indoors) via frigate.cameras.exclude — see 2026-07-28-frigate-notify-camera-exclude. No alerts from it is correct.
  • The Xiaomi at 192.168.30.168 is removed / dead — ignore it.

Deeper causes / links

Graph View

Backlinks