1. Что это за система, если по фактам

Это не «умный дом на Home Assistant», а собственная реализация: человек написал её сам, от датчика до веб-панели. Масштаб уже не игрушечный — полтора десятка Zigbee-устройств, около 140 «живых» топиков, семь постоянно работающих служб, несколько скриптов по расписанию, своя база истории и панель управления с редактором правил.

2. Как она работает сегодня

То есть у каждого сообщения от датчика путь такой: брокер → Python-логгер → таблица «последнее значение» → (через секунду) PHP-движок прочитал → сравнил с порогом → отправил команду в брокер. Латентность — до секунды, потому что движок опрашивает базу циклом, а не получает данные событием.

Дополнительно рядом живёт вторая, независимая автоматика: cron-скрипты PHP.

3. Диагноз: где болит (10 пунктов)

Ниже — не «список страшного», а конкретные вещи, которые я бы менял, с указанием, почему это вообще проблема.

4. Главный вопрос: слушать брокер напрямую или через базу?

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

1. Транспорт/шина событий — за это должна отвечать MQTT. База тут лишнее звено.
2. Долговременная история и аналитика — за это отвечает база, и она нужна.
3. Настройка (правила, справочники, порогов) — тоже база, и это удобно: правила редактируются из панели.

Проблема текущей схемы в том, что первая роль тоже отдана базе. Уберём это — и всё встанет на место. (вот это и был главный вопрос гермес-агенту, надо настроиться и переделать все)

4.1. Что конкретно меняется

4.2. Что это даёт на практике

• Реакция «нажал — сразу щёлкнуло», а не «через секунду-другую». Для света и кнопок это заметная разница.
• База перестаёт быть узким местом. Запись — пакетами, пачками по несколько сотен значений раз в 10–30 секунд, в одной транзакции.
• Появляется место для правильной логики: выдержки, гистерезис, «если команда не подтвердилась — тревога». В циклическом опросе это всё делается криво, потому что движок не знает точно, что было до.
• Падение базы перестаёт быть отказом автоматики. Это важно: бэкап, миграция, OPTIMIZE TABLE, ручная правка — всё это сегодня на минуту ослепляет систему.

4.3. А это не менее надёжно? Честно про минусы

Надёжность не в «через базу» или «через брокер», а в том, что происходит при перезапуске и при потере связи. Прямая подписка добавляет три вопроса, и у каждого есть ответ:

Ещё один аргумент, который часто упускают: у текущей схемы проблема с перезапуском уже есть (пункт 5 диагноза) — отложенные действия и подтверждения теряются при рестарте. То есть «через базу» не даёт надёжности, которую якобы теряет прямая подписка. Переход на события позволяет эту дыру закрыть системно, а не затыкать страховочными правилами.

4.4. Вердикт

Движок правил → одна долгоживущая служба, которая подписана на zigbee2mqtt/# и держит состояние в памяти. База → только история и настройки, запись пакетами. Правило «включить/выключить» вычисляется на событии, а не по таймеру. Это и быстрее, и, если сделать аккуратно, надёжнее, чем сейчас.

Миграцию при этом можно сделать без «большого взрыва»: сначала поднять рядом новый движок, который только слушает и пишет в отдельный лог (что бы он сделал на каждом событии), неделю сравнить его решения с текущим, а потом переключить исполнение. Так делают и в больших системах.

Скелет такого движка (Python, asyncio + aiomqtt)

import asyncio, json, time, aiomqtt

STALE = 900            # данных нет 15 минут — считаем датчик пропавшим

