Разработка мобильного приложения для умного здания (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 месяцев. Стоимость рассчитывается индивидуально после анализа протоколов контроллеров и требований к интеграции.







