Sprut.hub не запускает сценарий: ошибки, логи и решения

Sprut.hub • Практическая диагностика • Обновлено 09.10.2026

Сценарий в Sprut.hub не запускается, выполняется дважды, не выключает свет по таймеру или отправляет команду, но устройство не реагирует? Причина не обязательно в хабе. Ошибку удобнее искать по этапам: от события датчика до подтверждения состояния исполнительного устройства.

Короткий ответ. Сначала проверьте работу устройства вручную, затем активность сценария, жёлтый триггер в блоке «Если», дополнительные условия, режим повторного запуска (∞), задержки и журнал отладки. Изменяйте по одному параметру и проверяйте результат, а не сбрасывайте систему целиком.
5 звеньев проверки7 типовых симптомов4 практических примера

Как понять, на каком этапе не работает сценарий

Неудачный запуск часто описывают одной фразой: «Sprut.hub не выполнил автоматизацию». Но одинаковый внешний результат возникает из разных причин. Например, датчик не отправил событие, в блоке «Если» отключён запускающий триггер, дополнительное условие оказалось ложным или реле получило команду, но не изменило состояние.

1СобытиеДатчик, кнопка, расписание или изменение параметра
2ТриггерРазрешён ли запуск нужной ветви?
3УсловиеВыполнены ли все необходимые проверки?
4КомандаДошло ли действие до устройства?
5РезультатПодтверждено ли фактическое состояние?

Если вручную из интерфейса Sprut.hub лампа включается, а по движению нет, начните с триггеров и условий. Если лампа не реагирует даже на прямую команду, прежде проверьте питание, связь, шаблон устройства и сам исполнительный модуль.

Что проверить до изменения сценария

  1. Убедитесь, что сценарий включён. Проверьте его состояние и принадлежность к нужной комнате. Не путайте отключённую автоматизацию с ошибкой её логики.
  2. Проверьте устройства по отдельности. Посмотрите, меняется ли состояние датчика в интерфейсе и выполняется ли ручная команда на свет, розетку или реле.
  3. Запишите точный симптом. «Не включился в 19:02» полезнее, чем «иногда не работает». Для редких проблем нужны дата, время и исходные состояния.
  4. Проверьте время и часовой пояс хаба. Это особенно важно для планировщика, восхода/заката и расписаний. Не меняйте случайно несколько параметров сразу.
  5. Сохраните рабочую конфигурацию. Перед значительной переработкой экспортируйте сценарий как образец и убедитесь в наличии актуальной резервной копии хаба. Экспортированный шаблон сценария обезличивается, после импорта устройства придётся назначать заново.
Важно: диагностируйте свет и тестовые нагрузки в безопасных условиях. Не проверяйте экспериментальные алгоритмы на работающем газовом котле, электрокране, насосе, замке или другом критичном оборудовании. Не отключайте штатную защиту и не вскрывайте оборудование под напряжением.

Где находятся логи Sprut.hub и как их читать

У Sprut.hub есть служебное окно отладки. Согласно документации производителя, его открывают в настройках через меню настройки отображения. Там можно просматривать сообщения в реальном времени и искать нужное событие. Архив логов скачивается из общего интерфейса через меню с тремя точками и команду «Скачать логи». Расположение отдельных пунктов может отличаться в зависимости от версии интерфейса.

Способ 1

Наблюдать в реальном времени

  1. Откройте веб-интерфейс хаба.
  2. Перейдите в настройки и вызовите окно отладки.
  3. Очистите контекст наблюдения визуально: отметьте текущее время и нужное устройство.
  4. Воспроизведите проблему ровно один раз.
  5. Проверьте сообщения за этот промежуток и сопоставьте их с изменением устройства.
Способ 2

Скачать архив журналов

  1. Откройте общий интерфейс управления.
  2. Нажмите меню с тремя точками в правом верхнем углу.
  3. Выберите «Скачать логи».
  4. Сохраните архив отдельно от резервной копии.
  5. Перед передачей третьим лицам проверьте содержимое на персональные данные, адреса и токены.

Что искать в журнале

