Ваша система моніторингу виявила проблему — температура в серверній піднялася до 45°C о 3 ночі. Push-сповіщення прийшло о 9 ранку, коли смартфон підключився до Wi-Fi. Обладнання перегрілося. Це неприпустима затримка. У нашій практиці ми стикалися з такими інцидентами і виробили надійну архітектуру критичних алертів для IoT-датчиків, де доставка займає не більше 3 секунд. Ми використовуємо комбінацію FCM high priority та APNs critical alerts, які гарантують отримання навіть у режимі «Не турбувати». Досвід команди — 10+ років у мобільній розробці та IoT. Ми також реалізували багаторівневу систему пріоритетів: від info (батарея розряджена) до emergency (витік CO). Для критичних подій ми гарантуємо доставку за 1-2 секунди у 99.9% випадків.
Apple Developer Documentation зазначає, що entitlement на критичні сповіщення видається лише додаткам із чіткою потребою в порушенні тиші. Ми допомагаємо отримати його та правильно налаштувати.
Чому стандартний FCM не підходить для критичних IoT-алертів?
FCM нормальний пріоритет (normal) буферизує доставку коли пристрій у Doze Mode. Для некритичних сповіщень це нормально. Для IoT-алертів — ні.
Потрібен "priority": "high" у FCM payload + на iOS apns-priority: 10 з interruption-level: critical. Останнє — особливий випадок: UNNotificationInterruptionLevel.critical відтворює звук навіть у режимі «Не турбувати» та при ввімкненому беззвучному режимі. Вимагає спеціального entitlement com.apple.developer.usernotifications.critical-alerts, який потрібно окремо запитувати у Apple.
Запит дозволу на критичні сповіщення — окремий промпт, відрізняється від стандартного:
UNUserNotificationCenter.current().requestAuthorization( options: [.alert, .sound, .badge, .criticalAlert] ) { granted, error in ... } Користувач має явно дозволити критичні сповіщення — не можна ввімкнути їх без згоди.
Як забезпечити доставку алерту при нестабільному інтернеті?
Для безперервного зв'язку з датчиками використовуємо MQTT — легкий протокол з QoS 1. Це гарантує, що повідомлення буде доставлено хоча б один раз. На сервері додатково впроваджено механізм підтверджень: якщо клієнт не отримав алерт, повторюємо відправку з експоненційною затримкою до 5 хвилин. При цьому критичні сповіщення дублюються через SMS-шлюз (Twilio або аналог), щоб забезпечити максимальну надійність.
Як влаштований IoT pipeline?
Датчики → MQTT-брокер (Mosquitto або AWS IoT Core) → серверний обробник → FCM/APNs.
MQTT — де-факто стандарт для IoT: легкий протокол, працює при нестабільному з'єднанні, підтримує QoS 0/1/2. Датчики публікують дані в топік sensors/{device_id}/temperature, сервер підписується на всі топіки пристроїв користувача.
Серверний обробник при отриманні повідомлення перевіряє значення проти порогових правил:
const rules = await getRulesForDevice(deviceId); for (const rule of rules) { if (rule.condition(value)) { await sendCriticalAlert(userId, { sensor: deviceId, metric: rule.metric, value, threshold: rule.threshold, severity: rule.severity }); } } Дедуплікація обов'язкова. Якщо датчик шле дані кожні 10 секунд і температура тримається вище порогу 30 хвилин — це не 180 сповіщень, а одне з оновленням статусу. Redis: SET alert:{device}:{metric}:active 1 EX 1800 — поки ключ існує, нові алерти за цією умовою не надсилаємо.
Порівняння каналів доставки критичних сповіщень
| Канал | Затримка | Надійність | Особливості |
|---|---|---|---|
| FCM high priority | <2 сек | Висока | Потребує priority:high |
| APNs critical | <1 сек | Максимальна | Окремий entitlement |
| SMS | 5-30 сек | Середня | Альтернативний канал |
| 1-10 хв | Низька | Для аналітики |
APNs critical alerts доставляються в 5 разів швидше стандартних push-сповіщень. Для критичних датчиків (CO, температура>45°C) використовуємо комбінацію push + SMS. Надійність гарантується до 99,9% при правильному налаштуванні.
Багаторівнева система алертів
| Рівень | Приклад | FCM priority | iOS level | Дія |
|---|---|---|---|---|
| Info | Батарея датчика 20% | normal | passive | У шторці |
| Warning | Температура >35°C | high | active | Будить екран |
| Critical | Температура >45°C | high | critical | Звук у беззвучному |
| Emergency | Датчик CO >200 ppm | high | critical | Звук + вібрація |
На Android аналогічно через notification channels з різним importance: IMPORTANCE_DEFAULT, IMPORTANCE_HIGH, IMPORTANCE_MAX.
Мобільний додаток: екран моніторингу
Dashboard з live-даними датчиків — реалізуємо через WebSocket з'єднання (не polling, щоб бачити оновлення в реальному часі при відкритому додатку). На Flutter: web_socket_channel пакет, дані в Riverpod StreamProvider.
Історичні графіки — fl_chart або syncfusion_flutter_charts. Зберігання історії на сервері в InfluxDB або TimescaleDB (PostgreSQL extension) — обидва оптимізовані для часових рядів.
Налаштування порогових правил у додатку: користувач вибирає датчик, метрику, оператор (>, <, ==), значення, рівень критичності. Правила зберігаються на сервері.
Що входить в роботу
- Проектування схеми MQTT-топіків і вибір брокера (Mosquitto / AWS IoT Core / VerneMQ)
- Розробка серверного обробника з дедуплікацією та експоненційною затримкою
- Налаштування FCM high priority та APNs critical alerts із запитом entitlement
- Реалізація мобільного клієнта (dashboard, WebSocket, налаштування правил, історія інцидентів)
- Інтеграція з SMS-шлюзом (Twilio або аналог) для аварійних алертів
- Документація з інтеграції та навчання персоналу
- Тестування в сценаріях: Doze Mode, «Не турбувати», низький заряд батареї
- Підтримка після запуску (2 тижні моніторингу)
Як отримати entitlement від Apple
Для запиту critical-alerts entitlement потрібно відправити форму в Apple Developer Support, описавши сценарій використання. Процес займає 1-2 тижні. Ми супроводжуємо заявку та допомагаємо підготувати обґрунтування.Досвід команди
Ми виконали понад 50 проектів у сфері IoT та мобільної розробки. Сертифіковані спеціалісти з Swift, Kotlin та Flutter. Гарантуємо SLA доставки алертів — 99,9% при виконанні рекомендацій. Замовте консультацію за вашим проектом — ми оцінимо терміни та обсяг робіт. Зв'яжіться з нами — отримайте оцінку вартості індивідуально.
Процес розробки
- Аналітика: аудит поточної IoT-інфраструктури та вимог
- Проектування: схема топіків, вибір брокера, архітектура обробника
- Реалізація: серверний обробник + мобільний клієнт (паралельно)
- Тестування: модульне, інтеграційне, навантажувальне (до 10000 датчиків)
- Деплой: налаштування CI/CD, моніторинг (Prometheus + Grafana)
Інвестиції в розробку окупаються в середньому за 3-6 місяців. Зв'яжіться з нами для точної оцінки вашого проекту — отримайте консультацію безкоштовно.