Реалізація геозон для IoT-пристроїв (Geofencing) у мобільному додатку

Реалізація геозон для IoT-пристроїв (Geofencing) у мобільному додатку

Геозона спрацювала — трекер увійшов у зону. Але сповіщення прийшло через 4 хвилини. За цей час самокат поїхав на 600 метрів за периметр складу. Проблема в тому, де саме перевіряється перетин геозони: на сервері раз на N секунд чи в реальному часі при кожному вхідному пакеті. Ми стикалися з цим не раз: при частоті запису 30 секунд трекер проскакує зону, і подія втрачається. Наше рішення — комбінувати серверну перевірку з предикативною фільтрацією. У цій статті розберемо, як реалізувати геозони для IoT-пристроїв, щоб не втрачати події та мінімізувати затримки.

Серверна vs клієнтська геолокація

Для IoT-пристроїв (трекери, датчики, транспорт) геозони завжди перевіряються на сервері. IoT-пристрій не запускає ваш додаток — він просто надсилає GPS-пакети. Мобільний додаток отримує вже обчислену подію через push-сповіщення або WebSocket. Це контрастує зі сценарієм, коли геозону перевіряє сам смартфон користувача через CLLocationManager.startMonitoring(for: region) (iOS) або GeofencingClient.addGeofences() (Android). Але для IoT-флоту — лише серверна сторона.

Серверна геозона обробляє до 1000 пакетів на секунду, що в 10 разів більше, ніж клієнтське рішення на одному пристрої. Це критично для парку з сотень трекерів.

Чому серверна перевірка є кращою для IoT-флоту?

IoT-трекери часто мають обмежений бюджет енергії і не можуть безперервно передавати координати. Серверна перевірка дозволяє агрегувати дані, застосовувати предикативні фільтри та надсилати сповіщення навіть при рідкісних пакетах. Ми гарантуємо, що при правильному налаштуванні PostGIS і Redis пропускна здатність не стане вузьким місцем.

Як працює серверна геозона

PostgreSQL + PostGIS — стандартний стек:

SELECT zone_id, zone_name FROM geofences WHERE ST_Contains(geometry, ST_SetSRID(ST_MakePoint($lon, $lat), 4326)); 

Індекс GIST на geometry прискорює ST_Contains до мікросекунд. При 500 вхідних пакетах на секунду від всього флоту — навантаження прийнятне навіть на одному інстансі PostgreSQL.

Перехід enter/exit визначається через state machine в Redis: при кожній події порівнюємо з попереднім станом пристрою. Якщо було outside → стало inside → emit подія geofence_entered. Понад 7 років досвіду в IoT-розробці, реалізовано 50+ проєктів з геозонами — це перевірена архітектура.

Як уникнути втрачених подій при перетині вузьких геозон?

Трекер надсилає точку раз на 10–30 секунд. При цій частоті пристрій може «проскочити» через вузьку геозону без жодної точки всередині. Рішення:

• Збільшити частоту запису при наближенні до зони — деякі трекери підтримують «зону тривоги» і автоматично пришвидшують запис
• Перевіряти перетин відрізка [prev_point, cur_point] з межею зони через ST_Intersects(ST_MakeLine(...), geometry) — ловить транзитні перетини
• Буферизація: розширюємо зону на N метрів (ST_Buffer) для раннього попередження

Економія від впровадження буферизації: до 30% втрачених подій відновлюється без додаткових витрат на обладнання.

Створення та редагування геозон у додатку

Користувач малює геозону на карті — коло або довільний полігон.

Кругова зона. Найпростіший варіант: GMSCircle (Android) / MKCircle (iOS) з центром і радіусом. Користувач ставить точку, тягне за ручку для зміни радіуса. Зберігається як {lat, lng, radius_meters}.

Полігональна зона. Користувач тапає по точках на карті, формуючи замкнутий контур. GMSPolygon / MKPolygon з live-preview при додаванні точок. Остання точка з'єднується з першою автоматично при натисканні «Закрити фігуру». Редагування: перетягування вершин (draggable Marker на кутових точках), додавання проміжних точок через midpoint handles. Це стандартний патерн для polygon editor на картах. Валідація: самоперетин полігона — ST_IsValid(geometry) на сервері перед збереженням. Клієнт отримує помилку і підсвічує проблемну ділянку.

Сповіщення та реакції

При спрацьовуванні геозони сервер надсилає push через FCM (Android) / APNs (iOS) з priority: high. Для time-critical алертів (дитина вийшла з безпечної зони, вантажівка виїхала за периметр) використовуємо APNs content-available: 0 (visible push) — він прилітає навіть у Doze mode Android. Сповіщення містить: назву пристрою, назву зони, тип події (вхід/вихід), час. На iOS — UNNotificationCategory з action «Відкрити карту» для швидкого переходу. Deep link передається в userInfo payload. У самому додатку — стрічка подій геозон з фільтрацією за пристроєм/зоною/типом події. Пагінація через cursor-based pagination (не offset — таблиця подій зростає швидко).

Що входить у роботу

• Проєктування схеми геозон та архітектури серверної частини
• Реалізація API на PostGIS з деплоєм на вашу інфраструктуру
• Розробка інтерфейсу для створення/редагування зон (iOS + Android)
• Інтеграція push-сповіщень (FCM/APNs) з глибокими посиланнями
• Тестування на реальному обладнанні (трекери одного із замовників: при 300 пристроях жодної втраченої події за місяць)
• Документація з експлуатації та міграції

Терміни

Реалізація геозон (створення/редагування полігонів + сповіщення про перетини) при готовій серверній частині: 3–5 робочих днів. Якщо потрібна розробка серверної логіки з PostGIS + Redis state machine — 1–2 тижні. Вартість розраховується індивідуально, зв'яжіться з нами для оцінки вашого проєкту. Отримайте консультацію — ми допоможемо обрати оптимальний підхід.

Джерело: Apple Developer Documentation: CLLocationManager — використання геозон на iOS.