Удобно сопоставлять метки времени, идентификатор или название устройства, изменение его характеристики, факт команды и последующее состояние. Отсутствие строки в обычном журнале само по себе не доказывает, что события не было: детализация зависит от типа сообщения и версии системы. Не предполагается, что каждый блок сценария автоматически пишет отдельную подробную запись.

Чтобы получить наблюдаемую точку в собственной логике, на время диагностики можно добавить в безопасный блочный сценарий штатный блок «Уведомление» → «Системное». Официальная Wiki указывает, что такое сообщение видно в веб-интерфейсе и журнале отладки. Например, текст «Тест: датчик движения, ветка включения» поможет отличить выполнение ветки от физического срабатывания реле.

Пример диагностической последовательности, а не буквальный формат системного лога19:02:10 — Датчик: обнаружено движение
19:02:10 — Метка сценария: условие освещённости выполнено
19:02:11 — Команда: включить свет
19:02:12 — Проверка: свет включён

Если метка «условие выполнено» не появилась, проверяйте триггер и условия. Если метка есть, а свет не включился, проверяйте действие, связь, тип исполнительного устройства и наличие другой автоматизации, меняющей его состояние.

Почему сценарий не запускается: жёлтые триггеры и блок «Если»

В блочных сценариях жёлтый кружок обозначает активный триггер. Не каждое условие «Если» само запускает выполнение. По умолчанию устройства в верхнем уровне «Если» активны, а во вложенных условиях могут использоваться только для дополнительной проверки.

Активный триггерДвижение обнаружено
УсловиеОсвещённость ниже 200 лк
ДействиеВключить свет

В этой схеме понижение освещённости само по себе не обязано включать свет. Сценарий стартует при движении, затем оценивает текущее значение освещённости. Если сделать вложенный датчик освещённости активным триггером, поведение изменится: его событие сможет запустить соответствующую ветвь при выполнении вышестоящих условий.

«Одно из» и «Все сразу»

Когда в одном «Если» несколько условий, проверьте режим их объединения. «Одно из» допускает выполнение при одном подходящем условии, а «Все сразу» требует выполнения всей заданной комбинации в логике события. Сочетание кратковременного нажатия кнопки и состояния датчика движения особенно легко настроить неправильно. Это не универсальная команда «сначала произошло А, а через минуту Б».

Практический тест: временно оставьте один безопасный запускающий датчик и одно простое действие. Добейтесь воспроизводимого запуска, а затем по одному возвращайте дополнительные условия.

Сценарий срабатывает один раз, слишком часто или зацикливается

Значок бесконечности (∞)

В блоке «Если» значок ∞ отвечает за повторную реакцию на события при сохранении подходящего состояния. Когда ∞ выключен, сценарий может выполнить условие один раз и ждать выхода характеристики за порог или изменения состояния. Когда ∞ включён, каждое поступающее подходящее обновление способно повторно запустить действие. Поэтому для температуры, влажности и мощности это настройка особенно заметна: датчики отправляют значения многократно.

Официальная инструкция отдельно предупреждает: для планировщика бесконечность должна быть включена. Нельзя применять одно правило «всем датчикам выключить ∞» без учёта типа источника события.

Триггер на устройстве, которым управляет этот же сценарий

Опасный шаблон: событие изменения состояния реле запускает сценарий, который тут же снова меняет это реле. Возникает петля команд либо неожиданный повторный запуск. Разделяйте источник события и управляемое устройство или вводите корректные условия, исключающие самовозбуждение. Разработчик прямо не рекомендует делать управляемое устройство активным триггером того же сценария.

Два сценария управляют одной нагрузкой

Например, датчик движения включает лампу, а отдельный сценарий «Ночь» сразу устанавливает противоположное состояние. Это уже конкуренция автоматизаций, а не неисправность Zigbee. На время проверки безопасно отключайте только конфликтующий тестовый сценарий, отмечайте результат и возвращайте настройки по одному.

Почему не срабатывает задержка или свет выключается не вовремя

