Неделя получилась не про красивые сценарии, а про надежность. Дом снова показал: если автоматика не умеет объяснять свои действия, не имеет ручного приоритета и зависит от одного локального компьютера, она быстро превращается из помощника в источник раздражения.
Главный технический вывод
В умном доме нельзя считать сценарий рабочим только потому, что он один раз включил нужное устройство. Рабочий сценарий должен выдерживать пропадание связи, ручное вмешательство, перезапуск контроллера, пасмурную погоду, задержки датчиков и ситуацию, когда хозяина нет дома.
На этой неделе сразу несколько проблем уперлись в один принцип: автоматика должна иметь понятный приоритет. Ручное включение не должно тут же отменяться сценарием. Аварийное сообщение не должно превращаться в спам. Охлаждение не должно включаться, если дом пустой. Свет не должен загораться по часам, если на улице еще светло.
Отчет в понедельник не появился сам
Понедельничный дайджест должен был приходить в 20:00. На практике обнаружилось, что в системе был настроен только скрипт-напоминание: он пишет в Telegram, что пора подготовить черновик, но не создает статью, не делает картинки и не публикует draft в WordPress.
Это отдельная ошибка процесса. Напоминание не равно автоматизация. После этого выпуска нужно заменить reminder на реальную задачу: собрать события недели, создать локальный черновик, подготовить Telegram-превью, приложить картинки и только после этого ждать одобрения на публикацию.
Telegram и Hermes: мост стал важнее, чем казалось
Продолжился переход от OpenClaw к Hermes. Причина простая: Telegram должен быть не игрушечным ботом “включи-выключи”, а нормальным удаленным каналом к агенту. Если Павел пишет с телефона, сообщение должно попадать в рабочий контекст, а ответ должен возвращаться обратно без потери смысла и кодировки.
Проблема проявилась на бытовых вопросах: “какая температура там, где я” и “что включено” бот воспринимал как отдельные фразы без контекста. Для дома это недостаточно. Если агент уже определил, что активное присутствие на кухне, следующий вопрос про температуру должен относиться к кухне, а не падать с ошибкой “ничего не найдено”.
Вывод: Telegram-мост нужно развивать как диалоговую оболочку с памятью последней зоны, последнего устройства и последнего инженерного запроса. Иначе мобильный доступ есть формально, но управлять домом через него неудобно.
Приточка, охлаждение и панель управления
Главная инженерная боль недели — приточная установка основного дома. Появился летний режим, компрессор, охлаждение, ручная панель CAREL и вопрос: кто главный. Если пульт выставляет одно, Sprut пытается записать другое, а локальный сценарий третье, установка начинает дергаться.
Важная практическая идея: не ломать то, что уже работало зимой и в межсезонье. Нужно не заменить всю старую логику, а добавить поверх нее летний контур охлаждения. Приоритеты должны быть такими: ручной режим с панели выше автоматики, отсутствие людей в доме выключает активное охлаждение, ночной режим ограничивает скорость, а защита от холодного притока остается обязательной.
Отдельный вывод по надежности: управление критичным климатом не должно зависеть только от компьютера, который может уснуть, зависнуть или потерять связь. Для базового режима Sprut должен оставаться главным устойчивым контуром, а локальный агент должен добавлять аналитику и удобство, но не быть единственной точкой управления.
Бассейн включался слишком рано
Сценарий “Бассейн вечер” оказался устроен слишком примитивно: включить в 20:00, выключить в 23:00. Весной и летом это неправильно, потому что в 20:00 на улице еще может быть светло.
Логика изменена: теперь бассейн включается только в окне 20:00–23:00 и только если датчик “Дорога свет” показывает настоящую темноту, ниже 5 люкс. Выключение в 23:00 оставлено без условий, чтобы свет гарантированно гас.
Это хороший пример общей проблемы. Таймеры удобны зимой, но плохо работают летом. Для уличного света основным условием должен быть не час на циферблате, а реальная освещенность с гистерезисом.
HiTE PRO, HomeKit и два моста
После сброса и перепривязки HiTE PRO стало окончательно понятно: два сервера HiTE PRO — это два разных HomeKit-моста с разными кодами. Нельзя считать, что один PIN покрывает оба устройства. Особенно это важно для навеса, дороги, реки и других уличных реле, которые были разнесены между серверами.
Практический вывод: все HiTE PRO устройства нужно вести не “по названию”, а по связке сервер, серийный номер, HomeKit-мост, ID в Sprut и физическое назначение. Иначе после очередной перепривязки сценарии начинают ссылаться на старые или похожие устройства.
Шторы, люксы и дребезг
Штора в большой спальне снова начала ездить туда-сюда на облаках. Это типичная ошибка сценариев по освещенности: если есть один порог, устройство дергается вокруг него. Для штор нужен диапазон: закрывать при одном высоком уровне света, открывать только при заметно более низком, плюс задержка по времени.
Такой же принцип теперь применим и к бассейну, и к уличному свету: не реагировать на каждое мгновенное значение, а работать по устойчивому состоянию.
Энергопотребление и панели
Начали разбирать реальные нагрузки. Например, приточная установка не может честно отображаться как 35 Вт, если по паспортным данным она потребляет около 750 Вт. Значит, панель должна различать измеренные значения и расчетные паспортные нагрузки.
Появился план разделить мониторинг на три части: основной дом, баня и прочее — улица, беседка, сарай, будущий гараж. Это правильное направление. Пока все смешано в одной панели, трудно понять, где реально тратится энергия и какой сценарий влияет на конкретную нагрузку.
Mirtek/RadioAccess как быстрый источник общей мощности пока не взлетел: софт не получил ответ от поставщика данных. Заказ Shelly выглядит более практичным путем. Если удастся снять три фазы отдельно, можно будет сравнивать расчетную нагрузку сценариев с реальным потреблением.
Что делаем дальше
Первое — превратить понедельничный отчет из напоминания в настоящую автоматизацию. Второе — довести Telegram/Hermes до нормального диалога с контекстом. Третье — разделить панель на дом, баню и прочее. Четвертое — привести сценарии света к датчикам освещенности с диапазонами, а не к жестким часам.
И отдельно остается большая инженерная задача по приточке: зафиксировать приоритеты ручного режима, Sprut, CAREL и агента. Без этого охлаждение летом будет повторять зимние проблемы отопления, только вместо холодного дома получится дом с лишним расходом энергии и обмерзающим теплообменником.
