Введение

Мониторинг качества воздуха становится важной задачей как для больших городов, так и для частных помещений — офисов, школ, детских садов, квартир. Понимание уровня CO2, летучих органических соединений (VOC), а также концентрации взвешенных частиц PM2.5 и PM10 позволяет не только оценивать комфорт, но и предупреждать риски для здоровья. В этой статье расскажу о создании веб-приложения для мониторинга воздуха в реальном времени с использованием датчиков, передачи данных в браузер и визуализации. Покрою архитектуру системы, выбор аппаратуры, протоколы связи, обработку данных, интерфейс пользователя, вопросы калибровки и тестирования, а также практические советы по развертыванию и масштабированию. В тексте будет упомянуто дополнительное устройство для оценки среды — шумомер, который можно интегрировать в систему как опциональный канал данных.

Цели и требования проекта

Цель — получить недорогое, надежное веб-решение, которое собирает данные с датчиков качества воздуха, отображает их в реальном времени в браузере, хранит историю и генерирует оповещения о превышении порогов.

Основные требования:

— Поддержка датчиков CO2, VOC, PM2.5/PM10. Возможность добавления других сенсоров (температура, влажность, шум и т.д.).

— Низкая задержка передачи данных, обновление в браузере примерно каждую секунду или несколько секунд.

— Удобный и информативный интерфейс: графики, индикаторы состояния, история, карточки с текущими значениями.

— Масштабируемость: поддержка нескольких устройств/узлов.

— Безопасность и простота установки.

— Возможность локальной работы без облака (опционально).

Обзор аппаратной части

1) Датчики качества воздуха

— CO2: популярные модули на базе сенсоров NDIR (неразрушающий инфракрасный метод). Примеры — Senseair S8, MH-Z19B/C, SCD30. NDIR обеспечивает хорошую точность и стабильность, подходит для мониторинга в помещениях.

— VOC: обычно используются электрохимические или полупроводниковые сенсоры (например, CCS811, BME680/680+алгоритмы). Они дают индикативную оценку летучих органических веществ и эквивалентного CO2 (eCO2). Для точного определения конкретных соединений нужны лабораторные приборы, но для контроля качества воздуха такие датчики подходят.

— PM2.5/PM10: лазерные оптические датчики (зачастую на основе лазерного рассеяния), например PMS5003, SPS30, Plantower. Они измеряют массовую или числовую концентрацию мелких частиц.

— Дополнительно: датчики температуры/влажности (DHT22, SHT31), барометры, а также шумомер для оценки уровня звука (опционально).

2) Контроллер и коммуникации

— Микроконтроллеры с Wi-Fi: ESP32, ESP8266 — экономичны, поддерживают TCP/HTTP/MQTT, имеют достаточную производительность для чтения датчиков и отправки данных в сеть.

— Одноплатные компьютеры: Raspberry Pi — удобны для более сложной логики, локальной базы данных, веб-сервера и хранения больших объёмов данных.

— Интерфейсы датчиков: I2C, UART, PWM, GPIO. Важно продумать питание (стабильное 3.3/5 В), экранирование и размещение датчиков вдали от источников пыли и тепла.

Протоколы и архитектура передачи данных

Подходы к передаче данных в веб-приложение:

— MQTT + брокер: устройства публикуют данные в топики MQTT. Сервер/приложение подписываются и обновляют интерфейс. Хорош для масштабируемых решений, низкой нагрузки и надёжной доставки.

— HTTP/REST: контроллер периодически отправляет POST-запросы с текущими значениями на сервер. Простая реализация, но менее эффективна для реального времени и большого числа устройств.

— WebSocket: поддерживает двунаправленную связь между сервером и браузером в режиме реального времени. Сервер получает данные от устройств (через MQTT или HTTP) и пушит их в браузеры через WebSocket.

— Server-Sent Events (SSE): альтернатива WebSocket для односторонних push-обновлений в браузер.

Типичная архитектура:

— Устройства (ESP32/RPi) собирают данные, публикуют в MQTT-брокер (локальный Mosquitto или облачный).

