Разработка мобильного приложения для BMS-управления зданием

BMS-проекты начинаются одинаково: заказчик показывает схему здания с контроллерами Siemens Desigo CC, Schneider Electric EcoStruxure или Johnson Controls Metasys и говорит «хотим видеть всё это в телефоне». За этим «всё это» скрываются десятки протоколов, polling-циклы от 1 секунды до 15 минут, исто

Разработка и поддержка любых видов мобильных приложений:

Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

Это лишь некоторые из типы мобильных приложений, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента.

Услуги, которые мы предлагаем
Показано 1 из 1Все 1734 услуг
Разработка мобильного приложения для BMS-управления зданием
Сложный
от 2 недель до 3 месяцев

Наши компетенции:

Часто задаваемые вопросы

Последние работы

  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    897
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    784
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1218
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    1081
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    1004
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    600

BMS-проекты начинаются одинаково: заказчик показывает схему здания с контроллерами Siemens Desigo CC, Schneider Electric EcoStruxure или Johnson Controls Metasys и говорит «хотим видеть всё это в телефоне». За этим «всё это» скрываются десятки протоколов, polling-циклы от 1 секунды до 15 минут, историческая база на годы назад и требование работать даже когда основной сервер BMS перезагружается. Мы берём такие проекты под ключ: от анализа протоколов до публикации в stores. Наш опыт — 10+ лет в BMS-интеграции и более 50 реализованных объектов. Оцениваем проект за 2 дня и гарантируем стабильную работу при любой нагрузке.

Протоколы и шлюзы

Промышленные BMS говорят на BACnet/IP, Modbus TCP/RTU, KNX/IP и LonWorks. Напрямую из мобильного приложения к ним не ходят — между контроллерами и REST/WebSocket API стоит шлюз или middleware.

Типичный стек интеграции:

Уровень Технология
Контроллеры BACnet/IP, Modbus TCP, KNX
Шлюз Node-RED, Niagara Framework 4, собственный Python/Go сервис
Transport MQTT over TLS, REST, WebSocket
Мобильный клиент Flutter / Swift / Kotlin

Niagara Framework 4 (Tridium) — де-факто стандарт для крупных объектов. Он умеет нормализовать BACnet-объекты в единый REST API (/haystack/api/read?filter=bacnet) и отдавать WebSocket-стрим изменений. Работа с Haystack API через Dart:

class HaystackClient { final Dio _dio; final String _baseUrl; HaystackClient(this._baseUrl, String username, String password) : _dio = Dio(BaseOptions( baseUrl: _baseUrl, headers: { 'Authorization': 'Basic ${base64Encode(utf8.encode('$username:$password'))}', 'Accept': 'application/json', }, )); Future<List<HaystackRow>> read(String filter) async { final response = await _dio.get('/haystack/api/read', queryParameters: {'filter': filter}); final grid = HaystackGrid.fromJson(response.data); return grid.rows; } Future<Map<String, dynamic>> readPoint(String pointId) async { final response = await _dio.get('/haystack/api/hisRead', queryParameters: { 'id': '@$pointId', 'range': 'today', }); return response.data; } } 

Для объектов с MQTT-шлюзом (Node-RED конвертирует BACnet → MQTT JSON) используем mqtt_client в Flutter. Топики организуем по иерархии здания: building/{buildingId}/floor/{floor}/zone/{zone}/{parameter}.

Как мы интегрируемся с существующей BMS?

Процесс всегда начинаем с аудита контроллеров: выясняем, какие протоколы используются, какая версия Niagara или другого middleware, есть ли уже REST/WebSocket API или требуется установка шлюза. Затем проектируем схему потоков данных: какие точки читаем, какие пишем, с какой периодичностью. Сертифицированные инженеры настраивают шлюз и проводят интеграционное тестирование. Результат — единый интерфейс на телефоне вместо нескольких панелей управления.

Архитектура данных реального времени: почему DataHub критичен?

Самый сложный момент в BMS-приложении — не подключение, а управление потоком данных. Температура в 200 зонах обновляется каждые 30 секунд, освещение — по событию, энергопотребление — каждую минуту. Всё это нельзя переподписывать при каждом перерисовывании UI.

Решение — централизованный DataHub на уровне приложения:

