Сценарий, который работал месяц, в один вечер перестаёт срабатывать — и найти причину сложнее, чем починить сломавшееся устройство. Устройство либо работает, либо нет, а сценарий состоит из триггера, условий, нескольких шагов и связи между всем этим, и отказать может любое звено. При этом приложение чаще всего показывает, что всё в порядке.
Это ключевая особенность темы, с которой стоит начать: надпись «выполнено» в истории сценария означает не то, что думает пользователь. Разбору этого посвящён отдельный раздел, и он здесь главный — без него диагностика идёт по ложному следу.
Разберём по порядку: что проверить в первые минуты, как читать журнал выполнения, где обрывается цепочка чаще всего и в каких случаях дело не в сценарии, а в устройстве. Если автоматика у вас срабатывает, но не вовремя или не так, как хотелось, — это другая задача, и мы разбирали её в материале про умные шторы, где собраны типичные ошибки проектирования сценариев.
Быстрая проверка за пять минут
Шесть проверок по порядку. Большая часть случаев закрывается здесь.
1. Запустите сценарий вручную. В приложении у любого сценария есть кнопка запуска. Если вручную он работает, проблема в триггере или условиях; если не работает — в самих шагах или устройствах. Это главная развилка, и она экономит всё остальное время.
2. Проверьте, включён ли сценарий. Переключатель рядом с названием мог быть выключен при обновлении приложения или случайным касанием. Выглядит сценарий при этом совершенно нормально.
3. Посмотрите, онлайн ли устройства, которые в нём участвуют. Серый значок или надпись об отсутствии связи у одного из них объясняет всё.
4. Проверьте хаб, если он есть: индикатор должен быть в рабочем состоянии, а в приложении хаб должен числиться онлайн.
5. Откройте историю или журнал сценария. Там видно, запускался он вообще или нет — это второй по важности вопрос после ручного запуска.
6. Перезапустите хаб и приложение. Хаб обесточить на минуту, приложение закрыть полностью и открыть заново. Банально, но на зависшем хабе сценарии не выполняются при полностью рабочем виде.
Дальше — по результату первых двух проверок. Если сценарий не запускался вовсе, смотрите разделы про триггеры и условия. Если запускался, но результата нет, начинайте со следующего раздела.
«Сценарий выполнен», а ничего не произошло
Это главный разбор материала и причина, по которой диагностика сценариев идёт труднее, чем кажется.
Что на самом деле означает отметка об успешном выполнении. Система отчитывается об отправке команды, а не о её исполнении. Хаб или облачный сервис формирует команду, передаёт её устройству и помечает шаг успешным по факту того, что команда ушла. Дошла ли она, выполнило ли её устройство и в каком состоянии устройство оказалось — отдельный вопрос, который система задаёт не всегда.
Почему это сделано именно так. Опрос состояния каждого устройства после каждого шага сильно замедлил бы выполнение и нагрузил сеть: сценарий из шести шагов превратился бы в двенадцать обращений с ожиданием ответа. Поэтому значительная часть систем работает по принципу «отправил и пошёл дальше», а состояние подтягивает потом, в фоновом режиме и с задержкой.
Что из этого получается на практике. В журнале сценарий отмечен выполненным, все шаги зелёные, а свет не включился. Пользователь видит противоречие и начинает искать ошибку в сценарии, которой там нет: сценарий действительно сделал всё, что должен был, — отправил команды. Не исполнил их получатель.
Производитель при этом формально не обманывает. Отметка относится к выполнению сценария, а не к состоянию устройств, и это корректно: сценарий — это последовательность команд, и она выполнена. Просто пользователь читает её как подтверждение результата, и в интерфейсе эта разница почти никогда не объясняется.
Как проверить, что происходит на самом деле:
• Сверяйте состояние устройства, а не статус сценария. Откройте карточку устройства: показывает ли она «включено», если сценарий должен был включить. Расхождение — это и есть ответ.
• Потяните список устройств для обновления. Состояние в приложении кэшируется, и в карточке может висеть прошлое значение. Принудительное обновление показывает настоящее.
• Отправьте команду вручную из карточки устройства. Если вручную тоже ничего не происходит, вопрос не к сценарию, а к устройству или связи.
• Обратите внимание на частичное выполнение. Самый частый случай: три шага из пяти сработали. Это почти всегда признак того, что одно из устройств недоступно, а не ошибки в логике.
• Ищите подтверждение состояния в настройках системы. У части хабов есть режим с проверкой результата: он медленнее, но честнее. Если такая опция есть, для критичных сценариев её стоит включить.
• Не доверяйте зелёным галочкам при разборе. Пока вы не увидели изменившееся состояние устройства, считайте, что шаг не выполнен.
Журнал выполнения: куда смотреть в первую очередь
Журнал есть почти у всех систем, но лежит он неочевидно — в настройках сценария, в разделе истории или в свойствах хаба.
1. Найдите запись о нужном времени. Отсутствие записи — важнейший результат: сценарий не запускался вообще, и дальше нужно разбираться с триггером.
2. Посмотрите, что стало причиной запуска. Хорошие журналы пишут, какое событие сработало. Если причина не та, которую вы ожидали, сценарий запустил другой триггер.
3. Проверьте, не был ли сценарий прерван условием. Записи вида «условия не выполнены» или «пропущено» означают, что триггер сработал, а разрешение не прошло.
4. Сравните число шагов в журнале и в сценарии. Меньше шагов в записи — выполнение остановилось в середине.
5. Обратите внимание на время между шагами. Разрыв в несколько секунд там, где задержки нет, означает ожидание ответа от устройства.
6. Поищите повторные записи. Сценарий, который за минуту запустился шесть раз, обычно зацикливается — об этом ниже.
Если журнала в вашей системе нет вовсе, его роль выполняет грубый, но рабочий приём: соберите тестовую копию сценария, в которой первым шагом включается заметная лампа, а дальше идут остальные шаги. Лампа — это индикатор запуска, по которому видно, доходит ли дело до выполнения.
Триггер не сработал: время, датчик, присутствие
Если сценарий не запускался, причина здесь. Про выбор правильного триггера мы писали отдельно, здесь — только поиск неисправности.
• Время на хабе и часовой пояс. Самая частая причина из всех. Сбившееся время сдвигает все сценарии по расписанию, а после смены прошивки или переезда часовой пояс иногда сбрасывается.
• Город или геопозиция не указаны. Сценарии по восходу и закату без геопозиции не работают вообще или считаются для чужого города.
• Батарейка датчика. Датчик с подсевшей батарейкой перестаёт отправлять события раньше, чем начинает показывать низкий заряд. Проверяется по дате последнего события в карточке датчика.
• Датчик онлайн, но события не идут. У беспроводных датчиков бывает потеря привязки без пометки офлайн: карточка выглядит нормально, а последнее событие было неделю назад.
• Геозоны и разрешения на телефоне. Триггер по прибытию домой ломается от отключённого доступа к геопозиции, от режима экономии заряда и от запрета фоновой работы приложения. Это не проблема умного дома, но выглядит именно так.
• Триггер по подключению телефона к домашней сети перестаёт работать после смены имени сети или пароля — связь между сценарием и сетью приходится пересоздавать.
• Датчик стоит не там, где нужно. Датчик движения, который перестал ловить проход, мог быть сдвинут при уборке на несколько сантиметров.
Где живёт сценарий: хаб или облако
От ответа зависит, что именно у вас сломалось, и ответ не всегда очевиден.
• Локальный сценарий выполняется в хабе и работает без интернета. Если при пропаже сети автоматика продолжает работать, сценарий локальный.
• Облачный сценарий выполняется на сервере производителя. Без интернета он не работает, и при проблемах на стороне сервиса тоже.
• Смешанный случай встречается чаще всего: триггер обрабатывается локально, а одно из устройств управляется через облако. Такой сценарий ломается наполовину, и это объясняет частичное выполнение лучше всего остального.
• Как проверить. Отключите интернет на роутере на минуту, не выключая сам Wi-Fi, и запустите сценарий вручную. Что сработало — локальное, что нет — облачное.
• Устройства разных производителей в одном сценарии почти всегда означают облачную связку: обмен идёт через серверы, и любая из сторон может его прервать.
• Про выбор между локальной и облачной схемой мы рассуждали в материале про умные шторы, где это разобрано как решение при проектировании. Здесь важно другое: при диагностике нужно знать, какая схема у вас уже есть.
Устройство недоступно или спит
Вторая по частоте причина после триггера, и она объясняет большинство случаев частичного выполнения.
• Устройство в офлайне, но помечено онлайн. Состояние обновляется с задержкой, и в карточке висит старое значение. Потяните список для обновления.
• Питание выключателем. Умная лампа, обесточенная настенным выключателем, из сети исчезает — и сценарий включить её не может. Самая обидная причина, потому что ищут её последней.
• Устройство на батарейках экономит энергию. Такие устройства спят между событиями и просыпаются по расписанию, поэтому команда может ждать пробуждения. Задержка в этом случае нормальна, а отсутствие реакции — нет.
• Слабый сигнал в точке установки. Проверяется переносом устройства ближе к хабу или роутеру на время проверки.
• Розетка отключилась по защите. Умные розетки с защитой от перегрузки уходят в отключённое состояние и не всегда об этом сообщают.
• Про то, почему устройства теряют связь с сетью, у нас есть отдельный разбор — здесь мы в сетевую часть не углубляемся, нас интересует только факт недоступности в момент выполнения.
Условия, которые тихо блокируют выполнение
Условие отличается от триггера тем, что оно ничего не запускает, а только разрешает или запрещает. Именно поэтому его отказ выглядит как полное отсутствие реакции.
• Условие присутствия. Сценарий с проверкой «кто-то дома» не выполнится, если система считает, что дома никого нет, — а считает она по геопозиции телефона, которая могла перестать обновляться.
• Ночной режим или режим сна. Включённый однажды вручную режим тишины блокирует часть автоматики и остаётся включённым.
• Условие по дням недели. Сценарий «только в будни» в праздничный понедельник не сработает, и это не ошибка.
• Условие по состоянию другого устройства. Если оно офлайн, условие не может быть проверено — и часть систем в этом случае считает его невыполненным.
• Режим «дом», «отпуск», «гости». Сценарии часто привязаны к режиму дома, и забытый режим отпуска выключает половину автоматики.
• Условие по погоде. Берётся из внешнего сервиса, и при недоступности данных условие не выполняется.
• Проверка простая: временно уберите из сценария все условия, оставив триггер и шаги. Заработало — дело в условии, и остаётся вернуть их по одному.
Приоритеты, зацикливание и ручное управление
Когда сценариев становится больше трёх, они начинают влиять друг на друга. Эти случаи выглядят самыми загадочными, а объясняются просто.
• Сценарий сработал, но другой тут же вернул всё назад. В журнале оба отмечены выполненными, и результат виден только последний. Ищите сценарии, в шагах которых участвует то же устройство.
• Ручное управление отменяет автоматику. Многие системы запоминают, что человек тронул устройство вручную, и на время перестают им управлять автоматически. Логика полезная, но неочевидная, и срок у неё свой у каждой системы.
• Зацикливание. Сценарий меняет состояние устройства, это становится триггером для второго сценария, а тот возвращает всё обратно. Признак — серия записей в журнале за несколько секунд. Лечится добавлением условия, которое разрывает кольцо.
• Блокировка повторного запуска. Часть систем не запускает сценарий, пока предыдущий запуск не завершён, а он может висеть из-за недоступного устройства.
• Длинные задержки внутри сценария. Шаг с паузой в десять минут держит сценарий в работе всё это время, и новые запуски в этот период игнорируются.
• Про спор двух сценариев по времени как ошибку проектирования мы писали отдельно; здесь речь о диагностике уже собранной системы.
После обновления перестало работать
Отдельный сюжет: всё работало годами и перестало в один день без вмешательства.
1. Вспомните, не обновлялось ли приложение. Крупные обновления переносят сценарии в новый формат, и часть условий при этом теряется или выключается.
2. Проверьте прошивку хаба. Обновление хаба иногда сбрасывает часовой пояс и геопозицию — два параметра, от которых зависят все сценарии по времени.
3. Проверьте, не менялся ли аккаунт. Вход в другой аккаунт или выход из него оставляет устройства на месте, а сценарии делает недоступными.
4. Посмотрите разрешения приложения на телефоне после обновления системы телефона: геопозиция и фоновая работа часто сбрасываются именно там.
5. Проверьте прошивку самих устройств. Обновление устройства может поменять набор поддерживаемых команд, и шаг сценария перестаёт применяться.
6. Пересоздайте один сценарий с нуля в качестве проверки. Если новый работает, а старый нет, дело в формате старого, и остальные придётся пересобрать.
Когда дело в устройстве, а не в сценарии
Граница проходит по ручному управлению, и проверяется она за минуту.
• Команда из карточки устройства не работает — вопрос к устройству или связи, а не к сценарию. Дальше смотрите материал про потерю связи.
• Устройство реагирует с задержкой в десятки секунд — слабый сигнал или перегруженный хаб.
• Устройство самопроизвольно меняет состояние — ищите другой сценарий или расписание внутри самого устройства: у части приборов есть собственные таймеры, не видные в приложении умного дома.
• Устройство выпало из системы после сброса. Сброс к заводским настройкам стирает привязку, и все сценарии с этим устройством перестают работать молча.
• Замена устройства на такое же не возвращает сценарии: система видит новое устройство, и шаги приходится переназначать вручную.
• Устройство работает, но не той функцией. Шаг «включить» у многофункционального прибора может относиться к другому каналу или режиму, чем вы ожидаете.
Как не допустить повторения
Сценарии ломаются предсказуемо, и большая часть отказов предотвращается несколькими привычками.
1. Держите критичные сценарии локальными. Всё, что должно работать всегда, не стоит строить на устройствах разных производителей через облако.
2. Для важных сценариев включайте подтверждение состояния, если система это умеет. Медленнее, но без ложных отметок о выполнении.
3. Меняйте батарейки в датчиках по календарю, а не по предупреждению: раз в год для большинства датчиков.
4. Проверяйте часовой пояс и геопозицию после каждого обновления хаба. Две настройки, которые ломают больше всего сценариев.
5. Не управляйте вручную устройствами, которые ведёт автоматика, без необходимости — или знайте, на сколько ваша система после этого отключает автоматику.
6. Давайте сценариям понятные имена с указанием триггера. «Вечер по закату» вместо «Сценарий 3» — через полгода это сэкономит вечер поиска.
7. Добавляйте ручной запуск каждому сценарию. Кнопка-сцена или голосовая команда позволяет и проверить сценарий, и обойтись без него, когда автоматика встала.
8. Записывайте, что меняли. Короткая заметка с датой изменения избавляет от вопроса «а что сломалось месяц назад».
Чек-лист: по порядку сверху вниз
Если нужен короткий порядок действий без чтения разделов.
1. Запустите сценарий вручную — это главная развилка.
2. Проверьте, включён ли сценарий переключателем.
3. Откройте журнал: есть запись о запуске или нет.
4. Записи нет — проверяйте триггер: время на хабе, часовой пояс, геопозицию, батарейку датчика, дату последнего события.
5. Запись есть, а результата нет — смотрите состояние устройств в их карточках, а не статус сценария.
6. Потяните список устройств для обновления состояния.
7. Отправьте команду вручную из карточки устройства.
8. Выполнилась часть шагов — ищите недоступное устройство и проверяйте, не управляется ли оно через облако.
9. Проверьте питание устройств настенными выключателями.
10. Уберите из сценария все условия, оставьте триггер и шаги.
11. Проверьте режимы дома: отпуск, ночной режим, режим тишины.
12. Поищите второй сценарий, который трогает то же устройство.
13. Серия записей за секунды — зацикливание, разрывайте условием.
14. Перестало работать после обновления — проверьте часовой пояс, геопозицию, разрешения приложения и пересоздайте один сценарий как тест.
15. Перезапустите хаб обесточиванием на минуту.
Итог
Диагностика сценариев отличается от диагностики устройства тем, что сломаться может любое звено цепочки, а приложение при этом показывает нормальную картину. Поэтому первые два действия всегда одни и те же: запустить сценарий вручную и открыть журнал. Ручной запуск отделяет проблему с триггером от проблемы с шагами, журнал отвечает, запускался ли сценарий вообще.
Главное, что стоит понимать про отметки о выполнении: система отчитывается об отправке команды, а не об её исполнении. Это корректно с её точки зрения — сценарий действительно сделал всё, что должен, — но для поиска неисправности бесполезно. Смотреть нужно на состояние устройства в его карточке, а не на зелёные галочки в истории.
И практический вывод, который снимает большую часть будущих проблем: всё, что должно работать всегда, лучше держать локальным и на устройствах одной системы, а в датчиках менять батарейки по календарю. Сценарий, собранный из устройств трёх производителей через облако, работает ровно до первого сбоя у любого из них.
Читайте также: Кофемашина течёт: причины и что делать
Автор публикации
Связал с техникой всю свою жизнь. В детстве дружил с магнитофонами, тетрисами, приставками Nintendo, затем SEGA Dreamcast, Sony Playstation 1/2, потом первый смартфон, первый компьютер, первый отремонтированный ноутбук. За всю жизнь в руках побывали сотни всевозможных девайсов. Сборки компьютеров с нуля, ремонт ноутбуков, тестирование смартфонов, планшетов и прочих гаджетов стали любимым делом жизни. Это вдохновение, стимул, источник энергии… это больше, чем просто хобби!
Сборщик ПК с 2011 г. Бывший копирайтер, создатель музыки в FL Studio.
С 2020 года начал вести сайт TopTechnika.ru, разочаровавшись в шаблонности и бесполезности контента по теме выбора техники. Финансовое образование, ищу максимальную выгоду от каждой покупки.
По любым вопросам и предложениям пишите мне <a href="https://t.me/toptechnika">в личку в Телеграм</a> или на нашу корпоративную электронную почту <a href="mailto:admin@toptechnika.ru">admin@toptechnika.ru.</a>
