Beacon Detection Interface Asset

    Description

    The Beacon Detection interface asset enables your IntuiFace experience to detect beacons around your device and trigger any action based on their distance from that device. It is core to the Proximity and App Notification scenarios described in the Beacons overview article.

    NOTE:

    • This interface asset is available for use on Windows, iPad and Android devices.
    • To use this interface asset on an iPad, you need to predefine the list of beacons that should sought. To do this, use the iBeacon™ UUID list property (described below).

    Properties, Triggers & Actions

    Properties

    • iBeacon UUID list (iPad only): List of UUIDs separated by "," ";" or "|". For iPad only, IntuiFace must know which UUIDs to look for. iOS sets a limit of 20 UUIDs that can be monitored by a device.
    • Detect beacons: (true/false) Toggle whether or not IntuiFace should look for beacons.
    • Lost timeout (ms): Length of time after which a lost signal should mean the associated beacon is no longer detected.

    All of the properties listed below are read-only properties and thus only accessible via binding.

    • Beacons: the list of detected beacons. Each item in this list has the following properties
      • Beacon type: can be iBeacon, Eddystone-UID or Eddystone-URL
      • Distance: the estimated distance between the Bluetooth receiver and the beacon, measured in meters.
      • Detected power (RSSI): the detected signal power of the beacon. The difference between this number and the transmission power (see below) is used to estimate distance between the beacon and the receiver.
      • iBeacon:
        • UUID: a unique number used to differentiate one large group of beacons from another. For example, a retailer will have its own unique UUID assigned to all beacons across all stores.
        • Major - decimal: a unique number - in decimal - used to differentiate a subset of the UUID group. For example, each store for a retailer would have its own Major number.
        • Minor - decimal: a unique number - in decimal - used to differentiate a unique device with a Major group. For example, each beacon in a store would have its own Minor number.
        • Major - hexadecimal: a unique number - in hexadecimal - used to differentiate a subset of the UUID group. For example, each store for a retailer would have its own Major number.
        • Minor - hexadecimal: a unique number - in hexadecimal - used to differentiate a unique device with a Major group. For example, each beacon in a store would have its own Minor number.
        • Transmission power (txPower): the calibrated strength of the beacon signal measured one meter away.
      • Eddystone-UID
        • Namespace ID: a unique string used to differentiate one large group of beacons from another. For example, a retailer will have its own unique Namespace ID assigned to all beacons across all stores.
        • Instance ID: a unique string used to differentiate individual beacons.
        • Transmission power (txPower): the calibrated strength of the beacon signal measured one meter away.
      • Eddystone-URL
        • URL: the URL being broadcast
        • Transmission power (txPower): the calibrated strength of the beacon signal measured one meter away.

    Triggers

    For each supported protocol (iBeacon / Eddystone-UID / Eddystone-URL), this interface asset has three triggers:

    • Is changed: Raised when a beacon advertisement is changed.
    • Is detected: Raised when a new beacon advertisement is detected.
    • Is lost: Raised when an already-detected beacon advertisement is lost.

    All these triggers have parameters corresponding to the beacon properties. You can use these trigger parameters in a condition or as an argument of an action accessible via binding.


    BeaconTrigger.gif

    (click to enlarge)

    Actions

    In addition to the action enabling you to set the three major properties, you can also:

    • Start detection: Start looking for beacons
    • Stop detection: Stop looking for beacons

    Usage samples

    Proximity scenario

    The proximity scenario described in the Beacons overview article is implemented using the Beacon Detection interface asset. The following steps implement this scenario.

    1. Identify which beacon corresponds to each product.
      1. This can be done in advance and "hard written" in your experience
        or
      2. You can add a "configuration" scene, as done in the Beacon Demo sample experience, that will let the first user / installer do the setup without using Composer. You could also think about using an Excel spreadsheet to store these values.
    2. Specify the distance to use for your beacons. In our demo we decided:
      1. When the beacon is less than 1 meter away from the interactive device, show the associated product information
      2. When the beacon is more than 2 meters away from the interactive device, hide the information
      3. Using two widely different values for the minimum and maximum distance thresholds will avoid the product information from blinking.
    3. Add a method to test your "show / hide" actions without having to use beacons. We recommend you use Toggle Buttons with their Is checked / unchecked triggers.
    4. Use conditional triggers to check / uncheck your toggle buttons when the beacons are at the correct distance.

    Check out the Beacon Demo experience in our Marketplace to see this scenario in action in Composer.

    App notification

    The app notification scenario described in the Beacons overview article is also implemented using the Beacon Detection interface asset.

    The steps are the same as with the Proximity scenario above, except that the IntuiFace-based experience is running on a tablet and it is the tablet that is moving closer to and farther from a static beacon.