Блок «Задержка» запускает вложенные в него действия после указанного промежутка. В Sprut.hub есть два принципиально разных режима. Перепутав их, легко получить впечатление, что таймер перестал работать.

Один таймер

Повторное событие продлевает ожидание

Первое событие запускает отсчёт, следующее событие до его окончания сдвигает момент выполнения. Подходит для логики «выключить свет через несколько минут после последней активности» при корректных исходных триггерах.

Новый таймер

Каждое событие создаёт отдельную задержку

При трёх срабатываниях могут появиться три параллельных отложенных действия. Если пользователь ожидает одного итогового выключения, такой режим создаст нежелательные повторы.

Учитывайте также сброс задержки: команда очистки может отменить ранее поставленное действие. Когда задержек несколько, важно проверить, какой именно номер задержки сбрасывается. Если действие стоит внутри блока задержки, оно не обязано выполняться немедленно после основного условия.

Четыре типовые ситуации: как искать причину

01

Свет не включается по движению

Проверьте: меняется ли «движение» в хабе; включён ли сценарий; активен ли жёлтый триггер; не блокирует ли включение освещённость или расписание; реагирует ли реле на ручную команду.

Диагностический приём: добавьте временную системную метку перед командой света. Есть метка, но нет света — переходите к устройству и другим сценариям.

02

Уведомления приходят десятки раз

Проверьте: не активна ли ∞ у часто обновляемой температуры или мощности, не запускают ли один и тот же блок несколько событий, нет ли цикла через управляемый аксессуар.

Диагностический приём: сравните число поступивших обновлений датчика с числом повторных уведомлений. Для защиты от дребезга предусмотрите подходящую логику порогов, а не случайное отключение всех триггеров.

03

Свет выключается слишком рано или слишком поздно

Проверьте: режим «Один таймер» или «Новый таймер», поступление новых событий движения, вложенные действия, команду сброса конкретной задержки и наличие второго сценария выключения.

Диагностический приём: проведите эксперимент на коротком безопасном интервале и запишите время первого и последнего движения.

04

Отопление получает конфликтующие команды

Проверьте: сколько сценариев меняют одну уставку или реле, есть ли ручной приоритет, как обрабатываются режимы день/ночь, пропажа датчика и восстановление питания. Отдельно оцените последовательность команд и подтверждение результата.

Диагностический приём: воспроизведите логику на виртуальном или безопасном тестовом устройстве; реальные цепи котла не используйте как полигон. Защитные функции отопления должны работать независимо от пользовательской автоматизации.

Особенность: последовательное выполнение и блоки кода

Если сценарий использует код и сначала записывает характеристику, а сразу затем её читает, асинхронное выполнение может приводить к чтению прежнего значения. В настройках Sprut.hub предусмотрен режим последовательного выполнения; по документации он позволяет дождаться завершения записи перед последующим чтением. Но включать его «наугад» во всех сценариях не следует: сначала установите, что проблема действительно в порядке операций.

Быстрая таблица: симптом, вероятная причина, проверка

СимптомЧто чаще проверять сначалаБезопасное действие
Сценарий вообще не стартуетВыключен сценарий; нет активного жёлтого триггераПроверить статус и один запускающий источник
Срабатывает вручную, но не от датчикаНет события, нет активного триггера, неверное условиеПроверить изменение характеристики и вложенные «Если»
Срабатывает только один разРежим ∞ и неизменившийся порог / состояниеУточнить смысл повторного запуска именно этого устройства
Срабатывает многократноЧастые отчёты датчика; ∞; петля обратной связиСопоставить события, убрать цикл, разделить команды
Не работает по времениЧасовой пояс, планировщик, ∞, расписаниеПроверить время хаба и состояние планировщика
Задержка ведёт себя странно«Один» против «Новый»; сброс; несколько задержекПроверить тип таймера и номер очищаемой задержки
Команда есть, устройство не реагируетСвязь Zigbee / MQTT / Modbus, шаблон, питание, блокировкаПроверить управление из интерфейса, статус связи и обратную связь

Что сохранить, если неисправность повторяется

