Пошук людей у великому офісі: як ми подружили бікони з розумними годинниками

Бікони — це вдале рішення для використання всередині будівлі, але компанія Estimote вирішила піти далі і створила nearables — бікони, що використовують технологію BLE. Ми приємно вражені результатами, яких їм вдалося досягнути. Отже, ми спробували витиснути всі соки з Estimote nearables і поєднували їх із мобільними та носимими пристроями, щоби зрозуміти, на що вони здатні у реальності — про це і розповімо у статті.

Забігаючи наперед, пропонуємо коротке відео, в якому ми поділилися своїми враженнями і показали результати нашого дослідження:

Проблема пошуку людей у великих офісах

Під час нашого експерименту ми вирішили використати nearables для стеження за тим, як працівники нашої компанії переміщуються офісом. Насправді це не настільки страшно, як звучить. Компанії з великими офісами завжди стикаються з цією проблемою: як дізнатися місцеперебування працівника у будівлі, особливо якщо він постійно зайнятий на нарадах у різних кімнатах і рідко буває на своєму робочу місці. Очевидно, що для цього ви можете скористатися магією мобільного зв’язку, але по-перше, не всі носять зі собою свої мобільні (звучить дивно, але це правда), а по-друге, переривати нараду телефонним дзвінком — не надто ввічливо. Значно легше — просто дізнатися, де можна знайти людину в даний момент, і вирішити з нею термінове питання під час особистої розмови.

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

Ідея додатку

Нас не цікавлять банальні рішення, тому ідею поєднання nearables зі звичайними телефонами ми відкинули одразу. Натомість, як пристрої для трекання ми взяли розумні годинники Android Wear та Apple Watch. Оскільки ми повністю від’єднали розумні годинники від телефонів, наш додаток повинен був на 100% працювати автономно. Іншою причиною, чому ми обрали розумні годинники для свого експерименту, було бажання перевірити, чи справляться вони з цим завданням, зважаючи на усі їхні обмеження: Bluetooth з низьким енергоспоживанням, API, передачу HTTP, фонові сервіси тощо.

Ідея проста: ми прикріпляємо nearables у всіх ключових точках нашого офісу — біля входу, у ліфтах, на кухнях, у спортзалі тощо. Усі UUID nearables ми під’єднуємо до кожної з цих точок. Паралельно, наші працівники інсталюють додаток на своїх розумних годинниках і реєструють їх (це, безсумнівно, вимагає їхньої згоди). Це єдина дія, що вимагається від користувачів.

Ми задумали, що, у першу чергу, додаток повинен виконувати такі фукнції:
— Логуватися (через телефон);
— Давати дозвіл на фоновий сервіс, який буде взаємодіяти з біконами (на розумному годиннику);
— Надсилати UUID, отримані від nearables, розпізнаних поблизу — разом з ІD користувача і поточним часом (на розумному годиннику);
— Показувати на дисплеї точки перебування працівників, опираючись на серверні дані («пріоритетних» працівників — на розумному годиннику і телефоні; усіх працівників — тільки на телефоні).

Додаткові функції включатимуть:
— Можливість маркувати працівників, яких ви шукаєте найчастіше, як «пріоритетних», щоби інформація про місце їхнього перебування зберігалася окремо (на телефоні);
— Можливість пошуку людей за іменем (на телефоні).

Як це повинно було працювати

Коли ми працювали з шаблонами на смартфонах, у нас не виникало жодних проблем, пов’язаних з SDK. Тому ми сподівалися, що з розумними годинниками також все пройде гладко. За нашим задумом, розумний годинник повинен був отримувати інформацію з найближчого nearable, надсилати її серверу, щоб інформація про ваше поточне місце розташування ставала доступною для інших користувачів. Звучить нескладно, правда?

Android

Якщо ви використовуєте одну і ту ж систему на телефоні і розумному годиннику, це означає, що ви можете використовувати усі існуючі бібліотеки, анімації та SDK на маленькому екрані. Тому ми мали намір використати SDK від Estimote на годиннику таким самим чином, як ми робили це на телефоні. Зважаючи на зміни в Android Wear, пов’язані з появою підтримки Wi-Fi (якщо він доступний на апаратному рівні), ми хотіли використати безпровідну мережу для пересилання даних зі стікера на сервер.

iOS

Ми вже бачили, як пошук біконів працює на iOS, коли тестували SDK Estimote. У моделі watchOS 2 передбачена можливість доступу до хардверної частини годинника і комунікація напряму зі знайомими Wi-Fi точками. Саме тому нам дуже кортіло дізнатися, чи, працюючи в автономному режимі, додатки Apple Watch зможуть розпізнавати бікони Estimote.

Як це працювало насправді

Android

На щастя, у нас не виникло проблем із запуском Estimote SDK на годиннику Android Wear. Хлопці з Estimote створили вичерпні зразки, тому ми витратили небагато часу на написання простого сервісу під розумний годинник для комунікації з nearables у фоновому режимі.

Проте, ми все-таки зіткнулися з деякими проблемами. Наприклад, ми не могли покластися на SDK у обробці подій, коли ґаджет з’являється чи зникає із радіуса досяжності nearable. Це працювало з біконами, але не зі стікерами. Ми просто-напросто не отримували від стікерів жодних сигналів. Тоді ми пішли в обхід і використали іншу опцію: слухача (the listener), який опрацьовує кожну подію, отриману з nearable (близько двох подій за секунду). І вуаля — нам вдалося отримати дані від стікера. Тоді прийшов час передавати їх на сервер.

Раніше для пересилки даних з годинника на сервер ми використовували один із DataLayerAPI, щоби передавати інформацію на телефон, яку би той надсилав на сервер. Але чи можливо пересилати дані з годинника безпосередньо на сервер за допомогою Wi-Fi? Відповідь: так.