— Backend (Node.js, Python/Flask/FastAPI, Go) подписывается на топики, сохраняет данные в БД (InfluxDB, TimescaleDB, PostgreSQL), выполняет агрегации и бизнес-логику.

— Web-сервер предоставляет HTTP API и WebSocket/SSE для браузера.

— Frontend (SPA на React/Vue/Svelte или простая страница) подключается к WebSocket и отображает живые данные и графики (Chart.js, D3, Lightweight charts).

Выбор базы данных и хранение данных

Для временных рядов лучше выбрать TS-ориентированную СУБД:

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

— TimescaleDB (расширение для PostgreSQL): сочетает реляционные возможности и производительность для временных рядов.

— Альтернативы: Prometheus (подходит для мониторинга метрик), обычный PostgreSQL при небольшой нагрузке.

Хранение данных:

— Высокая частота измерений (каждую секунду) быстро заполняет базу. Рекомендую хранить детальные данные кратковременно (несколько дней/недель), а затем выполнять downsampling (1 минута/5 минут/час) для длительной истории.

— Индексация по времени и идентификатору устройства, хранение метаданных (локация, тип датчика, калибровки).

Обработка и фильтрация измерений

Сырые данные часто содержат шум и выбросы. Рекомендуемые этапы:

— Валидация: проверка допустимого диапазона значений (например, CO2 400–5000 ppm, PM 0–1000 µg/m3), отбрасывание явно ошибочных показаний.

— Сглаживание: скользящее среднее, экспоненциальное сглаживание для уменьшения флуктуаций.

— Каллибровка: регулярная калибровка датчиков NDIR и датчиков PM (сверка с эталоном, автоматическая компенсация нуля для некоторых датчиков).

— Коррекция температуры/влажности: некоторые датчики VOC и PM чувствительны к ним; применение коррекционных формул улучшает точность.

Пороговые значения, оповещения и правила

Необходимо определить пороговые значения для тревог и визуальных индикаторов. Примеры ориентировочных уровней (для помещений):

— CO2: <800 ppm — хорошо, 800–1000 ppm — средне, >1000–1500 ppm — плохо, >2000 ppm — опасно.

— VOC: зависит от датчика, использовать эталонные рекомендации производителя; внимание к резким всплескам.

— PM2.5: <12 µg/m3 — отлично, 12–35.4 — умеренно, 35.5–55.4 — плохо, >55.4 — очень плохо (US AQI ориентир).

— PM10: отдельные пороги.

Оповещения: push-уведомления в браузере, emails, SMS или интеграция с мессенджерами. Логика оповещений должна учитывать длительность превышения порога (короткий кратковременный всплеск vs. устойчивое повышение).

Frontend: интерфейс и UX

Ключевые элементы UI:

— Дашборд с текущими значениями: крупные цифры для CO2, PM2.5, VOC, температура, влажность, уровень шума.

— Исторические графики с возможностью смены интервала (минуты, часы, дни).

— Карточки состояния с цветовой индикацией (зелёный/жёлтый/красный).

— Переходы между устройствами/комнатами.

— Карта при наличии множества сенсоров в здании.

— Конфигурация оповещений и порогов.

Стиль: простой, лаконичный интерфейс, адаптивность для мобильных устройств, понятная цветовая схема и пояснения для пользователя, что означают значения.

Реализация в браузере и реальное время

Для отображения данных в реальном времени:

— Установите WebSocket-соединение с сервером. Сервер публикует события при поступлении новых данных от устройств.

— Для избежания излишней нагрузки: агрегируйте сообщения на сервере и посылайте только релевантные обновления (или реализуйте клиентские фильтры).

— Используйте библиотеки для рисования графиков, оптимизированные для потоковых данных (легковесные, с поддержкой прокрутки истории).

— Реализуйте кеширование и работу офлайн: при потере соединения показывайте последние сохранённые данные.

Калибровка, валидация и тестирование

Калибровка:

— CO2-сенсоры NDIR требуют минимального обслуживания; рекомендуется периодическая калибровка на воздухе с известным содержанием CO2 (например, открытый воздух) или по инструкции производителя.

