Будут ли таймеры Shelly работать без интернета

Какие таймеры работают без интернета

Сначала разделите пять разных механизмов. Только после этого у вопроса «работает ли Shelly без интернета» появляется точный ответ.

Таблицу можно прокрутить по горизонтали.

Официальная поддержка Shelly прямо относит предварительно сохранённые на устройстве расписания, локальные HTTP-действия и скрипты к функциям, доступным без интернета. Там же облачные сценарии перечислены среди функций, которым интернет нужен.

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

Шаг 1. Найдите, где хранится автоматизация

Подключитесь к той же домашней сети Wi-Fi, что и Shelly, и откройте локальную страницу устройства по его IP-адресу. Адрес можно посмотреть в роутере или в информации об устройстве. Путь меню зависит от модели и прошивки, поэтому ищите функции по смыслу: Timer («Таймер»), Schedule («Расписание»), Actions («Действия») и Scripts («Скрипты»).

Дальше отдельно откройте All Scenes («Все сценарии») в Shelly Smart Control и список автоматизаций домашнего контроллера, если он есть. Одно и то же действие нередко оказывается настроено сразу в двух местах: например, локальное выключение через десять минут и облачный сценарий, который снова включает выход по своему условию.

В облачном сценарии перечитайте блок When («Когда») как полное правило. Состояние, выбранное как Condition («Условие»), только проверяется в момент запуска и само по себе не запускает сценарий; для старта нужен Trigger — событие запуска. Заодно сверьте активные дни, интервал времени и объединение условий через AND/OR — «И»/«ИЛИ».

Для чтения конфигурации можно использовать локальный API. Эти запросы ничего не переключают:

• на Gen2, Gen3 и Gen4 откройте http://IP-АДРЕС/rpc/Shelly.GetDeviceInfo; поле gen покажет поколение, а auth_en — включена ли авторизация;
• там же http://IP-АДРЕС/rpc/Schedule.List вернёт задания, сохранённые сервисом расписаний устройства;
• на Gen1 с релейным выходом откройте http://IP-АДРЕС/shelly, затем http://IP-АДРЕС/settings/relay/0; во втором ответе ищите auto_on, auto_off, schedule и schedule_rules.

Если браузер перенаправляет HTTP-запрос на HTTPS, используйте защищённый адрес. Такое поведение предусмотрено для части устройств с Shelly OS 2.0.0 и новее. Если запрос требует пароль, не отключайте защиту: правильную схему авторизации разберём на четвёртом шаге.

Шаг выполнен, когда вы можете закончить фразу: «Это правило хранится в устройстве / домашнем контроллере / Shelly Cloud». Если исполнителей оказалось несколько, до испытания временно отключите дубликаты.

Шаг 2. Проверьте локальный доступ и часы

Не выключайте роутер целиком. Отключите только его внешнее соединение — кабель провайдера или WAN-подключение — и оставьте Wi-Fi включённым. Затем снова откройте локальную страницу Shelly по IP-адресу.

Если страница открывается и состояние выхода обновляется, локальная сеть работает. Если нет, проблема не во внешнем интернет-канале: устройство потеряло Wi-Fi, изменился IP-адрес, телефон подключён к гостевой сети или роутер запрещает клиентам видеть друг друга. Пока локальный адрес недоступен, проверять облачный сценарий или таймер бессмысленно.

Для расписания на Gen2+ прочитайте http://IP-АДРЕС/rpc/Sys.GetStatus. Поля time и unixtime не должны быть null, а last_sync_ts показывает время последней синхронизации. Затем откройте http://IP-АДРЕС/rpc/Sys.GetConfig и проверьте location.tz — часовой пояс — и адрес сервера sntp, с которого устройство получает точное время.

Затем перезапустите Shelly при всё ещё отключённом интернете и повторите проверку часов. Это отдельное испытание: обрыв интернета у уже работающего устройства и запуск после потери питания — не одно и то же. Если после перезапуска время не определено, расписание по часам нельзя считать надёжным. Для критичного короткого автоотключения выбирайте локальный Auto off, а для автономного расписания обеспечьте доступный в домашней сети сервер времени и ещё раз проверьте ближайший запуск.

Шаг 3. Проведите тест с отключённым интернетом

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

