Фонари начали жить по чужому часу

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

Основным решением стало локальное расписание на реле. Для новой одноканальной линии с подходящим питанием и нагрузкой можно рассмотреть Shelly 1PM Gen4: у него есть локальный веб-интерфейс и расписания по восходу и закату. Если Shelly уже установлен и ручное управление работает, менять его только из-за часового сдвига не нужно — сначала исправляют время и задания.
Диагностику строят в таком порядке:
- В
Settings → Geo Location And Time Zone(«Настройки → Местоположение и часовой пояс») указывают фактические широту и долготу объекта и выбирают его часовой пояс. Автоопределение оставляют только тогда, когда оно показывает те же данные. Для Gen2+ эти значения можно прочитать локально методомSys.GetConfig: в ответе должны быть заполненыlocation.tz,location.latиlocation.lon. - Часы устройства проверяют методом
Sys.GetStatus. Поляtimeиunixtimeне должны бытьnull, аlast_sync_tsпоказывает момент последней синхронизации. Если местное время отличается от часов телефона или поля не заполнены, расписание пока нельзя считать готовым: сначала восстанавливают доступ к серверу точного времени SNTP/NTP. - В разделе
Schedules(«Расписания») создают два отдельных задания на все нужные дни. Первое используетSunset(«Закат») и локальное действиеControl Output: On(«Установить выход: включено»). Второе используетSunrise(«Восход») и действиеControl Output: Off(«Установить выход: выключено»). - Только после этого добавляют небольшое смещение под реальный двор. Оно отвечает на вопрос «насколько темно должно стать», а не исправляет часовой пояс. В расширенном расписании Gen2+ это выражения вида
@sunset+15mи@sunrise-15m; конкретное число подбирают по условиям участка.
Перед первым запуском открывают список заданий и проверяют, что оба включены, относятся к нужным дням и вызывают именно Switch.Set с состояниями on: true и on: false. На Gen2+ тот же список возвращает Schedule.List, а Schedule.Eval позволяет вычислить предыдущий и следующий запуск для заданного выражения. Это полезнее, чем ждать вечера после каждой правки.
Сезонное время вручную к офсету не добавляют. Расписание работает в настроенном часовом поясе устройства и само учитывает правила этой зоны. В регионах с переводом часов запуск внутри пропущенного весеннего часа не выполняется, а в повторяющемся осеннем часу выполняется один раз. Поэтому ровный сдвиг на час — повод проверить зону и часы, а не повод навсегда прибавить ещё один час к закату.
Журнал показал, где терялась команда
Даже после проверки времени в таком обращении остаётся вторая часть проблемы: иногда команда не просто приходит позже, а не выполняется совсем. Здесь помогает разделение по месту исполнения. Одинаковое «свет не включился» имеет разные причины в локальном расписании, облачном сценарии и внешнем контроллере.
Таблицу можно прокрутить по горизонтали.
| Где рождается команда | Что проверить | Что считать нормальным результатом |
|---|---|---|
| На самом Shelly | Schedule.List, текущее время, включённое задание, правильные дни и действие | Задание есть, следующий запуск рассчитан, после события выход получил явное состояние «включено» (ON) или «выключено» (OFF) |
| В Shelly Smart Control или другом облачном сценарии | Условия сценария, журнал события и интернет-связь устройства | В журнале есть событие в ожидаемую минуту, а устройство было доступно облаку |
| В Home Assistant, на сервере или в скрипте | Доступность локального IP, поколение API, URL, параметры, авторизацию и HTTP-ответ | Контроллер получил успешный ответ, а Switch.GetStatus показывает требуемое состояние выхода |
Следующий шаг — открыть локальную страницу Shelly из той же Wi‑Fi-сети. Если она доступна и ручная команда оттуда меняет выход, задержку внешнего сервиса не нужно приписывать реле. Затем сверяют Activity log («Журнал активности»): он показывает дату, время и тип включения или выключения. Запись в правильную минуту при последующем обратном переключении указывает уже не на часы, а на вторую команду.
Поэтому рядом с расписанием проверяют Timers («Таймеры»), Actions («Действия») и автоматику внешнего контроллера. Например, Auto off («Автоматическое выключение») может погасить свет вскоре после корректного включения, а второй сценарий — вернуть прежнее состояние. Временное отключение одного источника команд помогает увидеть, исчез ли конфликт; после проверки его либо удаляют, либо задают непересекающиеся условия.
Внешняя команда добавляет ещё одну развилку. У первого поколения Shelly локальное включение реле выполняется запросом вида /relay/0?turn=on, а включённая защита использует Basic HTTP authentication — базовую HTTP-аутентификацию. У Gen2+ — Plus, Pro, Gen3 и Gen4 — штатный метод другой: /rpc/Switch.Set?id=0&on=true, а при включённой защите HTTP использует Digest authentication — проверку запроса по хешу SHA‑256. Неверный путь, номер канала, строка "true" вместо логического true в JSON или ответ 401 Unauthorized («Не авторизован») означают не нестабильную автоматику, а запрос, который не выполнился.
Перед отправкой команды внешний контроллер может запросить /shelly, определить модель и поколение, а затем применить документированный метод. В журнале самого контроллера стоит сохранять время запроса, адрес, параметры, код ответа и тело ошибки. Пароль туда записывать не нужно. Такой журнал отделяет сетевую задержку от неправильного метода и от ситуации, когда запрос принят, но другой сценарий сразу изменил выход.
Резерв оставили простым и предсказуемым

После проверки основного пути нужен не второй «умный» сценарий, а понятный временный резерв. Фиксированная команда On позже ожидаемого заката доводит выход до включённого состояния, а команда Off после ожидаемого восхода — до выключенного. Конкретные часы выбирают по местному диапазону восходов и закатов; универсального времени для всей России нет.
Резерв отправляет именно состояние, а не Toggle («Переключить»). Повторное On оставит уже включённый свет включённым, тогда как Toggle погасит его. При этом фиксированное расписание на том же Shelly не спасает от неверных часов, потери питания или остановки самого устройства: оно страхует только ошибку расчёта либо настройки солнечного события.
Отдельно выбирают поведение выхода после восстановления питания в Action on power on («Действие при включении питания»). Для декоративного света безопаснее может быть Turn OFF («Оставить выключенным»), а для освещения входа — Restore last known state («Восстановить последнее состояние»); универсального варианта здесь тоже нет. Критерий простой: нужно заранее решить, что хуже для конкретной линии — неожиданное включение или темнота, — и выбрать состояние осознанно.
Настройка считается завершённой только после двух последовательных событий. Вечером нужно дождаться включения, сверить минуту в журнале и убедиться, что загорелись сами фонари, а не только изменился статус в приложении. Утром тем же способом проверяют выключение. После этого временный резерв можно оставить как страховку с понятной ролью или удалить, чтобы два расписания не усложняли дальнейшую диагностику.
Солнечное расписание становится предсказуемым не после большого офсета, а после трёх точных настроек: места, часового пояса и синхронизированных часов. Когда локальная команда, облако и внешний API разведены по разным проверкам, сдвиг на час перестаёт быть загадкой.