Universal Mobile Electronic Key

    I can’t say that I felt very excited when I was offered to participate in the project “Device Lab from Google” , but, of course, there was interest. Once I did a project with various interactions via Bluetooth, and I got extremely interesting implementations. However, it turned out that during the manipulations with Bluetooth, all phones whose owners unintentionally left them turned on within the Bluetooth operating range lost their charge three times faster than usual. Colleagues, of course, were not very happy. The project had to be closed. In this regard, I have long wanted to hold the last generation beacons in the "tenacious" hands. And the Device Lab project provided me with such an opportunity.


    An article by author Dmitry Senashenko ( @DmitrySen ), as part of the Google Device Lab contest .

    The market now has many beacons and their manufacturers. And most of them are designed to determine the geolocation inside buildings. There are interesting ideas from the category of embedding beacons in suitcases to search for them at the airport by their signal. But given the power, it looks like a toy. I wanted to come up with and implement something original and useful at the same time. So, a few formalities on the site and in the Habr’s office, and the iBKS beacon in my hands:


    Much has been written about the lighthouses. For example: “ Google's beacon platform. Part 1 "or" Google's beacon platform. Part 2 ". I will not repeat myself, however, I will say that it was supposed to use the beacon with Google's beacon platform and work with it via the API. Reality has dotted the “i,” which I will talk about a bit later.

    In my life I work with telephony and intelligent IVR with support for email, html, sms, etc. Therefore, there are ready-made stands, it is easy to get the necessary equipment, etc. And it was to this topic that I wanted to adapt the beacons.

    Idea


    So, the idea came to me to use beacons as an authorization key to the doors in the office. As everyone knows, every office has doors with electronic locks and a reader at the entrance. Each employee has a key in the form of a card, and to enter the door he needs to attach this card to the reader, after which the door will open. In the world, the number of such doors amounts to many billions, and the number of cards, probably trillions. Although actually using them is not very convenient. If you are in a hurry for an important meeting, then losing time to remove the card (or remove the item in which this card lies - wallet, folder with documents) is very tiring.

    However, each person now has a telephone in his pocket. And some even have hand-held electronics. It’s easier to meet a person who has forgotten a card than to forget his phone. Therefore, it is more convenient and economical to replace the card with a telephone, and the reader with a beacon. Of course, there are good ideas in this direction.

    For example, a door handle with a fingerprint reader, NFC in the phone, etc. But NFC technology never appeared in every smartphone, but there is Bluetooth in every smartphone. Therefore, technologically this idea is actually ready for implementation.

    In addition, this solution increases the degree of comfort of employees. Approaching the door, just click on the application icon, and after authorization, the door will open. Those. it can be opened even from the elevator or on the approach to the door. In addition, you can open the door from the watch or by speaking to a personal assistant in the headphones with a microphone. An important factor is authorization. Let's take a look at this in more detail. See figure 1.

    Schematic diagram of work


    The phone enters the beacon's visibility range, finds it using Beacon Discover, and through Nearby messages API receives its attachment from the Google Beacons Registry. Then, via Wifi or mobile Internet in an encrypted session, the phone sends this attachment and its IMEI or other unique code specified when installing the application to the authorization server. The authorization server identifies access rights and, if so, gives the command to the electronic lock management server to open the corresponding lock, based on data from the attachment, which uniquely characterizes the door. The electronic lock control server instructs the actuator to open the door.


    Figure 1. Scheme of the organization of interaction

    This is the solution that occurred to me, and now let's try to implement it.

    We embody the idea in iron


    I had an Avaya PBX with a G250 gateway at my disposal. This is an old gateway, long discontinued. But its new replacement - the G450 / G430 gateway - also has the components we need, namely the electronic door lock control drive. A dry relay is built into this gateway for the needs of small offices - the so-called Contact Closure Adjunct (see Figure 2).


    Figure 2. Avaya Gateway G430

    This slot allows you to control the dialing of any pre-configured telephone number. When dialing this number, the gateway closes the relay and gives a signal to open the electronic lock.

    Further, I had a work stand with IVR (Interactive Voice Response) manufactured by Avaya as well. This is a fully software service that has the ability to process not only voice requests, but also email, SMS and, in this solution, you will need html-requests. Also, this IVR can initiate not only email and SMS, but also voice calls. Those. in relation to this project, this IVR can receive a html request with the transfer of variables and, based on the results of processing these variables, initiate an outgoing voice call to a certain number. Request processing in IVR can be carried out both by built-in tools and using the Java programming language. In this regard, this IVR was used as the authorization server. An Avaya Aura Communication Manager PBX with a G250 gateway was used as the electronic lock control server. An electronic lock was also available.

    Thus, the application on the mobile phone needed to get the identifier of the beacon, contact the Google Beacons Registry and get its attachment, after which in the html request send this information and your IMEI to IVR, which, after checking it, will dial the PBX, thus giving a signal to short-circuit the Contact Closure dry relay on the G250 and thus open the door.

    Well, the last step in preparing for implementation was getting a mobile phone running the Android operating system. It was an HTC Desire with Android Lollipop 5.1.1. Well, of course, it was also necessary to install Android Studio on your laptop.

    Everything was ready, and I set about. As usual, reality has dotted the i.

    Underwater rocks


    First, the beacon must be registered in the Google Beacon Registry. The easiest way to do this is through the Google Beacon Tools mobile app, available on both the Google Play Market and the Apple App Store.

    I turned on the beacon, removing the plastic disconnect between the microcircuit and the battery, installed Google Beacon Tools and began to search for the beacon. He did not appear. Then I downloaded the manufacturer’s application iBKS Config Tool. This application is also available for both Android and iOS devices. And - lo and behold! A beacon appeared.


    Figure 3. iBKS Config Tool

    However, he persistently did not want to appear in Google Beacon Tools. Having studied the Internet, I read that it is necessary to enter the editing mode on the iBKS Config Tool and change the type of broadcast of the beacon. The application refused to enter the editing mode stubbornly, both on Android and iOS. It was possible to enter this mode only after the beacon was turned off and on again by removing the battery. There was about 30 seconds for everything about everything, then the beacon was again blocked. I failed to understand this feature or bug. This has not been described anywhere. See figure 4.


    Figure 4. iBKS Config Tool editing mode

    Having changed Advertising Mode from 1 to 7 (see Figure 5), I finally saw a beacon in Google Beacon Tools (see Figure 6). But he stubbornly refused to register.


    Figure 5. Select Advertising Mode


    Figure 6. Google Beacon Tools

    Google Beacon Tools for registration required that the beacon be in iBeacon or Eddystone UUID. Mode, but in this mode he stubbornly did not see it. In the Eddystone URL mode, he saw it, but refused to register. The behavior of this application on Android and IOS was the same, although on Android the application first selected the project and only then refused to register the beacon.

    What was the reason for this behavior of the beacon, it was not possible to find out during the project. It seems that the beacon itself was problematic. Of course, it was worth replacing it, but the project was limited in time, and there was no time for a new trip to the Habr’s office. From experiments with the iBKS Config Tool and Google Beacon Tools, it was clear that the beacon emits, and transmitting its unique identifier. Therefore, it was decided to identify the beacon for the demo stand not by the attachment received from the Google Beacons Registry, but by its identifier. In general, for a prototype solution, such a replacement is quite adequate.

    So, it remains only to find a Java library that would allow Android Studio to organize the detection of a beacon identifier. Of course, GitHub and the Radiusnetwork.com.eddystonedemo library came to the rescue. This library allows you to see the identifier broadcast by the beacon, which is also visible through the iBKS Config Tool. Description given here .

    An Activity was organized (see Figure 7), which had a large gray button. This button after finding the beacon changed the color, name and property of Clickable. That is, until a beacon is found, nothing happens when a button is pressed. As soon as the beacon is found, the button turns red and allows you to click on it. When a button is pressed, a URL is called leading to the IVR application with IMEI transmission, which checks it and, if successful, forms a call via SIP to the electronic lock control server. In case of loss of the beacon signal (increasing the distance to it or turning it off), the button changes color and the Clickable property back.


    Figure 7. Application screenshots

    Code and final implementation


    The whole project can be found on Github here. Let us dwell on the details. The following is the function that is called when a beacon is found:

    public void didRangeBeaconsInRegion(Collection 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);
     }
     });
     }
     }
    }
    

    The following is the function to call a URL on an 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());
    }
    

    The timer in this application is needed to extinguish the button when the phone becomes unavailable 5 seconds after the loss.

    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("");
     }
     });
     }
     }
     }
    }
    

    Application development for IVR is carried out in a specialized environment Avaya Aura Orchestration Designer and is based on the development environment Eclipse. Essentially, under each element is Java code. The application is built to simplify development in the style of Drag <&> Drop. Figure 8 shows a screenshot of the application development environment for IVR.


    Figure 8. Avaya Aura Orchestration Designer development environment

    This application has two main modules: Data1 and Outcalling. Screenshots of these modules are shown in Figures 9 and 10.


    Figure 9. Data1 module


    Figure 10. Outcalling module The Data1

    module actually authorizes the beacon identifier and IMEI: if both are correct, a transfer is made to the Outcalling module, which generates an outgoing call to a pre-configured number stored in the CalledNumber variable. This variable sets the number configured in the ATC for the operation of the dry ContactClosure relay connected to the electronic door lock.

    The full project can be found here .

    Well, in conclusion , a video was posted at this address in which a description of the project is given and a demonstration of an already completed project is conducted. Thanks for attention!

    Also popular now: