Мы регулярно сталкиваемся с проектами, где HVAC-контроллеры (Danfoss, Honeywell, Daikin VRV) используют разные протоколы. Один объект — Modbus RTU на RS-485 к приточным установкам, BACnet/IP к чиллерам, проприетарный протокол к фанкойлам Daikin. Наше мобильное приложение работает с нормализованными данными через API-шлюз, поэтому мы уделяем особое внимание правильной интерпретации исходных данных. Ошибка на этапе разбора может привести к аварийным ситуациям: например, если температура подачи прочитана как unsigned вместо signed, система может принять -10°C за 65436°C и отключить отопление. За годы работы мы накопили базу типовых конфигураций для большинства распространённых контроллеров.
Ключевые параметры и их источники
Минимальный набор для мониторинга климата:
| Параметр | Источник | Единица | Частота |
|---|---|---|---|
| Температура подачи/обратки | Датчики PT1000/NTC на трубопроводе | °C | 30 сек |
| Температура воздуха в зоне | Комнатный датчик или термостат | °C | 1 мин |
| Влажность | SHT31 или HIH6130 в зоне | %RH | 1 мин |
| Уставка (setpoint) | Контроллер | °C | по изменению |
| Состояние компрессора | Дискретный вход контроллера | on/off | по изменению |
| COP (коэффициент эффективности) | Вычисляемый на бэкенде | — | 5 мин |
Важный нюанс: температура в 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 при той же нагрузке на сеть.
| Параметр | Polling (REST) | MQTT |
|---|---|---|
| Задержка доставки | 1–15 сек | < 0.5 сек |
| Нагрузка на сеть | Высокая | Низкая |
| Надёжность | Зависит от интервала | Сообщения QoS 1/2 |
| Сложность реализации | Низкая | Средняя |
Тренды и история
График температуры за неделю — обязательный элемент. Данные за длительный период запрашиваем с агрегацией на сервере (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 успешно реализованных проектов. Получите консультацию по вашему проекту уже сегодня.