1. Для расписания задайте ближайшее время с запасом в несколько минут. Для задержки включите выход с коротким Auto off, например на десять секунд.
2. Запишите ожидаемый результат: какое условие должно возникнуть, какой выход и в какое состояние перейдёт, когда это произойдёт.
3. Отключите WAN, но оставьте питание Shelly, роутер и Wi-Fi.
4. Дождитесь команды и наблюдайте саму нагрузку. Смена значка в приложении не доказывает, что реле или привод действительно изменили состояние.
5. Верните интернет и сопоставьте фактическое время с журналом действий.

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

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

Шаг 4. Сверьте событие, API и авторизацию

Сначала откройте Activity Log («Журнал действий») устройства или общий журнал Shelly Smart Control. Найдите нужное время и проверьте, записано ли включение или выключение. Отсутствие записи ещё не доказывает, что реле ничего не сделало: глубина журнала зависит от плана, устройство можно исключить из общего журнала, а при обрыве связи облачная история может остаться неполной.

На Gen2+ надёжнее одновременно прочитать локальный статус:

http://IP-АДРЕС/rpc/Switch.GetStatus?id=0

Поле output показывает состояние выхода, source — источник последней команды, а при активном таймере появляются timer_started_at и timer_duration. Поле tag, если его передал вызывающий клиент, помогает отличить одну интеграцию от другой. Для глубокой диагностики можно заранее включить локальные debug logs («отладочные журналы») и после воспроизведения открыть /debug/logs; по умолчанию эти журналы выключены.

Чтобы отделить сетевую задержку от ошибки правила, отправьте одну и ту же безопасную команду сначала на локальный IP, затем обычным внешним способом и запишите время. Быстрый локальный ответ при запоздавшей внешней команде указывает на участок до домашнего устройства — интернет, облако или внешнюю интеграцию. Если задерживается и локальный запрос, вернитесь к Wi-Fi, IP-адресу и настройкам роутера.

Поколения Shelly используют разные локальные API. Не подставляйте старый адрес в новое устройство и не меняйте тип значения на глаз. Таблица ниже относится к дискретному релейному выходу relay / Switch; для диммера, света или привода штор нужно выбрать компонент и метод из документации именно этого устройства.

Таблицу можно прокрутить по горизонтали.

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

Код 401 означает, что устройство запросило авторизацию. Для Gen1-реле клиент должен поддерживать Basic HTTP, для Gen2+ — Digest с SHA-256. Не устраняйте ошибку отключением пароля. Проверьте выбранную схему, имя пользователя, пароль и поддержку HTTPS вашим клиентом.

Если команда идёт не на локальный IP, а через Cloud API, это уже другой маршрут. В нём нужно проверить назначенный аккаунту сервер и актуальный auth_key — ключ доступа; после смены пароля ключ может потребовать обновления. Локальный метод Switch.Set и облачный адрес нельзя смешивать в одном шаблоне запроса.

Наконец, сверьте параметры самой команды. Для Gen2+ состояние on передаётся логическим значением true или false, задержка toggle_after — числом секунд, а id указывает точный канал. Запрос, который включил выход, но не передал задержку, не создал обещанный таймер: это ошибка команды, а не нестабильность Shelly.

Шаг 5. Уберите конфликт и задайте безопасное состояние

Оставьте включённым только одно правило и повторите короткий тест. Затем возвращайте остальные по одному: локальное расписание, локальный скрипт, правило контроллера, облачный сценарий. Так становится видно, какое из них отправляет вторую команду. Особенно часто конфликтуют локальный Auto off и расписание или сценарий, который вскоре снова включает выход.

Таблицу можно прокрутить по горизонтали.

Отдельно решите, что должно произойти после возвращения питания. На Gen2+ это задаёт initial_state, на Gen1 — default_state. Варианты вроде «выключить», «включить», «восстановить прошлое состояние» или «следовать входу» нельзя ранжировать без знания нагрузки. Для насоса или нагревателя безопасным может быть выключение, а для системы защиты от замерзания — другой заранее обоснованный режим. Выберите состояние по последствиям для конкретного оборудования и проверьте его отдельным контролируемым отключением питания.

Не считайте настенную клавишу гарантированным резервом при любом сбое. На Gen2+ параметры in_mode и in_locked определяют, управляет ли физический вход выходом напрямую. В режиме detached — «вход отделён от выхода» — нажатие лишь создаёт событие, которое ещё должен обработать скрипт, контроллер или другое правило. Проверка закончена только тогда, когда вы испытали именно настроенный режим входа и увидели ожидаемое состояние нагрузки.