Is there a way to Advertise Services and a URL?

[hardillb]

I'm trying to build a Eddystone beacon that hosts it's own Web Bluetooth based control interface.

The Web Bluetooth API lets me filter BLE devices either by name prefix or advertised services. At the moment I'm having to use the name prefix as the services I've attached are not getting advertised along with the URL. I'd like to be able to let users set arbitrary names for beacons so I would like to move away from using the name prefix.

My code currently looks like this

  var toggle = new ToggleCharacteristic(toggleCallback);
  var dim = new RangeCharacteristic(dimCallback);

  var characteristics = [toggle, dim];

  bleno.once('advertisingStart', function(err) {
    if (err) {
      throw err;
    }

    bleno.setServices([
      new BlenoPrimarySerivce({
        uuid: 'ba42561bb1d2440a8d040cefb43faece',
        characteristics: characteristics
      })
    ]);
  });

  eddystone.advertiseUrl(config.shortURL, {name: config.name});

[sandeepmistry]

@hardillb this functionality does not exist now, however it could be added.

One note, adding support to advertise a UUID would reduce the maximum encoded URL size by 4 bytes for a 16 bit UUID and 18 bytes for a 128-bit UUID, as everything needs to go in the advertisement data.

The name currently goes in the scan data, so does not affect the maximum encoded URL size.

[hardillb]

@sandeepmistry Thanks for the info. I was sort of hoping it might be possible to interleave frames with UUIDs and URL data. But if they both have to share the frame then the URL is nealy too short to be useful as it is.

I'll just have to stick to using a name prefix to find things.

Thanks

[sandeepmistry]

@hardillb interleaving could work, I did not think of that as a possible solution.

@beaufortfrancois is interleaving service uuids advertisement packets with Eddystone packets the preferred approach for this use case?

[beaufortfrancois]

cc @janjongboom who might have some opinion there.

[beaufortfrancois]

@scottjenson @cco3 do you know if interleaving service uuids advertisement packets with Eddystone packets the preferred approach for this?

[scottjenson]

Many beacons use interleaving to handle this situation. Assuming you are making your own beacons of course, you just send any packet you wish that can be easily scanned. There is no need to force this to go into the UID or URL frame type.

[don]

You could try sending advertising data or Eddystone data in the scan response to avoid interleaving.

[scottjenson]

You absolutely could do this. However, please be advised that it's possible to find beacons using a 'passive scan' which ignores the SCAN_RESP packet. This is part of the BLE spec but few OS implementations support it now. Someday, when Android does, we'll likely use it. It's a bit conservative, but it'll be done for security purposes as it prevents nefarious beacons from knowing that you've entered their range.

Now, there is no specific timeline on when Android will support passive scans so there isn't an immediate concern. Just letting you know we see this as something on our roadmap to support when it's available.

Scott

[janjongboom]

Here's how I do it currently in mbed OS http://blog.mbed.com/post/137093070607/physical-web-and-web-bluetooth-on-mbed-os. Just broadcasting two packets (one normal, one eddystone).

[hardillb]

So looks like interleaving UUID and URL frames works and is most likely to keep working with the passive scan option when it gets implemented. Can this all be done in the eddystone node or will it require changes to the underlying bleno as well?

[sandeepmistry]

@beaufortfrancois @scottjenson @janjongboom thank you for your input! Looks like interleaving is the way to move forward.

Can this all be done in the eddystone node or will it require changes to the underlying bleno as well?

@hardillb it's all doable without changes to bleno, this repo already has support to interleave URL and TLM packets.

There's one hiccup however, on OS X the beacon will continue to be non-connectable. No issues for Linux though.

[janjongboom]

There are some problems with Chromium on Android as well. https://bugs.chromium.org/p/chromium/issues/detail?id=599056

[beaufortfrancois]

@jyasskin @g-ortuno WDYT?

[jyasskin]

The bug covers it. We need to fix this, but there's also a bunch of other stuff we need to fix.