Умный дом на Raspberry Pi

Описание проекта и архива: что за система, из чего она состоит, как развернуть её с нуля и на какие грабли уже наступали. Документ лежит внутри архива рядом с кодом — читать перед тем, как что-то менять.

1. Что это такое

Самописная домашняя автоматизация без облака и без готовых платформ. Всё крутится на одной Raspberry Pi: Zigbee-устройства (датчики движения, протечки, температуры и влажности, реле, краны, розетки) общаются с координатором, zigbee2mqtt превращает их сообщения в MQTT, Mosquitto раздаёт их, логгер складывает значения в MariaDB, движок правил сравнивает их с таблицей правил и отправляет команды обратно в брокер, а веб-панель показывает состояние и даёт править правила и справочник датчиков.

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

2. Как идут данные

Zigbee-устройства
      │  радио
zigbee2mqtt ──► Mosquitto (127.0.0.1:1883, с логином)
                    │
        ┌───────────┴────────────┐
 mqtt_to_mysql.py            mqtt_listener.php
 логгер: JSON → таблицы      движок: правила → команды в .../set
        │                        │
        └──────► MariaDB ◄───────┘
                    │
            nginx + PHP 8.2 (панель)

Сквозной путь одного события: датчик протечки прислал water_leak: true → zigbee2mqtt опубликовал JSON в zigbee2mqtt/leak_bath → логгер разложил поля в sensor_data и sensor_history → движок, подписанный на тему, разобрал JSON, проверил правила на поле water_leak, нашёл совпадение и опубликовал {"state":"ON"} в zigbee2mqtt/fish_light/set → реле включило свет → устройство доложило новое состояние → строка в automation_log.

3. Службы и порты

4. Состав архива

5. База данных

22 таблицы. Данные не выгружались — только структура, чтобы было видно устройство.

6. Развёртывание с нуля

1. Пакеты: nginx php8.2-fpm php8.2-mysql mariadb-server mosquitto mosquitto-clients python3-venv nodejs npm.
2. База: создать iot_db в utf8mb4, залить db/schema_iot_db.sql, завести прикладного и административного пользователей.
3. Секреты: /etc/iot/credentials.ini (640, root:www-data) и credentials.env (640, root:пользователь pi). Значения — как в README.
4. Сайт: разложить site/ в /var/www/html/iot/, поправить пути в nginx/iot.conf, включить сайт, nginx -t && systemctl reload nginx.
5. Службы: юниты из systemd/ в /etc/systemd/system/, daemon-reload, enable --now iot-automation mqtt-to-mysql.
6. MQTT: mosquitto/ в /etc/mosquitto/, пользователя завести через mosquitto_passwd -c /etc/mosquitto/passwd iot.
7. Zigbee2mqtt: конфиг в каталог Z2M, вписать сетевой ключ и порт координатора, systemctl enable --now zigbee2mqtt.
8. Cron и сторож: задания из cron/crontab_*.txt, healthcheck.sh в домашний каталог, ежечасный iot_watchdog.sh.
9. Проверка: все службы active, в sensor_data свежие метки времени, в журнале движка «Загружено N активных правил» и ни одной ошибки PHP.

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

• Пароли не лежат в коде: PHP и службы читают /etc/iot/credentials.ini, shell и cron — credentials.env. Права 640, владелец — тот, кому нужно.
• Веб-панель открыта только localhost и подсети WireGuard; остальным — deny all.
• nginx не отдаёт по HTTP исходники и архивы: .py, .sh, .sql, .log, .bak, бэкапы и *.phpgood* закрыты отдельными правилами.
• Брокер слушает только localhost, анонимный доступ выключен.
• Пароль панели хранится хешем (bcrypt), в открытом виде его нет даже в конфиге.

8. Грабли

Милливольты против вольт

У батарейных Zigbee-устройств поле voltage — это милливольты (2500…3000), а у розетки с измерением мощности то же поле — вольты сети (207…253). Если собирать «батарейки» поиском по имени топика, розетка попадёт в список и будет выглядеть заряженной на тысячи процентов. Список берётся из battery_spec, а пороги в ней записаны в вольтах — сравнивать надо с милливольтами.

Темы «устройство/поле» существуют только в базе

При output: json в брокер приходит одно сообщение на устройство. Движок обязан разбирать JSON и проверять правила по каждому полю — иначе правила на датчики молча не срабатывают, при этом расписания продолжают работать. Симптом: «по времени работает, по топику нет».

Payload обязан соответствовать топику

Для многоканальных реле возможны две формы: .../set/state_l3 + {"state":"ON"} или .../set + {"state_l3":"ON"}. Перепутал — в журнале «успешно отправлено», а реле молчит.

Выдержка условия у простых правил

«Условие держится N секунд» должно работать и для триггерных правил, а не только для расписаний. Иначе кран закрывается в ту же секунду, когда открылся.

Состояние в памяти процесса

Отложенные команды и ожидания подтверждений переживают перезапуск только потому, что пишутся в таблицу pending_actions. Иначе systemctl restart тихо отменяет всё, что было запланировано.

Топик живёт вечно

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

Приложение не должно создавать таблицы

Наличие таблицы проверяется чтением; если её нет — в журнал идёт понятное сообщение, а создаёт её администратор. Иначе каждая страница и каждый cron сыплют «CREATE command denied».

9. Откат

• Файлы панели до обновления 28.10.2026: przorka_backup/groups_20261028/*.orig на самой малине.
• Группы правил убираются одной командой: ALTER TABLE automations DROP COLUMN group_name; — сами правила не пострадают.
• Всё остальное — текстовые конфиги: вернуть файл из архива и перезапустить службу.