Раздел «Аномалии» в самописном умном доме: как это работает и какие файлы участвуют

Спойлер: пока сам не знаю что эта за хрень, просто придумал идею в трех предложениях и скормил гермес-агенту после прожарки проекта. Нейросеть мне склепала вот такой сервис, который я сам пока не понял как работает, но чет крутое, оставил заметку, сижу разбираюсь может еще идеи какие будут )

1. Из чего состоит раздел

Раздел — это два независимых куска, которые общаются через базу данных:

2. Конвейер данных целиком

  Zigbee-датчик
        │  (радио)
        ▼
   zigbee2mqtt ──────────► MQTT-топик  zigbee2mqtt/<устройство>/<поле>
        │                              например zigbee2mqtt/fish_light/voltage = 218
        ▼
   Mosquitto (127.0.0.1:1883, логин/пароль)
        │
        ▼
  mqtt_to_mysql.py  ── последнее значение ──►  sensor_data     (одна строка на топик)
        │            ── история (если нужно) ─►  sensor_history (много строк по времени)
        │
        ▼
  iot_anomaly.py  (цикл 15 с)
        │
        ├─(1) съём точек ─────────────►  anomaly_samples   (число + время)
        │
        ├─(2) расчёт нормы и поиск ───►  anomaly_events    (тип, важность, отклонение)
        │        │
        │        └── важность ≥ порога карточки ──►  письмо через msmtp
        │
        └─(3) запрос ИИ из очереди ───►  anomaly_requests  (страница кладёт, сервис забирает)
                 │
                 └── статистика + промпт ──► нейросеть ──►  anomaly_reports (готовый отчёт)

3. Какие файлы участвуют

Полный список — от источника данных до витрины. Всё, что вне веб-корня, руками по HTTP не открывается (и это правильно: .py и .sh в public_html nginx отдаёт как 403).

Смежное, без чего раздел не поедет

4. Как это работает: пять таблиц

Вся логика раздела читается по схеме данных. Если понимать эти пять таблиц — понимать модуль целиком.

5. Четыре типа аномалий и одна честная тишина

Сервис ищет ровно пять видов событий. Это не «модный ИИ», а обычная статистика — и именно поэтому она работает на данных слабых и медленных Zigbee-датчиков.

Почему медиана и MAD, а не среднее и «три сигмы»

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

обычная сигма:  σ = √( Σ(xᵢ − среднее)² / n )        ← одна выбросная точка раздувает σ
устойчивая:     медиана m,  MAD = медиана(|xᵢ − m|),  σ = 1.4826 × MAD

med, sigma = median_abs_dev(values)     # медиана и 1.4826 × MAD по окну window_hours
if sigma > 0:
    threshold = spike_factor * sigma    # по умолчанию 6 сигм

uniq = sorted(set(values)); steps = [b - a for a, b in zip(uniq, uniq[1:]) if b - a > 0]
step = min(steps) if steps else max(abs(med) * 0.02, 0.02)
threshold = max(3 * step, abs(med) * 0.02, 0.02)

Сколько точек нужно, прежде чем что-то говорить

Пока в окне меньше min_samples точек, анализ по карточке просто не выполняется. Норма, посчитанная по пяти значениям, — это не норма, а случайность. По умолчанию нужно 20 точек, и статус карточки меняется с collecting на ready, только когда порог перейдён.

6. Как это выглядит в панели

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

Что настраивается прямо в карточке, без правки кода:

• Съём раз в N секунд — как часто брать точку (минимум 10).
• Окно нормы в часах — по каким последним данным считать «норму». Меньше окно — чувствительнее к смене режима, больше — стабильнее.
• Точек до начала анализа — min_samples.
• Пределы снизу и сверху — жёсткие границы; пустое поле = предела нет.
• Выброс = сколько сигм — spike_factor, по умолчанию 6.
• Пауза между однотипными аномалиями — cooldown_events. Это защита от спама: датчик, который «залип» в аномалии, больше не пишет о ней каждые 15 секунд.
• Пропажа данных = сколько интервалов — gap_intervals, по умолчанию 3.
• Почта и минимальная важность — кому и с какого уровня писать. Пустой адрес = письма нет, событие всё равно пишется в журнал.
• Промпт для нейросети — текст, который уйдёт системе вместе со статистикой. В нём задают роль и формат ответа.