class Engine:
    def __init__(self, client):
        self.c = client
        self.vals = {}      # топик -> (значение, время)
        self.modes = {}     # состояние автоматов: 'fish_heater' -> 'idle'/'heating'

    async def run(self):
        await self.c.subscribe("zigbee2mqtt/#")
        async for msg in self.c.messages:
            t = str(msg.topic)
            if t.endswith("/set"):        # эхо собственных команд не считаем данными
                continue
            try: data = json.loads(msg.payload)
            except ValueError: continue
            now = time.time()
            for k, v in (data.items() if isinstance(data, dict) else [(t, data)]):
                self.vals[f"{t}/{k}"] = (v, now)
                await self.on_value(f"{t}/{k}", v)

    async def on_value(self, topic, value):
        # пример: термостат как машина состояний, а не два правила с порогами
        if topic == "zigbee2mqtt/fish_reley_temp/temperature":
            t = float(value)
            mode = self.modes.get("fish_heater", "idle")
            if mode == "idle" and t < 23.0:
                await self.act("fish_power/set", {"state_l3": "ON"})
                self.modes["fish_heater"] = "heating"
            elif mode == "heating" and t > 25.0:
                await self.act("fish_power/set", {"state_l3": "OFF"})
                self.modes["fish_heater"] = "idle"

    def fresh(self, topic):
        v = self.vals.get(topic)
        return v is not None and time.time() - v[1] < STALE

    async def act(self, action_topic, payload):
        await self.c.publish(f"zigbee2mqtt/{action_topic}", json.dumps(payload), retain=False)

Обратите внимание на три вещи: команды публикуются только на смене состояния (никакого «долбления» каждую секунду), у каждого значения есть время, и «молчание датчика» становится обычным проверяемым условием. Плюс тот же процесс может писать историю пачками — тогда отдельный логгер вообще не нужен.

5. Как делать правильно: 12 принципов

1. Один владелец состояния. Не три места, а одно: движок. Всё остальное — производные (retained в брокере для восстановления, БД для истории).
2. Конвейер, а не «всё в одном». Вход (протокол), логика (правила), выход (актуаторы), история (запись), интерфейс (панель) — разные роли. Сегодня это частично выполнено, доводить до конца.
3. Событийная реакция вместо опроса. Опрос — только там, где нет событий (например, раз в 10 минут проверить, что службы живы).
4. Команды идемпотентны. «Включить то, что уже включено» не должно порождать новое событие и уведомление. Флаг «пропущено, состояние уже целевое» — хорошая идея, которую надо оставить и в новой схеме.
5. Каждая команда — с подтверждением. Опубликовали → ждём, что устройство сообщило новое состояние (в MQTT это приходит в тот же топик). Не пришло за N секунд — тревога, а не тишина.
6. Безопасное состояние по умолчанию. Связь потеряна → кран закрыт, нагреватель выключен, ничего не «остаётся как было». Fail-safe должен быть заложен в правила, а не в надежду.
7. Гистерезис и машины состояний вместо парных правил. Подробно ниже, но правило простое: «включить ниже X, выключить выше Y» — это один автомат с двумя порогами, а не два независимых правила.
8. Не привязываться к именам устройств. Правила должны ссылаться на роль («датчик влажности грядки»), а не на строку gorshok_smallone. Имя Zigbee-устройства меняется — правило ломается. Отображение «роль → топик» должно лежать в одном справочнике.
9. Секреты только в одном месте и с узкими правами. Отдельные учётки: «читатель» для панели, «движок» для чтения данных и записи команд, приложение — без прав менять схему БД. MQTT-ACL по топикам.
10. Ретенция как настройка, а не как побочный эффект. «Хранить 30 дней, агрегаты — год», реализовано партиционированием или отдельной таблицей агрегатов. Удаление десяти тысяч строк при каждой вставке — это не политика хранения.
11. Наблюдаемость по умолчанию. Здоровье, задержка реакции, число срабатываний, ошибки — и обязательное «тишина датчика» как отдельное состояние.
12. Всё под git. Конфиги, правила в виде файла (снимок таблицы автоматизаций), скрипты, юниты. Дамп базы — отдельно, по расписанию. Историю изменения правил хочется видеть: «кто и когда поменял порог».

6. Почему «два правила на один порог» воюют: гистерезис и машина состояний

