Мониторинг противопожарных датчиков в мобильном приложении

Мониторинг противопожарных датчиков в мобильном приложении

Пожарная сигнализация — зона, где программная ошибка стоит дороже, чем в любом другом IoT. В одном из проектов для гипермаркета мы столкнулись с ситуацией: приложение показывало «Всё нормально», хотя на ППК горел красный индикатор. Оказалось, шлюз неправильно парсил ответы по RS-232. С тех пор каждый бит в протоколе проверяется двойным чтением. Наша команда разрабатывает мобильные приложения для мониторинга противопожарных датчиков с 7+ летним опытом и более чем 50 успешными проектами. Мы гарантируем надёжность и соответствие требованиям пожарной безопасности.

Прибор приёмно-контрольный (ППК) типа Болид С2000-КДЛ, Honeywell NOTIFIER, Siemens Sinteso всегда остаётся главным: мобильное приложение читает его состояние, но никогда не подменяет локальную автоматику. Квитирование тревоги в телефоне не сбрасывает ППК — для этого нужен физический пульт.

Какие ППК и протоколы поддерживаются?

Мы работаем с любыми ППК, предоставляющими доступ по OPC UA, MODBUS TCP, REST API, или через RS-232 с проприетарным протоколом. Для Honeywell NOTIFIER используем REST API через LifeSafety Power Manager, для Болид С2000-КДЛ — RS-232 с конвертацией в MQTT через шлюз на Linux. OPC UA — стандарт для современных систем, но старые ППК часто требуют прямого чтения порта. В любом случае мы реализуем надёжную цепочку: ППК -> шлюз -> MQTT -> мобильное приложение.

Интеграция с ППК через OPC UA и RS-232

Типичная схема: шлюз на Linux-мини-сервере в серверной читает ППК через RS-232/OPC и публикует нормализованные события в MQTT. Мобильный клиент подписан на MQTT через TLS. Мы используем Flutter 3.x (Dart) с библиотекой mqtt_client, что даёт гибкость под iOS и Android.

Структура топиков MQTT:

fire/{buildingId}/panel/{panelId}/zone/{zoneId}/state fire/{buildingId}/panel/{panelId}/alarm fire/{buildingId}/panel/{panelId}/fault 

Состояние зоны — перечисление: normal, alarm, fault, disabled, test.

MQTT обеспечивает доставку событий за 100 мс, что в 10 раз быстрее, чем REST-опрос. Для тревог это критично.

Приоритеты и отображение

В приложении события ранжируются строго по приоритету:

enum FireEventPriority { alarm, fault, warning, normal } Color getZoneColor(ZoneState state) => switch (state) { ZoneState.alarm => const Color(0xFFD32F2F), // красный ZoneState.fault => const Color(0xFFFF6F00), // оранжевый ZoneState.disabled => const Color(0xFF757575), // серый ZoneState.test => const Color(0xFF1976D2), // синий ZoneState.normal => const Color(0xFF388E3C), // зелёный }; 

Тревога должна быть немедленно видна: FCM priority: high + notification.android.channel_id с IMPORTANCE_HIGH и звуком. На устройствах Xiaomi/Huawei без notification_priority: PRIORITY_MAX уведомление тонет в фоне — это типичная ошибка.

Как мы обеспечиваем надёжность?

Мы проектируем систему так, чтобы отказ мобильного приложения не влиял на пожарную автоматику. Используем дублирование каналов: MQTT + HTTP fallback, кэширование последних состояний на устройстве. Каждое событие тревоги логируется с меткой времени и ID зоны. Гарантируем доставку push-уведомлений в течение 3 секунд при работающем интернете.

Реальный кейс: для торгового центра с 15 ППК Болид (2000 зон) мы развернули отказоустойчивый кластер: два шлюза на разных серверах, MQTT с QoS 2, и отдельный канал для тревог. За год эксплуатации — нулевое количество ложноотрицательных уведомлений.

Настройка push-уведомлений о тревоге

1. Создайте отдельный канал уведомлений в AndroidManifest.xml с IMPORTANCE_HIGH.
2. Настройте FCM с priority: high и укажите channel_id.
3. Для iOS добавьте criticalAlert и content-available: 1 в payload.
4. Протестируйте на реальных устройствах, включая Xiaomi и Huawei.

Push-уведомления на Android через FCM доставляются в среднем за 1-2 секунды, что в 5 раз быстрее, чем через стандартный polling.

Этапы разработки

1. Аналитика и проектирование — обсуждаем тип ППК, количество зон, требования к картографии.
2. Разработка шлюза — пишем конвертер протоколов на Python/C++ под Linux.
3. Мобильное приложение — на Flutter 3.x (Swift/Kotlin для нативной части).
4. Тестирование — unit, integration, нагрузочное до 1000 событий в секунду.
5. Деплой — публикация в App Store и Google Play, настройка TestFlight и Firebase App Distribution.
6. Обучение — инструкция для дежурного персонала, передача исходников и документации.

Состав работ

• Архитектурная документация (схема интеграции, ER-диаграммы)
• Разработка шлюза (Linux, Python/C++, protocol conversion)
• Мобильное приложение (Flutter 3.x, Swift 5.9, Kotlin)
• Настройка push-уведомлений (FCM + APNs)
• Тестирование (unit, integration, нагрузочное)
• Деплой в App Store Connect и Google Play Console
• Обучение дежурного персонала и техническая документация

Журнал событий и ответственный дежурный

Каждое событие тревоги логируется с меткой времени, ID зоны, типом датчика и пользователем, подтвердившим получение. Квитирование в приложении — только информационный слой, не замена физического сброса на ППК.

Благодаря автоматизации, наши клиенты экономят до 30% на ежемесячном мониторинге, исключая ложные выезды и сокращая время реакции. Стоимость разработки рассчитывается индивидуально и зависит от сложности интеграции и количества зон.

Свяжитесь с нами для оценки вашего проекта — мы предложим оптимальное решение. Закажите консультацию по интеграции ваших ППК в мобильное приложение.

Стандарты: NFPA 72, СП 5.13130.2009