- PVSM.RU - https://www.pvsm.ru -
Последние несколько лет я занимаюсь R&D в области интернета вещей и распределенных систем, а так же являюсь Google developer expert IoT. В этой статье я хочу поделиться своим опытом и рассказать про новую концепцию Physical Web. Как реализовать эту концепцию с помощью Google’s beacon platform. Подробно расскажу про разные маячки (англ. Beacon — маяк) и их стандарты. Как централизованно мониторить и управлять большим количеством маячков от разных производителей. А также как добавить возможность взаимодействовать с маячками в приложениях на платформах Android и iOS.
В интернете вещей одним из мегатрендов сейчас являются умные дома, а точнее устройства для дома. Недавно была статья [1] на Geektimes с обзором прогонозов в области интернета вещей от разных компаний. А в конце уходящего 2015 года свой прогонз представили Vision Mobile [2].
У нас уже есть умные термостаты, весы, камеры, телевизоры, холодильники, датчики, замки и тд. С каждыми днём на рынке появляется всё больше и больше умных устройств от самых разных производителей, притом некоторые из них действительно хороши и полезны. Но как сегодня выглядит наше взаимодействие с такими устройствами, например, первоначальная настройка и мониторинг? В подавляющем большинстве случаев, у каждого производителя есть приложение, с помощью которого мы и можем взаимодействовать с его продуктами. На первый взгляд выглядит нормально, так ведь?
Но ведь умные устройства могут нас окружать не только дома. У многих из нас есть приложения для общественного транспорта, оплаты парковок, аренды автомобилей или велосипедов. Но если вы оказываетесь в другой стране по работе или в отпуске, вам скорей всего нужно будет установить еще несколько приложений.
Если мы верим в закон Мура, то маленькие, недорогие, подключенные устройства скоро ворвутся в нашу жизнь, наполняя наши дома, рабочие и общественные места. В настоящее время большинство умных устройств для интернета вещей требует установки специального приложения. Такое узкое решение просто не масштабируется до взаимодействия со всем множеством умных устройств. Я не имею ничего против приложений, приложения это здорово! Но их много и то взаимодействие, которое они нам предлагают не всегда удобно.
Physical Web [3] — это попытка построить мост между цифровым и физическим миром, который позволяет нам расширить суперсилу web — URL — для повседневного использования. В своей основе Physical Web является службой обнаружения: умный объект передает соответствующий URL-адрес, который могут принимать любые устройства поблизости, например ваш смартфон или планшет. Эта простая возможность транслировать URL открывает новые, захватывающие способы взаимодействия.
Представьте, что вы можете легко взаимодействовать со всеми умными устройствами в вашем доме, без труда их настроить или получить диагностические данные. Подойдя к остановке вы можете узнать когда прибудет ближайший автобус, сев в него, вы узнаете информацию по маршруту, время до следующей остановки. В торговом центре вы узнаете об акциях и скидках. Подойдя к торговому автомату, вы сможете купить и получать товар, не уговаривая его принять ваши деньги и даже не прикасаясь к нему. Вы можете купить билет в музей или кино, а подойдя к постеру или предмету экспозиции получить о нем дополнительную информацию. Можно арендовать машину или велосипед, оплатить парковку, совершив меньше ненужных действий. Или занять очередь. Занять очередь, Карл! Мы же в России так любим очереди. Даже если вы окажетесь в другом городе, для вас ничего не изменится.
Всё это возможно без установки кучи ненужных приложений, вам понадобиться одно единственное приложение. На Android это — Physical Web Browser, а на iOS — данный функционал встроен в Google Chrome. Physical Web является естественным решением, предлагающим взаимодействие по требованию без дополнительных усилий и накладных расходов в виде установки приложений.
Это совершенно новый User eXperience [4], предлагаюший взаимодействие по требованию, только тогда когда это действительно нужно пользователю. Вы просто нажимаете на ссылку и получаете то, что вам нужно. Никаких Push уведомлений, вибраций или чего то подобного.
Physical Web еще не готов до конца и не является продуктом Google. Это экспериментальный проект, находящийся на ранней стадии и разрабатываемый Google в открытом виде, как и все вещи, связанные с интернетом.
Как вы уже могли легко догадаться, источником так нужного нам URL являются маячки (англ. Beacon — маяк). Маячки представляют собой простейшее устройство, которое с заданной частотой транслирует какие-то данные, так называемый advertisement packet, с помощью технологии Bluetooth v4 или Bluetooth Low Eenergy(BLE).
Для тех, кто переживает за приватность: маячки принципиально не могут вас отслеживать, они умеет только транслировать сообщения, они ничего о вас не знают. Им всё равно, один человек получает от них пакеты или 30.
Ниже, как пример, представлен маячок от компании Estimote в разобранном виде:
Производителей устройств сейчас достаточно, поэтому на рынке представлены самые различные реализации как по размеру, форм-фактору, так и по назначению. Есть, например, и промышленные реализации, способные работать на улице и питаться от постоянного источника энергии. Цены на готовые устройства также варьируются.
В чем же концептуальная разница между маячками, если не брать в расчет цену и исполнение? Разница заключается в формате транслируемых сообщений.
Сейчас есть три основных стандарта:
На самом деле есть еще стандарты, например PayPal beacon или какие-то свои реализации от вендоров, например gimbal и estimote, но именно перечисленные выше являются на данный момент основными, доминирующими стандартами.
Большинство устройств сейчас умеют транслировать сообщения в любом из этих трех форматов, но давайте рассмотрим их чуть подробнее чтобы понять, в чем между ними разница.
Первым стандартом был iBeacon [5], он был представлен компанией Apple inc. в 2013 году. Основным его назначением было применение в области розничной торговли и мобильного маркетинга, а также для локального позиционирования внутри помещений.
Стандарт iBeacon предполагает трансляцию только 1 типа advertisment packet, который состоит из следующих частей:
Среди недостатков стандарта стоит отметить его проприетарность, отсутствие нативной поддержки на платформе Android и то, что он умеет транслировать только один тип advertisment packet. Зачастую, в каждом отдельном случае вам придется ставить отдельное приложение.
Консорциумом RadiusNetwork's [6] был представлен альтернативный и открытый стандарт AltBeacon [7]. Он изначально разрабатывался как интероперабельный и обратно совместимый со стандартом iBeacon. AltBeacon обладает почти таким же функционалом что и iBeacon, хотя и позволяет передать чуть больше полезной информации.
Из 28 байт Advertisment packet, нам доступны 25 байт которые состоят из:
В свою очередь BEACON ID может быть представлен как у iBeacon, т.е. 16-byte id1 + 2-byte id2 + 2-byte id3
. Подробнее со спецификаций протокола можно ознакомиться здесь [8]. Самый главный недостаток — такой же как у iBeacon: AltBeacon не умеет транслировать URL.
В 2015 году компанией Google был представлен новый и полностью открытый стандарт Eddystone [9], который эволюционировал из проекта URIbeacon [10]. Как и 2 других стандарта, Eddystone — это спецификация протокола, которая определяет формат сообщений BLE. Он призван быть более гибким и устранить недостатки присущие ibeacon и AltBeacon.
В отличие от них, он умеет рассылать уже 3 типа пакетов:
https://goo.gl/Aq18zF
, то любой клиент, который получил этот пакет может посетить этот URL (https://goo.gl/Aq18zF [12]). Так же, Eddystone-URL является основой Physical Web и позволяет легко обнаруживать и взаимодействовать с окружающим нас веб-содержимым. Он включает весь опыт других стандартов, в том числе UriBeacon, из которого он эволюционировал. Так же Eddystone обладает нативной поддержкой как в iOS так и в Android, что тоже карйне важно.
Разные модели маячков инициализириуется и конфигурируютсятся по разному. Конечно, если у вас всего один маячок установленный в пабе или, скажем, 5 установленных где то еще, это нормально, вы легко реализуете Physical web.
Но если вам нужно развернуть большое количество разных устройств, от разных производителей на достаточно большой площади (торговый центр, аэропорт, район города), при том что часть маячков могут быть в постоянном движении, например в транспорте. В таком сулчае у вас возникают проблемы.
Некоторые производители предоставляют свои облачные решения и CMS, например Estimote [13], Kontakt.io [14], Blesh [15] и LightCurb [16].
А Estimote (https://github.com/estimote/ [17]) и Kontakt.io (https://github.com/kontaktio/ [18]) так же дополнительно предоставляют на github свои SDK.
Но на мой взгляд, наиболее универсальным и простым инструментом для решения подобных задач явлется Google's beacon platform.
Google's beacon platform [19] позволяет легко мониторить и управлять сразу всеми устройствами, скажем в торговом центре или аэропорту. Платформа позволяет работать с разными маячками от разных производителей, предоставляй разработчикам единый, простой и гибкий инструмент.
Ниже представлена схема Google's beacon platform:
Для администрирования маячков нам предоставляется Google Proximity Beacon API [20], с помощью которого мы можем регистрировать наши устройства в Google Beacons Registry. В нём хранится информация о зарегистрированных маячках. С клиентской стороны, для взаимодействия с устройствами предлагается использовать Nearby Messages API [21], Places API [22] или что то ещё на ваше усмотрение.
В данном случае, маячки транслируют не URL, о котром мы говорили выше и как это может показаться на первый взгялд, а Advertisment ID (Eddystone-UID). Вместо того что бы напрямую транслировать URL, мы можем привязввать к нашим маячкам, а точнее к их ID, под которым они были зарегистрированы, некие вложения (Attachments), о которых я подробно расскажу ниже. После того как мы обнаружили маячок нашим смартфоном или планшетом, мы делаем запрос по его ID в Beacons Registry, а ответом получаем это самое вложение.
Такой подход позволяет нам избежать неоходимости физичеческого контакта с маячками для их конфигурирования. Мы можем лишь менять вложения которые привязаны к маячкам, тем самым управлять маячками удаленно. Данное решение так же позволяет мониторить все наши маячки удаленно. Как это реализованно я расскажу дальше.
Google Proximity Beacon API — это облачный сервис, который через REST интерфейс позволяет управлять маячками, а точнее связанными с ними данными.
Proximity Beacon API позволяет:
Перед использованием Proximity Beacon API, будет полезно понимать или ознакомиться со следующим:
Для работы с Proximity Beacon API необходимо выполнить 5 следующих шагов:
enabled
После включения и базовой настройки маячка на трансляцию сообщений, Proximity Beacon API может быть использован для его регистрации. К нему мы можем привязать дополнительные данные, которые помогут устройствам пользователей понять где они находятся. Запись в Google Beacons Registry может содержать следующие метаданные:
Подробнее о значениях метаданных вы можете прочитать здесь [30].
Рассылаемый ID (Advertised ID) должын быть корректным Eddystone-UID идентификатором маячка (16 байт, содержащих 10 байт namespaceId и 6 байт instance Id). Значение ID должно быть base64 представлением данных.
Маячки представлены в виде ресурса beacon
(https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons#resource-beacon [31]) и могут быть зарегистрированы вызовом метода beacons.register
.
О других методах вы можете посмотреть здесь [32].
Маячок может быть зарегистрирован одновременно только в одном проекте в Google Developers Console. Попытка зарегистрировать маячок повторно или в другом проекте приведет к ошибке. Как только маячок зарегистрирован, его поле AdvertisedID
не может быть изменено.
Поэтому обязательно настройте ваши маячки соответствующим образом перед регистрацией.
POST
Request URL:
https://proximitybeacon.googleapis.com/v1beta1/beacons:register
Request body:
{
"advertisedId": {
"type": "EDDYSTONE",
"id": "Fr4Z98nSoW0hgAAAAAAAAg=="
},
"status": "ACTIVE",
"placeId": "ChIJTxax6NoSkFQRWPvFXI1LypQ",
"latLng": {
"latitude": "47.6693771",
"longitude": "-122.1966037"
},
"indoorLevel": {
"name": "1"
},
"expectedStability": "STABLE",
"description": "An example beacon.",
"properties": {
"position": "entryway"
}
}
Response:
Если всё прошло удачно, ответом будет статус код: 200 ОК
. Тело ответа содержит JSON представление маячка, содержащее значение beacon.beaconName
, которое может использоваться как ссылка для управления маячком.
После того, как маяк был зарегистрирован, он не может быть просто удален из Google Beacons Registry. Есть два варианта как можно перевести маячок в режим офлайн:
beacons.deactivate
для того что бы временно удалить маячок из нашего проекта. После деактивации, API не будет возвращать ни привязанные данные, ни информацию по маячку. Для того что вернуть маяк в рабочее состояние нужно вызвать beacons.activate
beacons.decommission
что бы навсегда деактивировать beacon ID из нашего проекта. Вы больше не сможете использовать ID с которым он был ранее зарегистрирован. Но вы можете легко назначить маячку новый ID и перерегистрировать маячок с новым IDПосле того как маячок был зарегистрирован, он готов к следующему шагу.
К маячкам можно привязывать произвольные данные, называемые вложениями(Attachments). Они представляют из себя блобы, хранимые в Google’s scalable cloud. В настоящее время, вложения доступны только для проекта в котором они были созданы, вы не сможете использовать их в другом проекте.
При создании вложения вам нужно заполнить два поля:
surreptitious-banjo-145/string
aGVsbG8gd29ybGQh
Что бы выяснить какие пространства имён имён связанны с вашим проектом можно вызвать namespaces.list
.
Вложения могут быть длиной до 1024 байт. Вы можете использовать любой string
который имеет значение для вашего приложения, например, ID для автобусной остановки или раположения магазина, структурированные данные, такие как JSON, или ссылка на внешнюю базу данных.
Крайне советую воздержаться от ссылки на внешнюю базу данных, если вы хотите вернуть большие элементы данных, такие как изображения или видео, а так же если данные лежат на сторонней базе данных, которой вы не управляете.
Крайне не рекомендуется использовать вложения для хранения и передачи каких-либо конфиденциальных данных.
POST
https://proximitybeacon.googleapis.com/v1beta1/beacons/beaconName/attachments
{
"namespacedType":"surreptitious-banjo-145/my-attachment-type",
"data":"aGVsbG8gd29ybGQh"
}
Response:
Если всё прошло удачно, ответом будет статус код: 200 ОК
.
Тело ответа содержит JSON представление вложения, содержащее значение BeaconAttachment.attachment_name
, которое может использоваться как ссылка для управления вложениями.
После того как мы развернули наши маячки, что бы убедиться что они работают должным образом их необходимо мониторить. Кадры Eddystone-TLM позволяют маячкам сообщать свой статус устройствам, которые их обнаруживают, но если маячков много, а площадь на которой они развернуты достаточно велика, то самостоятельный обход маячков со специальным приложением для мониторинга может быть проблемой. Выход из ситуации есть. Мы можем периодически подсовывать пользователю кадры Eddystone-TLM, которые через него будут передаваться нам в Google’s beacon platform. Чередование кадров мониторинга с кадрами, которые непосредственно предназначеными для устройств пользователей (например, Eddystone-UID) происходит через равные интервалы времени установленные при инициализации маячков.
Еще раз. Кадры передаются в облако тогда и только тогда, когда пользователь взаимодействует с маячками!
Хотя, конечно, мы можем написать приложение, которое будет в фоновом режиме сканировать маячки, получать и передавать всю информацию от них, но об этом позже.
В случае если маячок установлен в месте где он не будет часто использоваться, рекомендуется чаще чередовать Eddystone-TLM кадры с целевыми, что бы максимизировать вероятность получения пользователем такого кадра.
В кадре Eddystone-TLM передаются следующие данные:
На основе этих данных Google's beacon platform может предоставить следующую информацию:
Вы можете отслеживать статус маячков с помощью ресурса beacons.diagnostics
.
В следующей части я покажу как добавить возможность взаимодействовать с маячками на клиентской стороне (Android и iOS) c помощью Google Nearby Messages API, indoor навигацию и Google Places APi. А так же расскажу как можно разрабатывать и прототипировать проекты вообще без маячка.
P.S. C удовольствем отвечу на ваши вопросы, а так же учту пожелания для следующей части.
Автор: zviad
Источник [33]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/mobil-naya-razrabotka/113953
Ссылки в тексте:
[1] статья: https://geektimes.ru/company/prestigio/blog/271520/
[2] Vision Mobile: http://www.visionmobile.com/product/iot-megatrends-2016/?utm_source=VisionMobile+subscriber+list&utm_campaign=25bf73aa20-2016_02_08%3A+IoT+Megatrends+Campaign&utm_medium=email&utm_term=0_efe0e34ffa-25bf73aa20-399276517
[3] Physical Web: https://google.github.io/physical-web/
[4] User eXperience: https://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D1%8B%D1%82_%D0%B2%D0%B7%D0%B0%D0%B8%D0%BC%D0%BE%D0%B4%D0%B5%D0%B9%D1%81%D1%82%D0%B2%D0%B8%D1%8F
[5] iBeacon: https://developer.apple.com/ibeacon/
[6] RadiusNetwork's: http://www.radiusnetworks.com/
[7] AltBeacon: http://altbeacon.org/
[8] здесь: https://github.com/AltBeacon/spec
[9] Eddystone: https://github.com/google/eddystone
[10] URIbeacon: http://google.github.io/uribeacon/
[11] https://goo.gl/: https://goo.gl/
[12] https://goo.gl/Aq18zF: https://goo.gl/Aq18zF
[13] Estimote: http://estimote.com/
[14] Kontakt.io: http://kontakt.io/
[15] Blesh: http://docs.blesh.com/docs/getting-started/
[16] LightCurb: https://www.lightcurb.com/en/beacon-platform
[17] https://github.com/estimote/: https://github.com/estimote/
[18] https://github.com/kontaktio/: https://github.com/kontaktio/
[19] Google's beacon platform: https://developers.google.com/beacons/overview
[20] Google Proximity Beacon API: https://developers.google.com/beacons/proximity/guides
[21] Nearby Messages API: https://developers.google.com/nearby/messages/overview
[22] Places API: https://developers.google.com/places/?hl=ru
[23] https://developers.google.com/identity/protocols/OAuth2: https://developers.google.com/identity/protocols/OAuth2
[24] https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services: https://en.wikipedia.org/wiki/Representational_state_transfer#Applied_to_web_services
[25] https://en.wikipedia.org/wiki/JSON: https://en.wikipedia.org/wiki/JSON
[26] https://console.developers.google.com/: https://console.developers.google.com/
[27] https://developers.google.com/beacons/proximity/get-started#step_4_get_an_oauth_20_client_id: https://developers.google.com/beacons/proximity/get-started#step_4_get_an_oauth_20_client_id
[28] https://developers.google.com/beacons/proximity/get-started#step_5_get_an_api_key: https://developers.google.com/beacons/proximity/get-started#step_5_get_an_api_key
[29] https://support.google.com/cloud/answer/6310037: https://support.google.com/cloud/answer/6310037
[30] здесь: https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons#Status
[31] https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons#resource-beacon: https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons#resource-beacon
[32] здесь: https://developers.google.com/beacons/proximity/reference/rest/v1beta1/beacons#methods
[33] Источник: https://habrahabr.ru/post/278443/
Нажмите здесь для печати.