Это самая частая логическая ошибка в самодельных домах, и в разбираемом проекте она была: правило «включить нагрев при температуре ниже 23» и правило «выключить при выше 25» — на первый взгляд правильная пара. Проблема в том, что реле физически одно, а решений о нём принимают два независимых потребителя, которые ничего не знают друг о друге. Стоит добавить третий (например, cron с усреднением за 15 минут) — и начинается «реле щёлкает не по правилам, а по моменту запуска скрипта».

Правильно — один автомат с состоянием:

состояние: idle | heating

idle       + температура < 23.0 (устойчиво 30 с)  → ON  → heating
heating    + температура > 25.0                   → OFF → idle
heating    + данных нет > 15 минут                → OFF → idle  (fail-safe)
любое      + ручная команда из панели             → принудительное состояние + тайм-аут

Отсюда сразу видны вещи, которых в паре правил не выразить: выдержка (устойчиво 30 секунд), поведение при пропаже данных, приоритет ручного управления. Всё это — состояние, а не условие, и хранить его надо вместе с решением, а не выводить заново из мгновенного значения.

7. Секреты, доступы и ACL

Исторически это была самая слабая часть, и её уже вылечили: секреты вынесены из кода в отдельные файлы с правами 640 root:www-data и 640 root:mazzick, у приложения урезаны права в БД, крон-скрипты перестали ходить в MQTT под учёткой администратора базы. Это стоит зафиксировать как правило и не разъехаться обратно.

Что добавить:

• ACL в брокере — сейчас, судя по конфигу, доступ определяется только паролем. Явный ACL по топикам закроет «движок читает всё, панель пишет всё»:

# /etc/mosquitto/acl
user iot_engine            # движок: читает всё, командует устройствами
topic read  zigbee2mqtt/#
topic write zigbee2mqtt/+/set

user iot_panel             # панель: только чтение + ручные команды
topic read  zigbee2mqtt/#
topic write zigbee2mqtt/+/set

user iot_logger            # логгер: только чтение
topic read  zigbee2mqtt/#

pattern write zigbee2mqtt/bridge/request/#   # служебные запросы — кому разрешено

• Закрыть анонимный слушатель 1884. Он нужен только внутри малины. Если он ещё и слушает на внешнем интерфейсе — это открытый брокер в локальной сети. Проверять одной командой: попытка подключиться без пароля с другого хоста должна падать.
• Разделить пароль панели и пароль SSH/MQTT. Если они совпадают, утечка одного = утечка всего.
• Правило для новых скриптов: пароль берётся только из /etc/iot/credentials.*, никаких литералов. В healthcheck — отдельная проверка, которая ищет в файлах реальные пароли (и её надо проверять «приманкой», иначе оn врёт).

8. Бэкапы и восстановление

Сейчас есть два скрипта, собирающие архив: дамп всех БД, конфиги zigbee2mqtt, mosquitto, nginx, systemd, cron. Это правильный набор. Чего не хватает:

1. Проверки восстановления. Бэкап без теста восстановления — это не бэкап, а надежда. Раз в квартал: развернуть на виртуалке, поднять, проверить, что панель отвечает и правила на месте.
2. Ротации. Сейчас в домашней папке лежат архивы по 190–700 МБ за разные месяцы и рядом выгрузки сайтов с хостинга — суммарно больше гигабайта, который к дому отношения не имеет. Нужна политика: последние 7 дневных, 4 недельных, 12 месячных, всё остальное удаляется автоматически.
3. Ключ Zigbee-координатора. Восстановление сети Zigbee — это в первую очередь сохранённый coordinator_backup.json из zigbee2mqtt. Без него вся сеть спаривается заново.
4. Снимок правил. Таблица automations — это тоже код. Хочется видеть её в git в виде файла (TSV/JSON), с диффом при каждом изменении из панели. Полчаса работы — и вопросы «кто поменял порог» закрываются навсегда.
5. Внешнее хранилище. Бэкап на той же малине спасает от ошибки, но не от смерти диска. Копия на NAS/в облако.

9. Наблюдаемость: чтобы дом сам сказал, что сломался