Ты инженер-электрик. Ниже статистика по силе тока домашней розетки (аквариум) и найденные автоаномалии.

Оцени: стабильность тока, всплески при включении нагрузки, соответствие мощности и
напряжения (P = U*I), признаки плохого контакта или износа проводки. Учти, что свет и
обогреватель включаются по расписанию, поэтому ступеньки тока ожидаемы.

Ответ: 1) вывод по состоянию цепи; 2) что может давать скачки; 3) что проверить
физически; 4) какие данные добавить. По-русски, кратко.

7. Что уходит в нейросеть и что приходит назад

Модель не видит базу и не видит графики. Ей уходит текст, который сервис собирает сам — и это принципиально: если дать модели сырые точки, она утонет в них и начнёт сочинять.

Ответ вместе со всем отправленным текстом сохраняется в anomaly_reports. Через месяц видно, на каких данных модель сделала вывод, — это важно, когда разбираешь ложную тревогу.

Анализ нейросетью пока не подключён.

Данные собраны и статистика посчитана (см. ниже). Чтобы включить разбор ИИ:
1) в /etc/iot/credentials.ini в секции [ai] указать enabled = 1, provider (openai/mistral/локальный),
   base_url, model и api_key;
2) нажать «Проанализировать» на карточке заново.

8. Почему модуль сейчас в режиме ожидания

В базе три карточки, у всех enabled = 0, и сбора точек нет: последняя точка датирована 26 сентября 17:54. Это не поломка — карточки выключены сознательно вместе с отсутствием ключа нейросети, и вот тут начинается отдельная история про уведомления.

Первая версия общей проверки дома считала выключенный модуль двумя ошибками и каждый час отправляла письмо «ПРОБЛЕМЫ (2)». Одинаковое письмо через неделю уезжает в спам вместе с настоящими тревогами — то есть сторожевая функция тихо превращается в бесполезную. Поэтому проверка научена различать ситуации:

карточек активно 0  И  [ai] enabled != 1   →  [SKIP]  «выключен сознательно», счётчик ошибок не растёт
карточки есть, а точки не собираются      →  [FAIL]  настоящая поломка, письмо уходит

9. Как включить раздел на полную мощность

# 1) ключ нейросети: секция [ai] в /etc/iot/credentials.ini
#    enabled = 1, provider = openai | mistral | ollama, base_url, model, api_key
sudo -n nano /etc/iot/credentials.ini
sudo -n systemctl restart iot-anomaly

# 2) включить карточку наблюдения (в панели — кнопкой, из консоли — так)
mysql iot_db -e "UPDATE anomaly_watchers SET enabled = 1 WHERE id = 1;"

# 3) проверить, что точки пошли (ждать интервал съёма, обычно минуту)
mysql iot_db -e "SELECT w.name, COUNT(s.id) точек, MAX(s.taken_at) последняя
                 FROM anomaly_watchers w LEFT JOIN anomaly_samples s ON s.watcher_id = w.id
                 WHERE w.enabled = 1 GROUP BY w.id;"

# 4) смотреть работу сервиса вживую
tail -f /home/iot_user/iot_anomaly.log

# 5) общая проверка дома (раздел 3 — про аномалии)
/home/iot_user/healthcheck.sh

10. Грабли, которые уже пойманы

11. Итог: зачем это вообще нужно

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

Раздел делает три вещи, и все три без нейросети: собирает точки по выбранным топикам со своим интервалом, считает норму устойчивыми методами (медиана и MAD) и сообщает письмом о том, что вышло за норму — с паузой, чтобы не превратиться в спам. Нейросеть здесь надстройка: она превращает таблицу чисел в осмысленный вывод, но находит аномалии статистика.

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