Eddystone implementation should provide a way to advertise more than three frames

[andresag01]

The current Eddystone implementation advertises the three frames TLM, URL and UID in the Eddystone specification. However, sometimes is desirable to broadcast additional advertising frames. For instance, if the user wishes to advertise connectable services and Eddystone at the same time. @janjongboom has a more specific use case.

Unfortunately, this is not easy to achieve in the current implementation. It would be desirable to add something like an additional callback where the user can update the advertisement payload at regular intervals.

@pan-

[ciarmcom]

ARM Internal Ref: IOTSFW-1762

[janjongboom]

@andresag01 So I was talking about this yesterday, and I think we should split this out of the eddystone module. We should end up with two modules:

1. BLE Advertisement Service
   • This contains 80% of the code that's currently in EddystoneService. Has a queue of events, and is responsible for swapping frames, etc.
   • Has some APIs that allow you to schedule / unschedule events, similar to minar API.
2. Eddystone Service
   • Consumes advertisement service
   • Allows you to register a certain advertisement frame and publish it every X time
3. Whatever other client (e.g. AccelerometerService)
   • Similar to 2. but then from userland code

The only thing missing here would be a central registry of Service UUIDs. I'd like to have a way of adding new yotta modules that implement bluetooth services, and can register themselves. Then whenever a normal frame is broadcasted they can tag along.

[jacobrosenthal]

Im sure this has been though of, but Config service should be a separate frame as well, instead of on bootup. Likewise a DFU service could be triggered through some button press or something.

[janjongboom]

Note that Eddystone now lives at https://github.com/roywant/EddystoneBeacon