BLE Gateway Proposal

[bradjc]

I've been working on an implementation of the gateway we've been discussing at various gateway meetings and other places.

See the readme for a description of how it currently works. It's mostly focused on parsing advertisements at the moment.

I also sketched up a rough overview of how the system works currently:

I thought this might be a good place to have discussion as it both is archived and allows for comments on specific code.

Known Issues

• There isn't a way for device-specific parsers to label or identify the type of the data object they output. For example, the powerblade parser returns an object with the keys power, voltage, energy, etc. but nowhere can it identify the entire object as a "Power Meter Reading" object, which downstream listeners would want. I'm not sure where this best fits yet.

[prabaldutta]

This is a nice write up of one aspect of what we were discussing. Another
interesting direction this could go is one level of indirection: instead of
using the EddyStone URL as the base URL to parse.js, you could use the
<URL, X> as the key to grab a different parse.js file from some special
server (that perhaps your company owns). Here, X could equal NUL, or
perhaps X could be a GPS coordinate, or really any other key. The idea
here is that rather than getting locked into using whoever's driver is
sitting at parse.js, you can intercept the request and forward it to your
(of someone else's) driver database. If there's a cache hit in that
database, then great, you use that copy of the driver. If there's a miss,
then you go looking for the default driver.

• Prabal

On Wed, Jan 6, 2016 at 9:02 PM, Brad Campbell [email protected]
wrote:

I've been working on an implementation of the gateway we've been
discussing at various gateway meetings and other places.

See the readme
https://github.com/lab11/gateway/tree/master/software/ble-gateway for a
description of how it currently works. It's mostly focused on parsing
advertisements at the moment.

I also sketched up a rough overview of how the system works currently:

[image: img-160106205310-0001]
https://cloud.githubusercontent.com/assets/1467890/12160233/fcfaff00-b4b7-11e5-8cd2-4975c54027cc.jpg

I thought this might be a good place to have discussion as it both is
archived and allows for comments on specific code.

Known Issues

• There isn't a way for device-specific parsers to label or identify
  the type of the data object they output. For example, the powerblade parser
  returns an object with the keys power, voltage, energy, etc. but
  nowhere can it identify the entire object as a "Power Meter Reading"
  object, which downstream listeners would want. I'm not sure where this best
  fits yet.

—
Reply to this email directly or view it on GitHub
#1.