Але тут є декілька нюансів, до яких ви повинні бути готові:
— Розумний годинник не повинен бути приєднаним до телефону.
— Розумний годинник повинен бути під’єднаний до Wi-Fi-мережі.

Окрім цього, майте на увазі, що Wi-Fi-звязок може бути автоматично втрачений, коли заряд батареї буде низький (це може бути закладено в налаштуваннях годинника).

Дотримуючись цих вказівок, ви можете використовувати свій звичний код для того, щоби надсилати HTTP-запити. До прикладу ми використовували OkHttp-бібліотеку. Так ми відображали дані про місце перебування потрібних нам людей. Тут є один мінус — ви не можете налаштувати свій додаток, допоки не під’єднаєте годинник до телефону. В загальному, ось так це працювало на моєму столі, де лежали nearables, телефон і годинник.

watchOS

Моніторинг nearables за допомогою існуючого Estimote WatchKit SDKпрацював лише на моделі watchOS 1. Самі додатки працюють на iPhone, а Apple Watch в цьому випадку використовується тут лише для виведення сповіщень на екран. Оскільки на моделі OS2 додатки запускаються безпосередньо на годиннику, ми не можемо тут використати цей SDK. Ми пробували різні обхідні шляхи, щоби примусити Apple Watch знаходити nearables, але виглядає на те, що Apple добряче постарався, аби унеможливити цю функцію на своєму розумному годиннику.

Більше технічних деталей представлено у нашому R&D-блозі.

iOS

Ми створили простий демо-додаток, який би шукав «знайомі» nearables і надсилав оновлення про місце перебування користувачів на сервер. Для того, щоби додаток здійснював фоновий моніторинг, для нього має бути дозволений фоновий режим: «Додаток комунікує через CoreBluethooth».

Існує 2 API, які дозволяють пошук біконів на iOS-платформі, використовуючи Estimote SDK:
— Пошук в радіусі. Запускається лише коли пристрій вловлює поблизу бікон. Спрацьовує приблизно 2 рази на секунду, якщо користувач перебуває поблизу бікона;
— Моніторинг. Запускається, коли користувач входить або виходить із зони бікона. Є дві опції, доступні під час роботи з API. Перша — сканувати середовище, шукаючи бікони у зоні досяжності. Друга — полювати лише на бікони зі спеціальними характеристиками.

Якщо обидві ці опції чудово працюють, коли додаток перебуває у фоновому режимі, то, коли телефон заблокований, вони поводяться трохи по-іншому:
— Пошук в радіусі не працює, якщо додаток працює у фоновому режимі. Це було зроблено для того, щоби у фоновому режимі додаток не запускався надто часто, коли користувач перебуває біля бікона;
— Моніторинг працює лише якщо ви хочете отримувати сповіщення про те, що ви увійшли у зону того чи іншого бікона, чи вийшли з неї. Це означає, що ми не можемо отримувати сповіщення про всі навколишні бікони, коли додаток працює у фоновому режимі.

І ще одна річ. Якщо користувач вимкнув додаток, система не буде запускати його, навіть якщо у радіусі був знайдений знайомий бікон. Вимикаючи додаток, користувач дає знак, що він більше не хоче, щоби додаток виконував які-небудь функції, тому це досить логічно, що він буде запускатися самостійно. Однак, якщо додаток був зупинений системою (наприклад, через перевантаженість пам’яті), iOS запустить його і повідомить про впольований бікон.

Поведінка у реальних умовах

Зрозуміло, що тестування у реальних умовах дало нам більше цікавих нюансів і допомогло виявити проблеми, яких ми до того не помічали. Nearables виявилися не надто надійними, адже кожен з них поводився по-різному. Інтенсивність сигналу для одного і того ж nearable у тих самих умовах суттєво відрізнялися. Більше того, чотири стікери перестали працювати ще до завершення нашого тестування.

Ось два найважливіші висновки:
— Середня відстань, яка повинна бути між біконом і ґаджетом, щоби між ними встановився зв’язок, складає близько 1 метра. Чи цього достатньо? Насправді ні.
— Часу, щоби виявити бікон, у найкращому випадку потрібно до 3 секунд — що не так вже й погано.

Було цікаво спостерігати за тим, як різні перешкоди впливають на роботу nearables. Наприклад, двері ніяк не вплинули на інтенсивність сигналу, на відміну від склянок з водою (знову ж так, різні стікери поводили себе по-різному).

Час з’єднання:

Підсумки

Незважаючи на все це, ми вважаємо, що нам вдалося досягти своєї початкової цілі з Android Wear. Додаток отримував інформацію від біконів, що перебували у зоні досяжності, надсилав її на сервер, а також отримував інформацію про розміщення інших біконів — при тому що додаток був встановлений на розумному годиннику, від’єднаному від смартфона.

З watchOS нам вдалося досягнути своєї мети лише частково.

Отже, наш експеримент з nearables залишив нам змішані відчуття. Тобто ми не були вражені результатами. В основному через те, що хоча nearables працюють без суттєвих затримок у часі, їх відстань до об’єктів не повинна перевищувати 1 метра. Однак якщо заглянете на сайт estimote.com, то побачите, що стікери промарковані статусом «В очікуванні на сертифікацію», проте нам пощастило їх отримати. Ми також використовували ранні версії SDK (першу версію для Android) і, сподіваємося, що багато проблем вже було виправлено і багато чого вдосконалено у пізніших версіях. Одне ми можемо сказати напевне: бікони — це дивовижна технологія, яка має великий потенціал для розвитку у майбутньому.

Стаття написана у свівавторстві з Богданом Мельничуком. Дякуємо Марті Чавазі за адаптацію з англійської.