Hi David, 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), 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/. Thanks, Chris On Wed, Nov 30, 2016 at 12:42:23PM -0500, David G. Simmons wrote: > I've been working on an iOS 'demo' app for Mynewt as a way to interact with > ble devices, and I'm interested in hearing feedback on what I've got so far, > etc. > > I've taken a fork of https://github.com/anasimtiaz/SwiftSensorTag > <https://github.com/anasimtiaz/SwiftSensorTag> which was originally written > for the TI CC2650 Sensor Tag and modified it for MyNewt. It is under the MIT > license, so I think it should be ok by Apache standards. > > This app will work with pretty much any MyNewt BLE device, and will display > any/all sensors/values that the device wants to make available. I'll have to > make some further modifications for some data types like Accelerometers that > publish tuples like (x,y,z) as it currently only handles single data updates > but the code is there to deal with tuples, I just have to adapt it to how the > new version handles incoming data. > > Here are the requirements for a MyNewt Device to send data to this app: > > 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. > Any and all sensor data should be published under the UUID 1811 -- again, > based on the bleprph code, but it can be changed if people think another UUID > would be better. > 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 > > For example, I have a BLE app for the nrf52dk device that has the following > definitions: > > /** GATT server. */ > #define GATT_SVR_SVC_SENSOR_UUID 0x1811 > > /** An ADC Sensor */ > #define GATT_SVR_CHR_SUP_ADC_SNS_TYPE 0x2A47 > #define GATT_SVR_CHR_NEW_ADC_VAL 0x4A47 > /** a SPI Sensor */ > #define GATT_SVR_CHR_SUP_SPI_SNS_TYPE 0x2A48 > #define GATT_SVR_CHR_NEW_SPI_VAL 0x4A48 > > static const char sns_type[] = "eTape Water Sensor"; > static const char sns_type2[] = "SPI Gyro Sensor"; > > The static const char values could be dynamically allocated, but this was > easier for this demo. > > case GATT_SVR_CHR_SUP_ADC_SNS_TYPE: > assert(ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR); > rc = os_mbuf_append(ctxt->om, &sns_type, sizeof sns_type); > return rc == 0 ? 0 : BLE_ATT_ERR_INSUFFICIENT_RES; > > case GATT_SVR_CHR_SUP_SPI_SNS_TYPE: > assert(ctxt->op == BLE_GATT_ACCESS_OP_READ_CHR); > rc = os_mbuf_append(ctxt->om, &sns_type2, sizeof sns_type2); > > So a read on those UUIDs returns the string ... > > The iOS App then looks like: > > > > And those sensor values are updated in real-time. This gives us, basically, a > 'generic' iOS app that can handle any MyNewt device with any arbitrary number > of sensors attached as long as the above conventions are followed. > > Comments? > dg > -- > 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. > >