Здесь в проекте больше, чем в 90 % самоделок: внешняя проверка здоровья, ежечасный сторож с письмом и защитой от повторов, отдельная служба статистики аномалий. Что я бы добавил именно как «правильное»:

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

10. Если бы строил с нуля: три варианта стека

Честно: бо́льшую часть этого дома можно не писать самому. Но у самописного есть реальная ценность — понимание каждого узла и полный контроль. Поэтому варианты, а не один «правильный ответ».

Вариант A. Готовое ядро + своя логика (рекомендую большинству)

zigbee2mqtt + Mosquitto + Home Assistant (или Node-RED) + MariaDB/InfluxDB для истории. Всё, что сегодня делают вручную PHP-движок, панель и часть cron, уже есть: редактор автоматизаций, история, уведомления, мобильное приложение, интеграции. Самописное остаётся ровно там, где оно даёт пользу — специфические сценарии (аквариум, полив) и свои отчёты. Развёртывание в Docker Compose, бэкап — том плюс дамп БД.

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

Вариант B. Остаться самописным, но сделать правильно

Тот же стек, что есть, с заменой «база как шина» на «брокер как шина»: один Python-движок на событиях (asyncio + paho/aiomqtt), правила в YAML с версионированием, FastAPI для панели вместо PHP, SQLite или MariaDB только для истории, Docker Compose, git, pytest для логики правил, симулятор MQTT для тестов.

Плюсы: полный контроль, лёгкость на Raspberry Pi, тестируемость, отсутствие зависимости от больших фреймворков. Минусы: всё это надо поддерживать самому, и мобильное приложение придётся делать самому (или обойтись Telegram-ботом, что для дома обычно достаточно).

Вариант C. Гибрид (часто лучший на практике)

Ядро — готовое (Home Assistant / Node-RED), а критичные контуры — свои, с тестами: термостат аквариума, защита от заливания, отчёты. Zigbee остаётся в zigbee2mqtt (он и так лучший в своём деле), брокер один, история одна. Так снимается 80 % рутины и остаётся контроль над тем, что действительно важно.

11. План улучшений и чек-лист

Приоритеты

Чек-лист «правильный самописный умный дом»

• Состояние имеет одного владельца; база — не транспорт, а хранилище.
• Реакция на событие, а не опрос по таймеру.
• Команда с подтверждением; «не подтвердилось» — это тревога, а не тишина.
• Гистерезис и выдержки как состояние, а не как пара правил.
• Fail-safe на воду и нагрев, включая аппаратный.
• Явное состояние «нет связи» у каждого датчика.
• Один владелец на устройство: или правило, или скрипт — не оба.
• Секреты вне кода, узкие права, ACL по топикам.
• Ретенция истории задана явно.
• Бэкап есть, восстановление проверено, координатор Zigbee сохранён.
• Правила и конфиги в git; логика правил покрыта тестами на симуляторе MQTT.
• Раз в неделю приходит «отчёт о жизни», а не только письма о бедах.

Приложение: замеры на живой системе (30.09.2026, 11:05)

Через пару часов после публикации статьи появился доступ к малине, и я прогнал проверку по факту. Ничего не менял — только смотрел. Ниже цифры, которыми подтверждаются (или уточняются) тезисы выше.

Что подтвердилось на практике

