Начните с сообщений, которые вы действительно читаете
Откройте несколько обычных сообщений дома и спросите: что человек должен сделать после каждого? Если ответа нет, возможно, событие достаточно сохранить в журнале. Если нужен только статус, он может быть удобнее на экране. Телефон лучше оставлять для того, что имеет значение именно сейчас.
Не начинайте с общего отключения уведомлений. Выпишите источники, нужное действие, получателя и условие завершения. Например, подход человека к двери, низкая батарейка датчика и отсутствие связи с камерой требуют разной частоты и разных формулировок. Событие и отказ доставки тоже различаются: тишина может означать не отсутствие события, а разрыв цепочки.
Один повод — понятное правило отбора
Для сообщения определите место, тип события, режим дома и допустимое время. Слишком широкий повод создаёт шум, слишком узкий пропускает нужную ситуацию. Используйте путь Frigate → HA → уведомление как карту ступеней: отбор в Frigate и условия в автоматизации могут решать разные части задачи.
У камер отдельно оцените уровни review и интересующую зону. У датчика двери — длительность открытого состояния. У обслуживания — возможность собрать несколько устройств в одну сводку. Не переносите правила спокойной сводки на сигналы, требующие немедленной реакции. Категории нужно сначала осмысленно назвать, затем проверить их поведение.
- 01СобытиеКакой факт пришёл и к какому эпизоду относится.
- 02ОтборНужны ли место, длительность, режим и повтор.
- 03СообщениеЧто произошло, что сделать и где посмотреть детали.
Повтор события и обновление сообщения — разные вещи
У одного события камеры могут появляться новые данные. Если каждое обновление вызывает отдельное сообщение, человек получает много карточек одного эпизода. Прежде чем ограничивать поток таймером, выберите идентификатор своего типа события и решите: новый эпизод должен создать новое сообщение, а обновление прежнего — дополнить прежнее.
В примерах уведомлений Frigate используются данные review и идентификатор для сообщения. Не подставляйте вместо него ID объекта из другой цепочки автоматически. Один review может охватывать несколько объектов; что считается одним сообщением, определяется задачей и выбранным источником.
Группировка не заменяет устранение дублей
В Companion App группировка объединяет уведомления визуально, а tag позволяет заменить карточку с тем же тегом. Это разные механизмы, описанные в документации приложения. Сохраняйте различимые теги для независимых эпизодов, иначе одно сообщение может вытеснить другое.
Не считайте это готовым способом для любого канала: Telegram и мобильные уведомления имеют разные возможности. Проверьте также поведение своей ОС и типа сообщения; для критических уведомлений есть отдельные ограничения. Если источник один, но серверов несколько, их сообщения не должны случайно использовать один общий ключ замены.
Напишите сообщение, которое понятно без журнала
Полезная формулировка содержит место, наблюдаемый факт и следующий шаг. «Датчик двери не присылал данные дольше выбранного срока; проверьте связь» честнее, чем «дверь закрыта», выведенное из старого значения. Для камеры можно дать переход к эпизоду, но ссылка должна открываться на телефоне получателя.
Завершение тоже нужно продумать: исчезла ли проблема, прочитал ли человек сообщение, или событие просто закончилось? Эти признаки не равнозначны. Для длительных проблем в HA есть Alert с повторными сообщениями и подтверждением. Возможности конкретного канала и подходящий интервал всё равно выбираются отдельно.
Два независимых события не должны стать одним
Представьте, что один человек долго стоит у двери, а спустя минуту у другой камеры происходит отдельный эпизод. Обновления первого сообщения можно объединять, но второй факт должен остаться различимым. Если для всех уведомлений выбран одинаковый tag, удобная замена карточки может скрыть независимое событие. Если для каждого обновления выбран новый ключ, тот же человек у двери продолжит создавать много сообщений. Правило должно различать эти два случая.
Сначала проверьте пару эпизодов в подготовленном примере и запишите ожидаемое число карточек. Затем посмотрите, что происходит при возврате связи и повторной обработке уже полученных данных. Наличие новой отправки не всегда означает новое физическое событие. В полезной записи есть идентификатор выбранного типа эпизода, момент наблюдения и смысл обновления. Если состояние дедупликации теряется при перезапуске, определите допустимое поведение заранее. Для первого варианта можно сделать правило проще, но его ограничение нужно сохранить в плане проверки, чтобы последующая тишина или повтор не оставались загадкой.
Проверьте не только один удачный приход
Повторите один эпизод с несколькими обновлениями и затем два независимых эпизода подряд. Для первого проверьте отсутствие лишних карточек, для второго — что новый факт не потерялся из-за общей задержки. Если вы используете паузу между сообщениями, запишите, что произойдёт с новым важным событием во время этой паузы.
Отдельно проверьте режим тишины, возврат обычного режима и недоступность отправки. Успешный вызов действия HA не подтверждает, что человек увидел сообщение. В итоговой записи нужны источник, отбор, отправка, фактическое получение и переход к подробностям. Проводите такую проверку на условном примере, не вызывая реальные тревожные события.
Коротко по делу
Убрать лишние уведомления
- Выбери одно событие и решение, ради которого нужно сообщение. Удали уведомления, после которых делать нечего.
- Раздели начало эпизода, допустимый повтор и восстановление. Обновление одного события не обязано давать новое сообщение.
- Проверь новый отдельный эпизод и доставку теста на телефон. Не скрывай потерю связи подавлением повторов.
Как понять результат. Одно событие даёт нужное число сообщений, а важное новое событие не теряется.