Сообщение об ошибке автоматизации в TRASSIR чаще всего появляется, когда сценарий или правило реакции перестаёт выполняться: не срабатывает тревожная запись, не отправляется уведомление, не запускается скрипт по событию детектора. Система при этом продолжает вести видеонаблюдение, но автоматические действия — сама суть настроенной логики — фактически отключены.
Причина может быть как в синтаксической ошибке пользовательского скрипта на Python, так и в банальном отключении правила после обновления сервера. Ниже разберём, как локализовать сбой, где смотреть журналы и какие проверки выполнить до обращения в техническую поддержку.
Что означает ошибка автоматизации в TRASSIR
Под автоматизацией в экосистеме TRASSIR понимается совокупность механизмов: правила реакций на события, пользовательские скрипты, тревожные сценарии, расписания записи и интеграционные события. Ошибка в любом из этих узлов приводит к тому, что заданное действие не выполняется или выполняется некорректно.
Типичные проявления: в интерфейсе клиента появляется уведомление о сбое сценария, в журнале событий фиксируется ошибка выполнения, а ожидаемая реакция — запись, сирена, push-уведомление, срабатывание реле — не происходит. Важно понимать, что сам видеопоток при этом обычно не затронут: проблема лежит в логике обработки событий, а не в захвате изображения.
Отдельный случай — ошибки внутри пользовательских скриптов. TRASSIR поддерживает расширение функциональности через скрипты, и если код содержит синтаксическую ошибку, обращение к несуществующему объекту или не обрабатывает исключение, выполнение прерывается с записью в лог.
Типичные причины сбоя
Чтобы не гадать, стоит пройтись по наиболее вероятным источникам проблемы. Опыт эксплуатации показывает, что большинство сбоев автоматизации сводится к ограниченному набору причин.
- 🔧 Синтаксическая ошибка в скрипте — опечатка, неверный отступ, обращение к удалённому объекту или каналу.
- 📦 Обновление ПО сервера — после апгрейда версии TRASSIR часть функций или объектов скриптового API может измениться, и старый код перестаёт работать.
- 🔌 Отключённый или переименованный канал — правило ссылается на камеру или детектор, которых больше нет в конфигурации.
- ⏱️ Конфликт расписаний — реакция настроена, но не попадает в активный интервал времени.
- 🚫 Превышение лицензионных ограничений — часть модулей автоматизации требует соответствующих лицензий.
Диагностика: где искать источник проблемы
Первый шаг — открыть журнал событий сервера. В клиенте TRASSIR журнал доступен через интерфейс просмотра событий: там фиксируются ошибки выполнения сценариев с указанием времени и объекта. Найдите записи, совпадающие по времени с моментом, когда автоматизация перестала работать.
Если используется пользовательский скрипт, полезно временно добавить в него вывод отладочных сообщений, чтобы понять, на какой строке происходит остановка. Для скриптов на Python характерны ошибки вида NameError или AttributeError — они указывают, что код обращается к объекту, который не существует в текущей конфигурации.
Проверьте также состояние самих правил: откройте настройки реакций и убедитесь, что нужное правило включено, привязано к существующему каналу и его расписание активно. После обновлений сервера правила иногда сохраняются, но теряют привязку к переименованным объектам.
☑️ Первичная диагностика сбоя автоматизации
Ошибки пользовательских скриптов
Скрипты — самая хрупкая часть автоматизации. Ошибка возникает, когда код не прошёл проверку синтаксиса, обращается к удалённому объекту системы или завершается с необработанным исключением. При этом соседние правила продолжают работать, что иногда маскирует проблему.
Безопасный порядок действий такой: скопируйте текущий код скрипта в отдельный файл как резервную копию, затем проверьте его в редакторе с подсветкой синтаксиса Python. Обратите внимание на отступы — в Python они являются частью синтаксиса, и случайный пробел ломает весь блок. Далее проверьте, что все объекты, к которым обращается скрипт (камеры, детекторы, переменные), присутствуют в текущей конфигурации сервера.
⚠️ Внимание: не редактируйте работающий скрипт напрямую на боевом сервере без резервной копии. Ошибка в коде может остановить не только этот сценарий, но и связанные реакции, если они зависят от его переменных.
Пример типичной ошибки в скрипте
Код обращается к каналу по имени, которое изменили при реорганизации камер. Решение — использовать стабильные идентификаторы объектов вместо имён там, где это поддерживается, либо актуализировать имена после каждого изменения конфигурации.
Сбои после обновления версии TRASSIR
Обновление серверного ПО — частый триггер ошибок автоматизации. Скриптовый API между версиями может меняться: отдельные функции объявляются устаревшими, меняются параметры вызовов или поведение событий. Скрипт, безотказно работавший на старой версии, после апгрейда начинает завершаться с ошибкой.
Что делать в такой ситуации? Во-первых, изучите список изменений новой версии в официальной документации — там указываются доработки, затрагивающие скрипты и правила. Во-вторых, проверьте каждый пользовательский скрипт на предмет вызовов, которые могли измениться. В-третьих, если критичная автоматизация сломалась и быстро восстановить её не удаётся, рассмотрите возможность временного отката на прежнюю версию — но только если это предусмотрено вашей схемой развёртывания и не противоречит условиям лицензии.
Проблемы с правилами реакций и расписаниями
Не каждая «ошибка автоматизации» связана со скриптами. Нередко сценарий исправен, но не срабатывает само правило: событие происходит, а реакция не запускается. Здесь первым делом проверяется цепочка «событие → условие → действие».
Убедитесь, что источник события (детектор движения, тревожный вход, аналитика) реально генерирует событие — это видно в журнале. Затем проверьте условия правила: расписание, минимальный интервал между срабатываниями, привязку к конкретным каналам. Частая ситуация — правило создано для камеры, которая позже была заменена, и привязка указывает на несуществующий объект.
| Симптом | Вероятная причина | Что проверить |
|---|---|---|
| Скрипт не запускается вообще | Синтаксическая ошибка в коде | Журнал ошибок, редактор кода |
| Скрипт запускается, но действие не выполняется | Обращение к несуществующему объекту | Имена каналов и детекторов в коде |
| Правило не срабатывает по событию | Отключено правило или неактивно расписание | Настройки реакций и расписаний |
| Автоматизация сломалась после обновления | Изменение скриптового API | Список изменений версии, тест скриптов |
| Реакция срабатывает с задержкой или частично | Перегрузка сервера, конфликт правил | Загрузка CPU, очередь событий |
⚠️ Внимание: если автоматизация управляет исполнительными устройствами — реле, замками, сиренами, — тестируйте изменения в контролируемом режиме. Ошибочное срабатывание или, наоборот, отказ реакции в охранной системе может иметь последствия за пределами IT-инфраструктуры.
Восстановление работоспособности: пошаговый порядок
Когда причина локализована, действуйте от простого к сложному. Сначала перезапустите проблемное правило или скрипт — иногда сбой носит разовый характер и связан с временной недоступностью объекта. Если ошибка повторяется, переходите к исправлению конфигурации.
Для скриптов: исправьте код, проверьте его на тестовом событии и только потом возвращайте в рабочий контур. Для правил реакций: пересоздайте привязки к каналам, если объекты переименовывались. Для проблем после обновления: адаптируйте скрипты под актуальный API согласно документации вашей версии.
Если собственными силами причину установить не удаётся, соберите диагностическую информацию — фрагмент журнала с ошибкой, текст скрипта, версию сервера — и обратитесь в официальную техническую поддержку разработчика или к интегратору, обслуживающему вашу систему. Точные каналы связи указаны в сопроводительной документации к вашей лицензии.
Профилактика сбоев автоматизации
Снизить вероятность повторения ошибки помогают простые организационные меры. Ведите учёт всех пользовательских скриптов: где применяется каждый, какие объекты использует, кто и когда его менял. При любой реорганизации камер или детекторов проверяйте зависимые правила и сценарии.
Перед обновлением сервера создавайте резервную копию конфигурации и тестируйте критичные сценарии сразу после апгрейда, а не когда обнаружится, что тревожное уведомление не пришло. Для ответственных объектов имеет смысл настроить контрольный сценарий — периодическое тестовое событие, подтверждающее, что цепочка автоматизации работает end-to-end.
Зачем нужен контрольный сценарий
Это искусственное событие (например, срабатывание по расписанию), которое проходит всю цепочку реакций и фиксирует результат. Если контрольное действие не выполнено — вы узнаёте о сбое автоматизации до того, как она понадобится в реальной тревоге.
Часто задаваемые вопросы
Скрипт работал, а теперь выдаёт ошибку — что изменилось?
Чаще всего менялось окружение: обновилась версия сервера, переименовали канал или удалили объект, к которому обращается код. Сверьте текст ошибки в журнале с текущей конфигурацией.
Можно ли восстановить скрипт, если резервной копии нет?
Если скрипт хранился только на сервере и был испорчен правкой, восстановить его штатными средствами может оказаться невозможно. Проверьте наличие архивных копий конфигурации сервера — если они создавались, старую версию скрипта можно извлечь оттуда.
Правило включено, но реакция не срабатывает. Где искать причину?
Проверьте расписание активности правила, привязку к каналу и наличие самого события в журнале. Если событие не регистрируется, проблема на стороне детектора или камеры, а не автоматизации.
Влияет ли лицензия на работу автоматизации?
Да, часть функций — например, отдельные модули аналитики и интеграций — требует соответствующих лицензий. Если лицензия истекла или не покрывает модуль, связанные реакции могут перестать выполняться. Проверьте состояние лицензии в настройках сервера.
Когда стоит обращаться в техническую поддержку?
Если журнал показывает ошибку, которую не удаётся связать с конфигурацией, если сбой воспроизводится на исправном скрипте или если проблема появилась сразу после обновления и не решается адаптацией кода. Приложите к обращению версию сервера, текст ошибки и фрагмент лога — это ускорит диагностику.