company_banner

Universal Mobile Electronic Key

    Не могу сказать, что я почувствовал большое воодушевление, когда мне предложили поучаствовать в проекте «Device Lab от Google», однако, без сомнения, интерес присутствовал. Когда-то я делал проект с различными взаимодействиями через Bluetooth, и у меня получились крайне интересные реализации. Однако оказалось, что в ходе манипуляций с Bluetooth все телефоны, владельцы которых по недосмотру отставили их включенными в радиусе работы Bluetooth, теряли заряд в три раза быстрее, чем обычно. Коллеги, само собой, не очень радовались. Проект пришлось закрыть. В связи с этим мне давно хотелось подержать в «цепких» руках маячки последнего поколения. И проект Device Lab мне такую возможность предоставил.


    Статья автора Дмитрия Сенашенко (@DmitrySen), в рамках конкурса «Device Lab от Google».

    На рынке сейчас присутствует множество маячков и их производителей. И в большинстве своем они предназначены для определения геолокации внутри зданий. Есть интересные идеи из разряда встраивания маячков в чемоданы, чтобы по их сигналу искать их в аэропорту. Но, учитывая мощности, это выглядит как игрушка. Хотелось придумать и реализовать нечто оригинальное и полезное одновременно. Итак, немного формальностей на сайте и в офисе Хабра, и маячок iBKS у меня в руках:


    О маячках написано много. Например: «Google's beacon platform. Часть 1» или «Google's beacon platform. Часть 2». Повторяться не буду, однако скажу, что предполагалось использовать маячок с Google’s beacon platform и работать с ней по API. Реальность расставила свои точки над «i», о чем я расскажу немного позже.

    По жизни я работаю с телефонией и интеллектуальными IVR с поддержкой email, html, sms и т.д. Поэтому имеются готовые стенды, легко достать необходимое оборудование и т.д. И именно к этой тематике мне и хотелось приспособить маячки.

    Идея


    Итак, мне пришла в голову идея использовать маячки как ключ авторизации к дверям в офисе. Как всем известно, в каждом офисе есть двери с электронными замками и считывателем при входе. У каждого сотрудника есть ключ в виде карточки, и для входа в дверь ему необходимо приложить данную карточку к считывателю, после чего дверь откроется. В мире количество таких дверей исчисляется многими миллиардами, а количество карточек, наверное, триллионами. Хотя на самом деле пользоваться ими не очень удобно. Если ты спешишь на важное совещание, то терять время на то, чтобы извлечь карточку (или извлечь предмет, в котором лежит эта карточка – кошелек, папку с документами) весьма утомительно.

    Однако у каждого человека в кармане теперь есть телефон. И у некоторых – даже носимая на руке электроника. Проще встретить человека, забывшего карточку, чем забывшего свой телефон. Поэтому удобнее и экономически целесообразнее заменить карточку на телефон, а считыватель – на маячок. Конечно, существуют неплохие идеи в этом направлении.

    Например, дверная ручка со считывателем отпечатков пальцев, NFC в телефоне и т.д. Но технология NFC так и не появилась в каждом смартфоне, а вот Bluetooth как раз в каждом смартфоне есть. Поэтому технологически данная идея уже фактически готова к реализации.

    К тому же такое решение повышает степень комфорта сотрудников. Подходя к двери, достаточно нажать на иконку приложения, и после прохождения авторизации дверь откроется. Т.е. ее можно открыть еще из лифта или на подходе к двери. Кроме того, можно открыть дверь с часов или сказав об этом в наушники с микрофоном персональному ассистенту. Важным фактором является авторизация. Давайте взглянем на это подробнее. См. рисунок 1.

    Принципиальная схема работы


    Телефон входит в зону видимости маячка, находит его, используя Beacon Discover, и через Nearby messages API получает из Google Beacons Registry его attachment. Далее через Wifi или мобильный интернет в шифрованной сессии телефон отсылает этот аттачмент и свой IMEI или другой уникальный код, заданный при установке приложения, на сервер авторизации. Сервер авторизации идентифицирует права на доступ и в случае положительного решения дает команду на сервер управления электронными замками открыть соответствующий замок, основываясь на данных из attachment, которые уникальным образом характеризуют дверь. Сервер управления электронными замками дает команду исполнительному устройству открыть дверь.


    Рисунок 1. Схема организации взаимодействия

    Вот такое решение пришло мне в голову, и теперь давайте попробуем его реализовать.

    Воплощаем идею в железе


    В моем распоряжении была АТС компании Avaya со шлюзом G250. Это старый шлюз, давно снятый с производства. Но его новая замена — шлюз G450/G430 — имеет также необходимые нам компоненты, а именно привод управления электронным замком двери. В данный шлюз для потребностей малых офисов встроено сухое реле — так называемый Contact Closure Adjunct (см. рисунок 2).


    Рисунок 2. Шлюз G430 производства Avaya

    Этим разъемом можно управлять набором произвольного преднастроенного телефонного номера. При наборе этого номера шлюз замыкает реле и дает сигнал на открытие электронного замка.

    Далее, у меня был в наличии рабочий стенд с IVR (Interactive Voice Response) производства также компании Avaya. Это полностью программный сервис, обладающий возможностями обработки не только голосовых запросов, но и email, смс и, что в данном решении и понадобится, html-запросов. Также этот IVR умеет инициировать не только email и смс, но и голосовые звонки. Т.е. по отношению к данному проекту этот IVR может получить запрос по html с передачей переменных и по результатам обработки этих переменных инициировать исходящий голосовой вызов на некий номер. Обработка запроса в IVR может быть проведена как встроенными средствами, так и с использованием языка программирования Java. В связи с этим в роли сервера авторизации был применен как раз этот IVR. В роли сервера управления электронным замком использовалась АТС Avaya Aura Communication Manager со шлюзом G250. Электронный замок также имелся в наличии.

    Таким образом, приложению на мобильном телефоне требовалось получить идентификатор маячка, связаться с Google Beacons Registry и получить его аттачмент, после чего в html запросе отослать эту информацию и свой IMEI на IVR, который, проверив ее, сделает набор на АТС, дав таким образом сигнал для замыкания на шлюзе G250 сухого реле Contact Closure и открыв таким образом дверь.

    Ну и последним шагом подготовки к реализации стало получение мобильного телефона под управлением операционной системы Android. Это был HTC Desire c Android Lollipop 5.1.1. Ну и, конечно, необходима была также установка Android Studio на свой ноутбук.

    Все было готово, и я приступил. Как обычно, реальность расставила точки на «i».

    Подводные камни


    Для начала маячок требуется зарегистрировать в Google Beacon Registry. Проще всего это сделать через мобильное приложение Google Beacon Tools, доступное как в Google Play Market, так и в Apple App Store.

    Я включил маячок, удалив пластиковый разъединитель между микросхемой и батарейкой, установил Google Beacon Tools и стал искать маячок. Он не появлялся. Тогда я скачал приложение производителя iBKS Config Tool. Это приложении тоже доступно как для Android, так и для IOS устройств. И — о чудо! Маячок появился.


    Рисунок 3. iBKS Config Tool

    Однако в Google Beacon Tools он упорно появляться не хотел. Проштудировав интернет, я вычитал, что требуется войти в режим редактирования на iBKS Config Tool и изменить тип трансляции маячка. В режим редактирования приложение упорно входить отказывалось, как на Android, так и на iOS. Войти в этот режим удалось только после выключения и повторного включения маячка путем удаления батарейки. На всё про всё было около 30 секунд, далее маячок опять блокировался. Понять, это фича или бага, мне не удалось. Это нигде не описывалось. См. рисунок 4.


    Рисунок 4. Режим редактирования iBKS Config Tool

    Поменяв Advertising Mode c 1 на 7 (см. рисунок 5), я наконец-то увидел маячок в Google Beacon Tools (см. рисунок 6). Но регистрироваться он упорно отказывался.


    Рисунок 5. Выбор Advertising Mode


    Рисунок 6. Google Beacon Tools

    Google Beacon Tools для регистрации требовал, чтобы маячок находился в режиме iBeacon или Eddystone UUID., но в этом режиме он его упорно не видел. В режиме же Eddystone URL он его видел, но регистрировать отказывался. Поведение этого приложения на Android и IOS было одинаковое, хотя на Android приложение сначала выбирало проект и только потом отказывалось регистрировать маячок.

    Что явилось причиной такого поведения маячка, выяснить в ходе проекта не удалось. Такое впечатление, что сам маячок был проблемный. Стоило его, конечно, заменить, но реализация проекта была ограниченна временным рамками, и на новую поездку в офис Хабра времени не было. Из опытов с iBKS Config Tool и Google Beacon Tools было понятно, что маячок излучает, причем передавая свой уникальный идентификатор. Поэтому было принято решение проводить идентификацию маячка для демонстрационного стенда не по attachment, полученного от Google Beacons Registry, а по его идентификатору. В целом для прототипа решения такая замена вполне адекватна.

    Итак, осталось только найти Java-библиотеку, которая позволяла бы в Android Studio организовать обнаружение идентификатора маячка. На помощь, конечно, пришелся GitHub и библиотека Radiusnetwork.com.eddystonedemo. Эта библиотека позволяет видеть транслируемый маячком его идентификатор, который также виден через iBKS Config Tool. Описание дано тут.

    Был организован Activity (см. рисунок 7), который имел большую серую кнопку. Эта кнопка после нахождения маячка меняла цвет, имя и свойство Clickable. Т.е., пока маячок не найден, при нажатии на кнопку ничего не происходит. Как только маячок найден, то кнопка становится красной и позволяет на себя нажать. При нажатии на кнопку вызывается URL, ведущий на приложение IVR с передачей IMEI, которое его проверяет, и в случае успешности формирует вызов по протоколу SIP на сервер управления электронным замком. В случае потери сигнала маячка (увеличения расстояния до него или его выключения) кнопка меняет цвет и свойство Clickable обратно.


    Рисунок 7. Скриншоты приложения

    Код и конечная реализация


    Целиком проект можно найти Github здесь. Остановимся на деталях. Ниже приведена функция, вызываемая при нахождении маячка:

    public void didRangeBeaconsInRegion(Collection<Beacon> beacons, Region region) {
     for (Beacon beacon: beacons) {
     if (beacon.getServiceUuid() == 0xfeaa && beacon.getBeaconTypeCode() == 0x00) {
     // This is a Eddystone-UID frame
     Identifier namespaceId = beacon.getId1();
     Identifier instanceId = beacon.getId2();
     foundBeacon = namespaceId.toString();
    //проверка идентификатора маячка для упрощения проекта проводится здесь. Ниже проверяется именно идентификатор моего конкретного маячка.
     if (foundBeacon.equals("0xba1c51bab3147efee8e5")) {
     Log.d("Found beacon", foundBeacon);
    //Это необходимо чтобы менять свойство обратно при потере маячка
     found = true;
     runOnUiThread(new Runnable() {
     public void run() {
    //Здесь проводится смена надписи, цвета и свойства Clickable при нахождении маячка.
     mainButton.setText("You can open the door now");
     mainButton.setBackgroundColor(0xffef0606);
     mainButton.setClickable(true);
     }
     });
     }
     Log.d("RangingActivity", "I see a beacon transmitting namespace id: " + namespaceId +
     " and instance id: " + instanceId +
     " approximately " + beacon.getDistance() + " meters away.");
     runOnUiThread(new Runnable() {
     public void run() {
     ((TextView) RangingActivity.this.findViewById(R.id.foundbeacon)).setText("Found beacon - " + foundBeacon);
     }
     });
     }
     }
    }
    

    Ниже приведена функция вызова URL на IVR:

    public void buttonClick(View view) {
    //Вызов этой функции возвращает IMEI телефона
     String ret = telephonyManager.getDeviceId();
     Log.d("IMEI", ret);
     //URL ниже ведет на IP адрес IVR и вызывает приложение обработки HTML запросов под названием OpenTheDoor и передает туда идентификатор маячка и IMEI
    webview.loadUrl("http://192.168.0.204:7080/Redirector/?AVAYAEP__LaunchId=OpenTheDoor&beacon=" +
     foundBeacon + "&imei=" + ret.toString());
    }
    

    Таймер в данном приложении нужен, чтобы гасить кнопку при потере доступности телефона через 5 секунд после потери.

    protected void onCreate(Bundle savedInstanceState) {
     super.onCreate(savedInstanceState);
     setContentView(R.layout.activity_ranging);
     mainButton = (Button) findViewById(R.id.mainbutton);
     telephonyManager = (TelephonyManager) getSystemService(Context.TELEPHONY_SERVICE);
     webview = (WebView)findViewById(R.id.webView);
    //таймер деактивации кнопки
     mTimer = new Timer();
     mMyTimerTask = new MyTimerTask();
     mTimer.schedule(mMyTimerTask, 1000, 5000);
    }
    
     class MyTimerTask extends TimerTask {
     @Override
     public void run() {
     if (found) {
     found = false;
     }
     else {
     runOnUiThread(new Runnable() {
     public void run() {
    //Смена свойств кнопки по потере доступности маячка
     mainButton.setText("Open the door");
     mainButton.setBackgroundColor(0xffcfc3c3);
     mainButton.setClickable(false);
     ((TextView) RangingActivity.this.findViewById(R.id.foundbeacon)).setText("");
     }
     });
     }
     }
     }
    }
    

    Разработка приложений для IVR проводится в специализированной среде Avaya Aura Orchestration Designer и базируется на среде разработки Eclipse. По сути под каждым элементом скрывается Java-код. Сборка приложения для упрощения разработки проводится в стиле Drag<&>Drop. На рисунке 8 приведен скриншот экрана среды разработки приложений для IVR.


    Рисунок 8. Среда разработки Avaya Aura Orchestration Designer

    Это приложение имеет два главных модуля: Data1 и Outcalling. Скриншоты этих модулей приведены на рисунках 9 и 10.


    Рисунок 9. Модуль Data1


    Рисунок 10. Модуль Outcalling

    В модуле Data1 проводится фактически авторизация идентификатора маячка и IMEI: если оба правильны, то проводится перевод на модуль Outcalling, в котором формируется исходящий вызов на преднастроенный номер, хранящийся в переменной CalledNumber. В данной переменной устанавливается номер, настроенный в ATС для срабатывания сухого реле ContactClosure, подключенного к электронному замку двери.

    Полный проект можно найти здесь.

    Ну и в заключение по вот этому адресу выложено видео, в котором дано описание проекта и проведена демонстрация уже готового проекта. Спасибо за внимание!
    Google 92,16
    Филин Лаки
    Поделиться публикацией
    Комментарии 19
    • +1
      Идея интересная. Есть несколько вопросов:
      1. Как быстро происходит обнаружение нового устройства (маячка телефоном), ведь если я спешу, то мне не хочется ждать 10 секунд перед дверью, пока произойдёт обнаружение маячка, идентификация и связь с сервером.
      2. На сколько этот поиск влияет на заряд батареи телефона?

      Чисто теоретически, чем реже происходит поиск новых устройств и передача данных по радиоканалу, тем меньше садится батарея, как у маячка, так и у телефона.
      • 0
        Ну около 5-10 секунд. В целом быстро. Учитывая, что телефон начинает ее искать метров за 30, то при подходе к двери и даже раньше он его всегда находит. Можно конечно предположить гипотетическую ситуацию, когда дверь находится сразу при открытии дверей лифта за сплошной бетонной стеной с заземленной экранировкой. Тогда да, может возникнуть ситуация, когда надо будет ждать. Я поделал эксперименты со своей дверью, маячок за стеной из пеноблоков исправно находился метров за 15 до двери.
      • +5
        если вы хотели облегчить/ускорить открывание двери, то она должна разблокироваться при приближении человека (в идеале при касании ручки).

        вы не написали про скорость вашего решения, похоже умышленно. так как очевидно, что оно значительно медленнее карточки.

        и карточку и телефон надо доставать (и да, карточку тоже можно достать заранее). карточку не нужно разблокировать, выбирать приложение, нажимать кнопку…
        • 0
          Понимаете, тут же важен сам факт верификации двери и телефона. Можно же сделать реализацию когда кнопка на телефоне будет нажиматься сама. Т.е. вы подходите к двери и она открывается, верифицируясь по телефону и маячку. Однако а как быть если вы просто проходите мимо? Ну то есть должен быть факт принятия решения.
          Относительно карточки и телефона. Еще неизвестно что быстрее достается и в любом случае это практически равноценно. Также можно переносить кнопку принятия решения открытия двери на носимую электронику. ну то есть например на часы. Тогда открытие двери будет еще проще.
        • +3
          В качестве недостатка имеющегося решения с карточкой:

          Если ты спешишь на важное совещание, то терять время на то, чтобы извлечь карточку (или извлечь предмет, в котором лежит эта карточка – кошелек, папку с документами) весьма утомительно.


          И тут же, в качестве достоинства предлагаемого решения:

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


          Т.е. там — просто достать кусок пластика и, возможно, приложить к считывателю, а тут — достать телефон, разблокировать, запустить приложение…

          Всегда удивлялся, как люди умудряются объективно более сложное решение, требующее большего кол-ва действий, признать более простым и удобным. Ну вот как?
          • 0
            Ну тут вопрос то этот эмпирический. Кому как удобно. Вот я например, работая в офисах с такими дверьми уже более 15 лет, не держу карточку отдельно. Иначе ее просто забыть или потерять. У меня персонально карточка лежит в кошельке. Потому что он всегда со мной. В зависимости от его наполненности :-) его бывает не просто достать из кармана. А телефон всегда ближе. Работа у меня требует частых переговоров и это мой инструмент.
            Поэтому я не готов с вами согласиться. Мне телефон достать быстрее чем кошелек с карточкой. Хотя у кого-то наверное карточка лежит в чехле телефона и это вообще равноценно.

            В данном решении несколько аспектов. 1- удобство пользования. По поводу вытаскивания карточки и телефона вопрос эмпирический. Я с этим согласен. При условии носимой электроники — однозначно удобнее. Но не у каждого она есть. При условии расположения двери в конце коридора и возможности разрешения открытия двери без нажатия кнопки — тоже удобнее.
            2 аспект — удобство обслуживания сети маячков вместо сети считывателей. Это конечно вопрос IT, а не пользователей.
            • 0
              Мне телефон достать быстрее чем кошелек с карточкой.


              Ну, пусть так. Но дальше-то начинаются отличия — телефон надо разблокировать и т.д. Если выскользнул из рук — то последствия лежат в очень широком диапазоне. А если карточка упала на пол (хоть бы и вместе с кошельком) — то отряхнул и дальше пошел.

              Не, не понимаю. ;) Т.е. в некоторых деталях — понимаю и соглашаюсь, но в целом — не понимаю.
              • 0
                Ну развивается же NFC или Apple Pay. Это по сути то-же самое, что и предложенная мной идея. И почему-то она активно развивается, хотя по сути та-же самая проблема. Достать для оплаты телефон или достать карточку из кошелька. Достать для открытия двери телефон или карточку.
                Но мне персонально эта идея даже больше нравится, если дверь открывать с часов.
                Или автоматически открывающаяся при приближении авторизованного телефона.
                Но часов под Android у меня под рукой не было. :-( А то бы сделал.
                • 0
                  Да, вы правы насчет NFC / Apple Pay. И меня это тоже удивляет до изумления. Как и бесконечные «wow! теперь вы можете открыть дверь в дом / гараж (включить свет, смыть унитаз и т.д.) со своего смартфона!»

                  Вот с часов — другое дело, тут я всеми пятью конечностями «за». Кроме унитаза, разве что. ;)
                  • 0
                    Давеча наблюдал как на проходной в бизнес-центр с проходом через вертящуюся штуку с валидатором народ проходит. Кто носит карточку на шее и пригибается к валидатору, кто задним карманом в нее тычется. Кто сумку пытается обтереть об валидатор. И народ говорит проблемы нет. Посмотрите на такой валидатор 5 минут и все становится ясно. В случае же с телефоном ничего прижимать и доставать и обтирать не надо. Подошел, толкнул рамку, телефон считался через маячок, отвалидировался и вперед.
                    • 0
                      Если телефон не надо даже доставать, то какие могут быть вопросы? Вопросов нет.
          • +1
            Особо спешащие вешают карточку на шею / делают себе браслет с меткой.
            А вот найти иконку на «рабочем столе» среднестатистического iPhone — та еще задача.
            • 0
              На шею вешают обычно карточку внутри офиса. А в офисное здание и вход? Конечно теоретически я вижу в офисах людей с карточками на шнурках, но ни в одном моем офисе таких не было. А знаком я более чем с 1000 людей, пользующихся карточками. По-видимому это были какие-то другие карточки.
              • 0
                у нас одна карточка и на вход в БЦ и на внутренние двери. масса людей носят их на шее или на поясе.
                когда были разные карточки — их можно было носить вместе.
                • 0
                  У кого как. А у меня 4 карточки и мне это крайне неудобно. Хочу одну. Они все вместе в толщину больше сантиметра.
            • 0
              Не соглашусь с
              На всё про всё было около 30 секунд, далее маячок опять блокировался. Понять, это фича или бага, мне не удалось. Это нигде не описывалось


              У меня был маячок от этого производителя и это не баг, а фича. Действительно нужно вытащить батарею и на 30 секунд устройство переходит в Dev mode. Потом можно включить этот режим, чтоб не возиться с батареей, а после полной настройки устройства, отключить. Это описывается в документации к маячку. Было много неясных моментов с маячком, но момент с батареей был вполне понятен.
              • 0
                Согласен, нашел эту информацию позже. По неизвестной причине она не попалась мне на глаза в момент работы с маячками, хотя я перелопатил изрядно информации в попытках достучаться до них. Ну будем считать «не свезло». Как-то эмпирически получил доступ и слава богу.
              • 0
                Время потрачено зря, т.к. никто не будет использовать. Было неудобно стало еще неудобнее :)

                1. Кладем карточку в чехол телефона
                2. Достаем телефон и проводим над сканером

                Зачем нам еще действия?
                • 0
                  так тут не надо ни класть ни проводить.
                  Нужно подойти и открыть дверь. Все.

                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                Самое читаемое