Реалізація моніторингу 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 шлюзу вони можуть бути зміщені. Тому ми завжди звіряємо мапінг регістрів з документацією контролера.

Типові помилки при зчитуванні даних

Найпоширеніша помилка — неправильний порядок байтів (little-endian vs big-endian) та різна кодування даних. Наприклад, у деяких контролерів температура передається в градусах Фаренгейта з множником 100, а не 10. Наш досвід показує, що в 30% проєктів виявлено невідповідності між документацією та реальним протоколом. Тому ми обов'язково проводимо тестовий опит усіх регістрів і звіряємо з показниками еталонних датчиків.

Реалізація на 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 над Polling

Для об'єктів з 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 — користувач має бачити коли і що сталося, навіть якщо сповіщення змахнув.

Як ми забезпечуємо безперебійний моніторинг?

Ключове рішення — резервування каналів зв'язку. Якщо основний шлюз через 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 успішно реалізованих проєктів. Отримайте консультацію по вашому проєкту вже сьогодні.