— PM-датчики: при установке проверьте на предмет засорения, обеспечьте правильное направление вентиляции. Для сравнения используйте эталонные приборы или сервисы мониторинга в вашем регионе.

— VOC-датчики: необходимо тестировать на реакцию на различные растворители/источники и учитывать склонность к дрейфу.

Тестирование:

— Функциональное тестирование: проверка цепочки: датчик → устройство → брокер → сервер → браузер.

— Нагрузочное тестирование: эмулируйте множество устройств и клиентов, проверьте производительность бекенда и БД.

— Тесты на восстановление: отключение сети, перезапуск компонентов, тестирование отложенной доставки данных.

Безопасность и приватность

— Аутентификация устройств: используйте уникальные ключи/сертификаты для каждого устройства при подключении к MQTT/HTTP.

— HTTPS и WSS для связи между браузером и сервером.

— Ограничение доступа к API и дашборду: роли пользователей, доступ к данным только своих устройств.

— Локальная работа: при необходимости обеспечьте возможность работы без выхода в интернет, чтобы данные оставались внутри сети клиента.

Развертывание и масштабирование

— Малые инсталляции: всё можно развернуть на одной Raspberry Pi с локальным Mosquitto и InfluxDB.

— Крупные сети: контейнеризация (Docker), оркестрация (Kubernetes), отдельные инстансы брокера MQTT, балансировщики для WebSocket.

— Логи и мониторинг самого мониторинга: следите за здоровьем устройств, логами подключения и длительностью передачи данных.

Примеры сценариев использования

— Офисы: контроль CO2 для оптимизации вентиляции, снижение усталости и увеличение продуктивности.

— Школы: отслеживание риска передачи воздушно-капельных инфекций через концентрацию CO2 и вентиляцию.

— Жилые помещения: контроль PM2.5 во время отопительного сезона, обнаружение резкого повышения VOC (ремонтные работы, приготовление пищи).

— Промышленные помещения: мониторинг превышений PM и VOC вблизи производственных процессов.

Практические советы по выбору компонентов и сборке

— Размещение датчиков: не рядом с кухонной плитой, окнами, кондиционерами. Высота ~1.0–1.5 м для оценки дыхательной зоны.

— Защита от пыли и влаги: корпуса с фильтрами или перфорированные кожуха, но не закрывайте оптические сенсоры слишком плотно.

— Периодичность отправки: для реального времени 1–10 с, но учитывайте ресурс сети и БД. Для многих случаев оптимальным будет 5–30 секунд.

— Источники питания: стабильный адаптер; при автономной работе — учёт энергопотребления ESP32 vs Raspberry Pi.

— Документация: ведите списки устройств, серийные номера, даты калибровки.

Интеграции и расширения

— Интеграция с системами автоматизации зданий (BMS) для управления вентиляцией в ответ на показания.

— Интеграция с IoT-платформами (Home Assistant, Node-RED).

— Добавление ML-моделей для предсказания ухудшения качества воздуха по трендам и внешним данным (погода, трафик).

— Экспорт данных в открытые сервисы или стандартизированные форматы для исследований.

Бизнес-модель и эксплуатация

— Услуга мониторинга для нескольких клиентов: аренда датчиков с облачным сервисом и dashboard.

— Продажа решений «под ключ» для зданий: установка датчиков, настройка, сервис поддержки.

— Подписка на расширенные функции: долгосрочное хранение, продвинутые аналитики, оповещения и интеграции.

Заключение

Разработка веб-приложения для мониторинга качества воздуха в реальном времени — это пересечение аппаратной инженерии, сетевых протоколов, бэкенд-архитектуры и удобного интерфейса. При правильном выборе датчиков (CO2, VOC, PM2.5/PM10 и дополнительных моделей), устойчивой архитектуре данных (MQTT + временная СУБД), внимательной калибровке и UX вы получите систему, которая поможет улучшать микроклимат, сохранять здоровье и оптимизировать расходы на вентиляцию и очистку. Включение дополнительных каналов, например, уровней звука с помощью шумомер, делает картину окружающей среды более полной и полезной для принятия решений. Начинайте с прототипа на одном устройстве, отладьте цепочку данных и затем масштабируйте архитектуру под реальные требования.