Разработка мобильного приложения для умного здания (Building Management System)

TRUETECH занимается разработкой, поддержкой и обслуживанием мобильных приложений iOS, Android, PWA. Имеем большой опыт и экспертизу для публикации мобильных приложений в популярные маркеты Google Play, App Store, Amazon, AppGallery и другие.
Разработка и поддержка любых видов мобильных приложений:
Информационные и развлекательные мобильные приложения
Новостные приложения, игры, справочники, онлайн-каталоги, погодные, фитнес и здоровье, туристические, образовательные, социальные сети и мессенджеры, квиз, блоги и подкасты, форумы, агрегаторы
Мобильные приложения электронной коммерции
Интернет-магазины, B2B-приложения, маркетплейсы, онлайн-обменники, кэшбэк-сервисы, биржи, дропшиппинг-платформы, программы лояльности, доставка еды и товаров, платежные системы
Мобильные приложения для управления бизнес-процессами
CRM-системы, ERP-системы, управление проектами, инструменты для команды продаж, учет финансов, управление производством, логистика и доставка, управление персоналом, системы мониторинга данных
Мобильные приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, платформы предоставления электронных услуг, платформы кешбека, видеохостинги, тематические порталы, платформы онлайн-бронирования и записи, платформы онлайн-торговли

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

Предлагаемые услуги
Показано 1 из 1 услугВсе 1735 услуг
Разработка мобильного приложения для умного здания (Building Management System)
Сложная
от 2 недель до 3 месяцев
Часто задаваемые вопросы
Наши компетенции:
Этапы разработки
Последние работы
  • image_mobile-applications_feedme_467_0.webp
    Разработка мобильного приложения для компании FEEDME
    756
  • image_mobile-applications_xoomer_471_0.webp
    Разработка мобильного приложения для компании XOOMER
    624
  • image_mobile-applications_rhl_428_0.webp
    Разработка мобильного приложения для компании RHL
    1054
  • image_mobile-applications_zippy_411_0.webp
    Разработка мобильного приложения для компании ZIPPY
    947
  • image_mobile-applications_affhome_429_0.webp
    Разработка мобильного приложения для компании Affhome
    874
  • image_mobile-applications_flavors_409_0.webp
    Разработка мобильного приложения для компании FLAVORS
    445

Разработка мобильного приложения для умного здания (Building Management System)

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

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

Промышленные 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-приложении — не подключение, а управление потоком данных. Температура в 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-клиента с отображением плана этажа, real-time данными через MQTT/WebSocket и управлением setpoints: 8–12 недель. Полноценная система с поддержкой нескольких объектов, историческими графиками, алертами и разграничением прав: 4–6 месяцев. Стоимость рассчитывается индивидуально после анализа протоколов контроллеров и требований к интеграции.