• Одна реальная железная проблема: датчик протечки leak_bath — 50 % и 2400 мВ, это ровно порог «вышла из строя» для CR2032. Батарейку надо менять. Сторож при этом ведёт себя правильно: с 03:05 сообщает о ней раз в час в свой лог, но письмо отправил один раз и повторно не шлёт, пока состояние не изменится.
• На реле идёт одна команда на переключение, а не поток. Проверил за сутки по журналу: реально отправленных команд (то есть публикаций в MQTT) — 263 на весь дом, из них 119 приходится на ваш тестовый прогон правила ssss. По аквариуму: нагрев получил 2 команды за сутки (одна — 30.09 в 06:04, вторая — 29.09 вечером), повторов от механизма подтверждений — 0 за все 1198 записей журнала. Движок отправляет публикацию только в момент смены состояния: условие проверяется каждую секунду, но вторая публикация при неизменном значении не идёт — её держат три замка: смена значения триггера, cooldown_seconds (65 с у света, 3600 с у нагрева) и проверка «устройство уже в нужном состоянии» (такие записи в журнале помечены skipped=1 — команда не отправлялась вовсе, только строка в журнал).
• Свет в коридоре — это не дребезг, а нормальная работа. 107 реальных команд за сутки (54 включения и 53 выключения) = человек проходит по коридору примерно раз в 13 минут в рабочее время. Плюс 10 срабатываний, которые движок погасил сам как «уже выключено». Это правильное поведение, менять его не нужно.
• А вот в журнале действительно есть шум, и это настоящая проблема. Пока условие с выдержкой ждёт своё время, движок печатает строку «⏳ Условие выполняется уже N сек из 30» каждую секунду — за сутки таких строк 15 074. Это засоряет systemd-журнал (уже 77,6 МБ) и мешает искать настоящие события. Чинится одной правкой в движке: печатать строку на старте отсчёта и на его завершении, а не каждый тик.
• Аномалии выключены сознательно — 0 карточек, 0 точек; healthcheck это учитывает и не считает поломкой (см. P1 в плане: включение требует ключа нейросети).
• Расписания и группы устройств работают как описано: шесть правил по времени управляют светом земляники и тремя каналами реле аквариума (state_l1, state_l2).

Что уточнилось против первой редакции

• Брокер закрыт строже, чем я написал. В первой редакции было «1883 на LAN с паролем» — на самом деле сейчас оба порта слушают только localhost. Доступ снаружи невозможен. Так что пункт про «закрыть анонимный слушатель» уже выполнен; из рекомендаций по доступу остаётся ровно одна — добавить ACL по топикам, чтобы «прочитано» и «можно командовать» были разными правами.
• Правила 158 и 159 — не пустышки. Раньше в заметках они значились как «включены без действия и письма». На самом деле у них пустой action_topic (техникой не управляют), но поднят флаг уведомления — то есть это правила-наблюдатели: «PM2.5 > 100» и «ЛОС > 1000» шлют письмо. Формулировка исправлена: это рабочие уведомления, а не мусор.
• В журнале есть след вашего теста: 29.09 в 16:36 правило с именем ssss сработало 119 раз подряд, самого правила в таблице уже нет. В базе рядом осталась пустая тестовая таблица zz_test_perm. Мелочь, но такие следы как раз и мешают при разборе «кто управлял техникой» — чистить сразу.
• Правило 158 (PM2.5) — единственное место, где действительно стоит разобраться. Оно срабатывало 404 раза за неделю (258 за один день 27.09), каждый раз с реальным действием и письмом. Действия по технике у него нет — только уведомление, поэтому вреда нет, но письма в такие дни идут сотнями. Два вопроса к нему: порог 100 µg/m³ против названия «PM2.5 > 20» (название и условие расходятся — легко запутаться) и вопрос, не логичнее ли считать среднее за 5 минут, а не мгновенное значение, чтобы пыль от одного прохода не превращалась в поток уведомлений.

Итого

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

Ответ на исходный вопрос: да, движок должен слушать брокер напрямую, а базу оставить для истории и настроек. Это не менее надёжно — при трёх условиях, которые надо написать явно: восстановление состояния при старте, поведение при потере связи (fail-safe) и guard на устаревшие данные. И делать это лучше не «в один день», а поставив новый движок рядом в режиме наблюдения и сравнив его решения с текущими.

И главное, что стоит сказать вслух: у самописного дома есть то, чего не купить — понимание каждой линии своего кода. Поэтому «переписать на Home Assistant» — не единственный правильный путь. Правильный путь — оставить контроль там, где он ценен, и не тащить на себе то, что давно решено другими. (ну это слишком просто. Легче всего HomeAsistent поставить! Но мы легких путей не ищем)