class BmsDataHub { final MqttClient _mqtt; final _streams = <String, BehaviorSubject<BmsPoint>>{}; Stream<BmsPoint> watchPoint(String pointId) { if (!_streams.containsKey(pointId)) { _streams[pointId] = BehaviorSubject(); _mqtt.subscribe('building/+/+/+/$pointId', MqttQos.atLeastOnce); } return _streams[pointId]!.stream; } void _onMessage(List<MqttReceivedMessage<MqttMessage>> events) { for (final event in events) { final topic = event.topic; final payload = MqttPublishPayload.bytesToStringAsString( (event.payload as MqttPublishMessage).payload.message); final point = BmsPoint.fromJson(jsonDecode(payload)); _streams[point.id]?.add(point); } } } 

BehaviorSubject из пакета rxdart сохраняет последнее значение — виджет, подписавшийся после прихода данных, сразу получает актуальное состояние без ожидания следующего цикла polling.

Интерактивный план этажа

Заказчики всегда хотят план здания с живыми данными. DXF или SVG-план конвертируем в SVG (через ODA File Converter для DXF), рендерим через flutter_svg + InteractiveViewer. Точки датчиков — overlay поверх SVG с позиционированием по нормализованным координатам:

class FloorPlanWidget extends StatelessWidget { final FloorPlan plan; final Map<String, BmsPoint> liveData; @override Widget build(BuildContext context) { return LayoutBuilder(builder: (context, constraints) { return Stack(children: [ SvgPicture.asset('assets/floors/${plan.id}.svg', width: constraints.maxWidth), ...plan.sensors.map((sensor) => Positioned( left: sensor.x * constraints.maxWidth, top: sensor.y * constraints.maxHeight, child: SensorMarker( point: liveData[sensor.pointId], type: sensor.type, ), )), ]); }); } } 

Маркеры меняют цвет по порогам: зелёный (норма), жёлтый (предупреждение), красный (авария). Пороги берём из BMS-конфигурации, не хардкодим.

Управление: запись значений в BACnet-точки

Читать проще, чем писать. Для командования BACnet-точками (setpoint температуры, включение/выключение освещения) через REST-шлюз:

Future<void> writePoint(String pointId, dynamic value) async { // Оптимистичное обновление UI _hub.updateLocally(pointId, value); try { await _api.put('/haystack/api/pointWrite', data: { 'id': '@$pointId', 'level': 8, // приоритет записи BACnet (1-16, ниже = выше приоритет) 'val': value, 'who': _authService.currentUser, 'duration': 'PT0S', // permanent }); } on DioException catch (e) { // Откат при ошибке _hub.revertLocally(pointId); rethrow; } } 

BACnet Priority Array — деталь, которую игнорируют и потом не могут понять, почему уставка температуры не меняется: контроллер принимает команды, но они перебиваются более высоким приоритетом из BMS-расписания (уровень 2-4). Уровень 8 — стандартный для ручного оператора.

Алерты и журнал событий

Аварийные события из BMS приходят через MQTT или WebSocket. Локальные push-уведомления генерируем через flutter_local_notifications, серверные push (когда приложение закрыто) — через FCM с высоким приоритетом (priority: high, content_available: true).

Журнал событий: SQLite через drift для офлайн-хранения 30 дней истории, страничная загрузка из API для более старых записей.

Разграничение прав

В реальных объектах разные пользователи видят разные этажи и зоны. Права хранятся на бэкенде, мобильный клиент запрашивает список доступных объектов при логине и не строит маршруты к недоступным ресурсам. Попытка записать в запрещённую точку → HTTP 403 → локальный откат + уведомление пользователю.

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

  • Анализ протоколов контроллеров и архитектуры BMS.
  • Проектирование схемы интеграции и потоков данных.
  • Реализация мобильного клиента (iOS/Android на Flutter или нативном стеке).
  • Настройка шлюза и интеграционное тестирование.
  • Публикация в App Store и Google Play.
  • 30 дней технической поддержки после релиза.
  • Документация по API и обучение персонала (опционально).

Сроки и стоимость

Этап Срок
MVP (план этажа + real-time мониторинг) 8–12 недель
Полноценная система (несколько объектов, графики, алерты, права) 4–6 месяцев
Интеграция с нестандартными протоколами +2–4 недели

Стоимость рассчитывается индивидуально после анализа ваших контроллеров и требований. Свяжитесь с нами для оценки — мы подготовим коммерческое предложение за 2 рабочих дня.