Для сложной проблемы полезен небольшой пакет воспроизведения. Он позволяет отделить ошибку логики от неисправности оборудования, а инженеру — быстрее разобраться без удалённого доступа ко всему дому.

  • Версия Sprut.hub и тип оборудования, на котором он работает; указать Release или Beta.
  • Название неисправного сценария и обезличенный скриншот его блоков и настроек.
  • Точная дата, время и последовательность действий, при которых возникла ошибка.
  • Исходные и ожидаемые состояния датчиков, реле и виртуальных аксессуаров.
  • Временные системные уведомления и соответствующий фрагмент журнала отладки.
  • Архив логов, если он действительно нужен поддержке, после проверки приватной информации.
  • Описание уже выполненных проверок: ручное управление, статус устройства, триггер, условия, таймер.
Не публикуйте открыто пароли, токены ботов и API, внешние адреса, серийные номера, данные аккаунтов или резервные копии с учётными данными. Для консультации часто достаточно обезличенных фрагментов. Перед переходом с Release на Beta или переустановкой следует оценить риски для работающей системы и иметь резервную копию.

Частые вопросы

Почему Sprut.hub не запускает сценарий, хотя датчик работает?

Проверьте, включён ли сценарий и является ли нужный датчик активным триггером. Во вложенных блоках «Если» датчик может служить лишь проверкой условия. Затем проверьте остальные условия и режим «Одно из» или «Все сразу».

Где смотреть логи Sprut.hub?

В настройках веб-интерфейса откройте служебную отладку: там доступны сообщения в реальном времени. Архив можно скачать через меню с тремя точками и пункт «Скачать логи».

Почему сценарий срабатывает только один раз?

Одна из причин — выключенный значок бесконечности: повторный запуск может потребовать смены состояния или пересечения порога обратно. Проверьте фактическую последовательность событий и настройки конкретного блока «Если».

Почему уведомления отправляются многократно?

Часто причиной оказываются повторные сообщения датчика при включённом ∞, несколько активных триггеров или обратная связь, когда сценарий изменяет собственное запускающее устройство.

Чем отличается «Один таймер» от «Новый таймер»?

«Один таймер» продлевается при новом событии до завершения ожидания. «Новый таймер» создаёт параллельную задержку для каждого подходящего события, поэтому действия могут выполниться несколько раз.

Что означает жёлтый кружок в сценарии?

Он отмечает активный триггер. Без активного запускающего источника соответствующая ветка не стартует от изменения устройства; обычное условие само по себе не является событием запуска.

Может ли другой сценарий отменять действия первого?

Да. Два сценария способны последовательно посылать противоположные команды одному устройству. Сравните время действий и проверьте все сценарии и связи, управляющие этой нагрузкой.

Нужно ли включать последовательное выполнение?

Только при наличии понятной причины, например когда блок кода зависит от результата предыдущей записи характеристики. Это не универсальное исправление ошибок Zigbee и таймеров.

Поможет ли перезагрузка хаба?

Перезапуск иногда восстанавливает отдельные зависшие компоненты, но не исправляет неверные триггеры или логику. Сначала зафиксируйте время и сообщения неисправности, а после перезапуска проверьте причину и повторяемость.

Можно ли искать ошибку на работающем отоплении или электрокране?

Для критичных систем лучше использовать безопасный стенд или виртуальные устройства. Штатные защитные цепи и ручное управление не должны зависеть только от экспериментального пользовательского сценария.

Можно ли отправить логи специалисту?

Да, но сначала проверьте архив и скриншоты на личные данные, сетевые адреса, токены и ключи. Не передавайте весь резервный архив, если достаточно минимального фрагмента журнала.

Диагностика и настройка Sprut.hub

Сценарий продолжает работать неправильно?

Поможем разобрать логику, проверить устройство и найти конфликтующие условия. Для предварительной оценки пришлите обезличенный скриншот сценария, версию хаба и описание ошибки. Возможна онлайн-консультация и настройка по согласованию.

Техническая основа: отладка, триггеры, элементы сценариев, задержки, выгрузка логов. Описанные меню соответствуют проверенной документации Wiki; названия пунктов могут меняться в новых сборках.