Главная работа недели — дом начал превращаться из набора отдельных сценариев в систему, которую можно читать и проверять. Когда логика живет только внутри Sprut, любой конфликт приходится искать вручную: один сценарий включает подсветку, другой через секунду выключает, третий считает это дежурным светом, четвертый — эконом-режимом. Теперь сценарии выгружаются в Obsidian, связываются с устройствами и конфликтами, а спорные места можно смотреть как карту, а не как длинный список загадочных ID.
Зачем понадобилась карта сценариев
На этой неделе снова проявилась типичная проблема большого умного дома: сценарии могут быть правильными по отдельности, но конфликтовать вместе. В бане это было особенно заметно на подсветках. Эконом-режим должен включать минимальный свет по присутствию, а жилой режим и дежурные сценарии должны управлять своими устройствами отдельно. В реальности несколько сценариев писали в одни и те же каналы.
Самый понятный пример — портал и коридорная подсветка. Сценарий дежурного света управлял порталом как своим устройством, а эконом-сценарий бани тоже пытался использовать тот же портал по движению. Для коридора была похожая история: входной сценарий и ночной эконом-сценарий пересекались на одной подсветке. В результате дом мог выглядеть так, будто “сам передумал”: включил свет, затем другой сценарий вернул другое состояние.
Исправление сделали не вслепую. Сначала собрали карту активных пересечений, затем развели владельцев по режимам. Для сценариев #34 и #3 добавлены условия, запрещающие им писать в портал и коридорную подсветку, когда баня находится в эконом-режиме. Эконом-логика теперь владеет этими устройствами в экономе, а дежурные и входные сценарии не спорят с ней в тот момент, когда не должны.
Obsidian стал рабочей памятью дома
Отдельный шаг — перенос сценариев в Obsidian. Идея простая: если у дома десятки сценариев, их нужно видеть не только в интерфейсе Sprut, но и как документацию. Для этого появился экспорт сценариев, устройств, режимов и конфликтов в отдельную ветку хранилища. Obsidian показывает связи между страницами, поэтому становится видно, какие сценарии используют один и тот же канал, какие режимы пересекаются и где нужно смотреть внимательнее.
Это не декоративная база знаний. В ней уже есть рабочие задачи: проверить конфликт по порталу, проверить коридорную подсветку, разобрать ошибку сценария #65, дописать человеческие объяснения к режимам бани и настроить ежедневное обновление экспорта. После этого сценарии можно обсуждать предметно: не “почему опять горит не то”, а “какой сценарий владеет этим устройством в этом режиме”.
Параллельно стало понятно, что не все плагины Obsidian одинаково полезны. Один из подключенных плагинов подвесил запуск рабочего пространства, и его пришлось убрать. В правилах Codex теперь зафиксировано: для этой базы оставляем простые markdown-связи, Obsidian Git, Codex Bridge и Vault Agent, а тяжелые экспериментальные плагины не включаем без необходимости.
Домашняя wiki теперь живет в Git
Важная часть этой работы — домашняя wiki стала не просто папкой с заметками, а версионируемой базой знаний. Obsidian-хранилище лежит в Git, поэтому изменения сценариев, устройств, правил и рабочих задач можно отслеживать по истории, а не держать только в памяти текущего диалога. Это особенно важно после нескольких длинных тредов, когда контекст переполняется и часть решений легко потерять.
Теперь у дома есть понятное место для инженерной памяти: страницы сценариев, устройства, режимы, конфликты, рабочие задачи и отчеты Codex. Git здесь нужен не для красоты, а как страховка от хаоса: если экспорт сценариев сломался, плагин Obsidian повел себя неправильно или агент записал лишнее, можно увидеть, что именно изменилось, и не гадать по ощущениям.
Для Павла это меняет формат работы. Вместо того чтобы каждый раз заново объяснять сложную логику бани, приточки или света, можно открыть домашнюю wiki и посмотреть текущее правило: какой сценарий за что отвечает, какие есть исключения, какие конфликты уже разобраны и какие задачи еще висят. Это превращает умный дом из набора живых скриптов в документированную систему.
Удаленный доступ перестал быть “только картинкой”
Еще одна важная бытовая история недели — Codex Live на панели в бане. Сначала noVNC открывался, но за ним не было настоящего VNC-сервера. Панель показывала страницу, а подключаться было не к чему. Затем VNC подняли как сервис Windows, проверили порт 5900, noVNC на 6082 и добавили это в runtime health check.
После этого выяснилась вторая проблема: картинка была, курсор был, но клики и клавиатура не доходили. Это хуже, чем полностью сломанный доступ, потому что выглядит почти рабочим. Исправление свели к нормальному полному доступу: noVNC открывается не как iframe, а напрямую; в ссылке и обязательных настройках закреплен не view-only режим; пароль полного управления берется из локального `.env`; health-check проверяет не только страницу noVNC, но и VNC backend.
Практический смысл простой: если Павел в бане, но микрофон или управление находятся в доме, панель должна давать реальный рабочий доступ, а не просто изображение рабочего стола. На этой неделе этот контур стал ближе к нормальному инструменту, а не к аварийному костылю.
Hermes научили смотреть камерами
В Telegram у Hermes была отдельная проблема: он мог отвечать странно, терять кодировку и не умел делать то, что раньше делал OpenClaw, — отправлять свежий снимок с камеры. Это исправили на уровне маршрутизации команд. Теперь запросы вроде “покажи 160”, “фото cam_165” или “где мои собаки” обрабатываются как камерные команды до общего роутинга по умному дому.
Камеры получили понятные алиасы: двор, вход, река, беседка, собаки. Для поиска собак Hermes отправляет серию снимков с нескольких камер, а не один случайный кадр. В `smart_camera.py` дополнительно учтен `auth_hint` из реестра камер, поэтому проблемные камеры с другой схемой авторизации тоже стали сниматься корректно.
Это важное отличие от обычного “бот включил свет”. Telegram становится глазами дома. Если надо быстро проверить двор, вход, реку или будку, не нужно открывать отдельную систему видеонаблюдения. Можно попросить Hermes прислать кадр, а потом уже решать, нужно ли вмешиваться.
Панель получила MQTT Explorer
Еще один диагностический инструмент недели — MQTT Explorer в панели. Павел показал мобильное приложение, где хорошо видно дерево топиков, и эту идею перенесли в домашнюю панель. Теперь в основной и мобильной версии есть отдельный раздел MQTT Explorer: поиск, фильтр по свежести, дерево топиков и краткие значения.
Сделано это аккуратно: панель не создает второго постоянного подписчика на брокер, а читает накопленное состояние из локальной истории, которую уже ведет `mqtt_logger`. Это снижает риск вмешаться в рабочий MQTT-контур и одновременно дает удобный способ смотреть, что реально публикуется: `keen`, `Sprut`, устройства, состояния и свежесть сообщений.
Для обслуживания дома это полезнее, чем кажется. Когда устройство “не отвечает”, сначала нужно понять, есть ли вообще данные в MQTT, когда они обновлялись и какой payload приходит. Теперь часть такой диагностики можно делать из панели, без отдельного приложения на компьютере.
Ручные режимы и погодные правила стали строже
По приточке и вытяжке на этой неделе стало ясно, что ручное управление должно быть настоящим ручным управлением. Если Павел выключает приточку с панели, сценарий не должен тут же включать ее обратно. Для общей вытяжки после 19:00 добавлен смысл ручного окна: если включить ее вручную вечером, автоматика не должна мгновенно погасить команду, а должна дать час работы.
По охлаждению дома добавлено правило для жарких выходных: если в субботу или воскресенье датчик присутствия несколько раз подтверждает, что люди дома, кондиционирование не должно выключаться только потому, что кто-то вышел на улицу на пару часов. Дом не успевает остывать и потом встречает жарой. Теперь эта ситуация описана как отдельный режим поведения, а не как исключение “на словах”.
Погодный контур тоже продолжает развиваться. Open-Meteo сейчас показывает низкий риск полива на ближайшие сутки: 0.0 мм за 24 часа, 0.1 мм за 48 часов и 1.1 мм за 72 часа. Weathercloud продолжает давать домашнюю станцию и избранные станции вокруг. Для будущих поливов это значит, что решение “поливать или ждать дождь” будет опираться не на один мокрый датчик, а на прогноз и соседние наблюдения.
Что дальше
Главный следующий шаг — не просто руками делать выпуск после пропуска, а убедиться, что понедельничная автоматизация реально выполняется. В системе уже есть cron для еженедельного отчета, но 1 июня в 20:00 он не дал результата. Значит, надо проверить не только наличие правила, но и факт запуска, окружение, доступ к workspace и доставку результата.
По дому ближайшая практическая работа понятна: довести Obsidian-экспорт до ежедневного обновления, закрыть оставшиеся конфликты сценариев бани, проверить стабильность Hermes в Telegram, добавить в панель избранные MQTT-топики и продолжить превращать ручные команды в правила с понятным сроком действия. Дом становится сложнее, поэтому главный выигрыш недели — не новая кнопка, а появление нормальной карты того, кто чем управляет.
