Реализация мониторинга HVAC-систем через мобильное приложение

Мы регулярно сталкиваемся с проектами, где HVAC-контроллеры (Danfoss, Honeywell, Daikin VRV) используют разные протоколы. Один объект — Modbus RTU на RS-485 к приточным установкам, BACnet/IP к чиллерам, проприетарный протокол к фанкойлам Daikin. Наше мобильное приложение работает с нормализованными данными через API-шлюз, поэтому мы уделяем особое внимание правильной интерпретации исходных данных. Ошибка на этапе разбора может привести к аварийным ситуациям: например, если температура подачи прочитана как unsigned вместо signed, система может принять -10°C за 65436°C и отключить отопление. За годы работы мы накопили базу типовых конфигураций для большинства распространённых контроллеров.

Ключевые параметры и их источники

Минимальный набор для мониторинга климата:

Важный нюанс: температура в Modbus Holding Registers часто приходит как знаковое int16 в единицах 0.1°C. Если контроллер отдаёт 0xFF9C, это не 65436°C — это -100, то есть -10.0°C. Неправильная интерпретация — источник классической ошибки «датчик показывает -3200°C».

fun parseModbusTemperature(rawValue: Int): Double { // Конвертируем unsigned 16-bit в signed val signed = if (rawValue > 32767) rawValue - 65536 else rawValue return signed / 10.0 } 

В соответствии с Modbus Application Protocol Specification v1.1b, адреса регистров начинаются с 40001, но в API шлюза они могут быть смещены. Поэтому мы всегда сверяем маппинг регистров с документацией контроллера.

Реализация на Android: polling через Retrofit + coroutines

Шлюз (Node-RED или самописный Go-сервис) предоставляет REST API. Polling с адаптивным интервалом — агрессивный когда приложение на переднем плане, редкий в фоне:

class HvacPollingService( private val api: HvacApi, private val repository: HvacRepository, ) { private var pollingJob: Job? = null fun startPolling(scope: CoroutineScope, foreground: Boolean) { pollingJob?.cancel() val interval = if (foreground) 15_000L else 60_000L pollingJob = scope.launch { while (isActive) { try { val data = api.getHvacStatus() repository.update(data) } catch (e: IOException) { // Логируем, не крэшим — потеря связи с шлюзом штатная ситуация } delay(interval) } } } } 

Для объектов с MQTT-шлюзом (Eclipse Mosquitto) используем org.eclipse.paho.client.mqttv3. Топики по зонам: hvac/{buildingId}/{unitId}/temperature, hvac/{buildingId}/{unitId}/setpoint. MQTT обеспечивает почти мгновенную доставку изменений — в 10 раз быстрее polling при той же нагрузке на сеть.

Тренды и история

График температуры за неделю — обязательный элемент. Данные за длительный период запрашиваем с агрегацией на сервере (avg/min/max по часовым интервалам), не тащим сырые 30-секундные записи. В приложении рендерим через MPAndroidChart (Android) или fl_chart (Flutter):

LineChartData buildTemperatureChart(List<TemperatureReading> history) { return LineChartData( lineBarsData: [ LineChartBarData( spots: history.asMap().entries.map((e) => FlSpot(e.key.toDouble(), e.value.temperature)).toList(), isCurved: true, color: Colors.blue, dotData: FlDotData(show: false), ), ], titlesData: FlTitlesData( bottomTitles: AxisTitles( sideTitles: SideTitles( showTitles: true, getTitlesWidget: (value, meta) => Text(formatHour(history[value.toInt()].timestamp)), ), ), ), ); } 

Алерты по выходу из диапазона

Температура вышла за пределы — нужно уведомление. На сервере настраиваем правила (например, через Node-RED или TimescaleDB continuous aggregates), push приходит через FCM. В приложении храним историю алертов локально в Room/SQLite — пользователь должен видеть когда и что произошло, даже если уведомление смахнул.

Почему важно правильно интерпретировать данные протоколов?

Даже при корректном считывании регистров возможны расхождения: разные контроллеры используют разный порядок байтов (little-endian vs big-endian) и разную кодировку данных. Например, у некоторых контроллеров температура передаётся в градусах Фаренгейта с множителем 100, а не 10. Наш опыт показывает, что в 30% проектов обнаружены несоответствия между документацией и реальным протоколом. Поэтому мы обязательно проводим тестовый опрос всех регистров и сверяем с показаниями эталонных датчиков. Это гарантирует, что приложение с первого дня показывает корректные данные.

Как мы обеспечиваем бесперебойный мониторинг?

Ключевое решение — резервирование каналов связи. Если основной шлюз через Modbus недоступен, приложение автоматически переключается на резервный BACnet/IP или Cloud API. Для этого мы используем паттерн Chain of Responsibility с таймаутами. Кроме того, мы настраиваем локальное кэширование данных на устройстве на случай потери сети. В нашей практике был проект для торгового центра с 200 точками мониторинга — мы гарантировали доставку уведомлений с задержкой не более 30 секунд при 99.9% uptime сервера.

Что входит в разработку?

В рамках работы мы предоставляем:

• Документацию по протоколам и точкам данных (адреса регистров, коэффициенты преобразования).
• Исходный код приложения с комментариями и тестами.
• Интеграцию с существующими системами (BMS, SCADA) через API.
• Обучение персонала заказчика работе с приложением.
• Техническую поддержку в течение 3 месяцев после запуска.

Процесс работы: аудит текущих контроллеров → проектирование архитектуры интеграции → разработка мобильного приложения (iOS/Android) → тестирование на стенде → деплой на объекте. Сроки: от 4 до 6 недель для типового проекта. Стоимость рассчитывается индивидуально после анализа протоколов и количества точек мониторинга. Свяжитесь с нами, чтобы обсудить детали и получить консультацию — мы проанализируем вашу инфраструктуру и предложим оптимальное решение под ключ.

Таким образом, мы гарантируем надёжный мониторинг HVAC с точностью данных до 0.1°C и временем реакции на аварийные ситуации менее 30 секунд. Доверьте управление климатом профессионалам с 5+ лет опыта и более 20 успешно реализованных проектов. Получите консультацию по вашему проекту уже сегодня.