Hey, this sounds like a really cool project so just wanted to chime in. As a preface, I'm not sure if I completely understand what you're going for with this app so correct me if I'm wrong (I'm also a bit rusty).
Here are my suggestions: Any MyNewt device that has "nimble" in its name will be seen as a valid > MyNewt device -- we can change this, but I based this off of the bleprph > tutorial code. If the new service will only ever run on mynewt then simply the existence of said service should be enough to 'validate' the device as being mynewt. > - Each sensor should publish 2 UUIDs as follows: > > > - UUID 0x2Axx is considered a 'configuration UUID', should be > readable, and should return a String containing the name of the sensor as > you would like it to be displayed in the app > > > - UUID 0x4Axx is considered a 'data UUID' and should be subscribable > and subsequently updated with the sensor readings associated with its > 0x2Axx config UUID > > In general, services should have fixed characteristics with fixed UUIDs. We should not be dynamically creating characteristics inside a service. This is because (at least in the case of Android) the mobile device caches the service and characteristic information, including the number of characteristics and all UUIDs so that it does not need to re-discover the service (noticeably slower than connecting to the cached service). For example, if my Android device first discovers the service with 1 sensor (i.e two characteristics), I will only ever see the service having two characteristics with the initial UUIDs even If I have added four more and changed the UUIDs for all characteristics. Therefore, I suggest making a service with a single characteristic, either READ or NOTIFY, with a unique 128-bit UUID, that either stores (in the case of READ) or publishes (in the case of NOTIFY) a list of "sensor" structures which hold the sensor name and value. From there the mobile device can display the list accordingly. Again take everything I just said with a grain of salt, I haven't used MyNewt in a number of months. Finally, great idea for a project. This would be very useful for new developers as a tool and a reference point for other applications. Brian Giori On Thu, Dec 1, 2016 at 7:03 AM, David G. Simmons <santa...@mac.com> wrote: > Doh!! > > Ok, so since actually complying with BLE standards is sort of important > :-) the UUID to use is E761D2AF-1C15-4FA7-AF80-B5729020B340 which is > unique, and is 128-bits. > > That being said, it is also noted that defined characteristics are all > (save one) in the 0x2Axx range. So my choice there was bad too. > org.bluetooth.characteristic.fitness_machine_control_point defined as > 0xEE1D is the outlier there. > > 128-bit UUIDs are a pain in the *** if you ask me. They are easy to > generate via the website Chris so generously provided. They are annoying to > translate into 16-byte arrays, but generating 128-bit UUIDs with a common > prefix/suffix is, as best I can tell, not possible. This all makes the iOS > app more complicated if not impossible without requiring users to generate > their own UUIDs, then go edit the iOS source files, build and deploy the > app to a device. > > I see 2 possible solutions here: > > 1) we flaunt standards, a bit, and use 16-bit characteristic IDs that are > NOT within the pre-defined characteristic ranges, say 0xDExx and 0xADxx as > our Config and data prefixes -- keep in mind that this is *only* for a demo > app and would not be used for any production application. > 2) We generate 2 128-bit UUIDs, say 559557e5-2ae2-4d4b-bda2-d432e8577be3 > and d5e9608f-6e41-490f-88e2-4281c8ebe2c6, then clip off the start, > 559557e5- and d5e9608f- for config and data prefixes, and folks can > generate their own 128-bit UUIDs, then replace the prefixes. > > 1 seems a lot more straight-forward and easier to explain to people who > are trying to work through the tutorials. 2 would have a lower chance of a > UUID collision, though even with 1, the collision chances are nearly > non-existent. > > Happy to take suggestions here. > > dg > > > On Nov 30, 2016, at 1:03 PM, Christopher Collins <ccoll...@apache.org> > wrote: > > > > That sounds great! My only comment is that the app probably shouldn't > > use those 16-bit UUIDs. There is a registry of standardized bluetooth > > service UUIDs (https://www.bluetooth.com/specifications/gatt/services < > https://www.bluetooth.com/specifications/gatt/services>), > > and 0x1811 is reserved for the Alert Notification Service. > > > > For non-standard services and characteristics, you will need to use > > 128-bit UUIDs. You can generate unique 128-bit UUIDs using a site like > > this one: https://www.uuidgenerator.net/ <https://www.uuidgenerator.net/ > >. > > -- > David G. Simmons > (919) 534-5099 > Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • > Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter < > http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs> > /** Message digitally signed for security and authenticity. > * If you cannot read the PGP.sig attachment, please go to > * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!! > * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/> > **/ > ♺ This email uses 100% recycled electrons. Don't blow it by printing! > > There are only 2 hard things in computer science: Cache invalidation, > naming things, and off-by-one errors. > > >
