2

I'm building a BLE automation IO card, so I'm trying to use BLE-Automation I/O https://www.bluetooth.com/wp-content/uploads/Sitecore-Media-Library/Gatt/Xml/Services/org.bluetooth.service.automation_io.xml

And it says that it supports 1 or more Analog (0x2a58) or Digital Attributes (0x2a56)... so I created a whole list of analog and digital attributes:

Digital - "Output energized" [RO]
Analog - "Current Temp" [RO]
Digital - "Self-test" [RW]
Digital - "Self-test results" [RO]
Analog - "Temp setpoint" [RW]

-- but, since they are the BLE SIG attributes, they're all coming up with the same UUID and it's confusing the client software.

Should I make them "custom" with my own 128 bit UUID's or is there an "index" or somesuch field that I should use to serialize them properly?

I'm using the BlueNRG1 chip, and the code I'm currently using is

suuid.Service_UUID_16 = 0x1815; //Automation
ret = aci_gatt_add_service(UUID_TYPE_16,  &suuid, PRIMARY_SERVICE, 35, &AutomationHandle); 
if (ret != BLE_STATUS_SUCCESS) {PRINTF("j"); goto fail;}    

cuuid.Char_UUID_16=0x2A56;  //[0]Digital: Bar Detected
ret =  aci_gatt_add_char(AutomationHandle, UUID_TYPE_16, &cuuid, 1, CHAR_PROP_READ, ATTR_PERMISSION_NONE, GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP, 16, CHAR_VALUE_LEN_CONSTANT, &OutCharHandle);
if (ret != BLE_STATUS_SUCCESS) {PRINTF("k"); goto fail;}

cuuid.Char_UUID_16= 0x2A58; //[1]Analog: Current Temp
ret =  aci_gatt_add_char(AutomationHandle, UUID_TYPE_16, &cuuid, 2, CHAR_PROP_READ, ATTR_PERMISSION_NONE, GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP, 16, CHAR_VALUE_LEN_CONSTANT, &CurDetectCharHandle);
if (ret != BLE_STATUS_SUCCESS) {PRINTF("l"); goto fail;}
ApplyFormat_Temp16(AutomationHandle,CurDetectCharHandle);

cuuid.Char_UUID_16= 0x2A58; //[2]Analog: BarCount
ret =  aci_gatt_add_char(AutomationHandle, UUID_TYPE_16, &cuuid, 2, CHAR_PROP_READ | CHAR_PROP_WRITE | GATT_NOTIFY_ATTRIBUTE_WRITE , ATTR_PERMISSION_NONE, GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP | GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP, 16, CHAR_VALUE_LEN_CONSTANT, &LastbarcountCharHandle);
if (ret != BLE_STATUS_SUCCESS) {PRINTF("r"); goto fail;}

cuuid.Char_UUID_16= 0x2A58; //[3]Analog: Last Bar Temp
ret =  aci_gatt_add_char(AutomationHandle, UUID_TYPE_16, &cuuid, 2, CHAR_PROP_READ, ATTR_PERMISSION_NONE, GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP, 16, CHAR_VALUE_LEN_CONSTANT, &LastbartempCharHandle);

cuuid.Char_UUID_16= 0x2A56; //[5]Digital: Self Test
ret =  aci_gatt_add_char(AutomationHandle, UUID_TYPE_16, &cuuid, 1, CHAR_PROP_READ | CHAR_PROP_WRITE | GATT_NOTIFY_ATTRIBUTE_WRITE , ATTR_PERMISSION_NONE, GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP | GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP,
                       16, CHAR_VALUE_LEN_CONSTANT, &SelftestCharHandle);
if (ret != BLE_STATUS_SUCCESS) {PRINTF("o"); goto fail;}

cuuid.Char_UUID_16= 0x2A56; //[6]Digital: Self Test Passed
ret =  aci_gatt_add_char(AutomationHandle, UUID_TYPE_16, &cuuid, 1, CHAR_PROP_READ | CHAR_PROP_WRITE | GATT_NOTIFY_ATTRIBUTE_WRITE , ATTR_PERMISSION_NONE, GATT_NOTIFY_WRITE_REQ_AND_WAIT_FOR_APPL_RESP | GATT_NOTIFY_READ_REQ_AND_WAIT_FOR_APPL_RESP, 16, CHAR_VALUE_LEN_CONSTANT, &STpassedCharHandle);
if (ret != BLE_STATUS_SUCCESS) {PRINTF("p"); goto fail;}

...

I do see them in the app, but they all have the same UUID so the app is not seeing the differences in the access permissions.

Thor Johnson
  • 31
  • 5
  • 1
    Could you elaborate on the "app" ? – Nipo Aug 20 '19 at 21:06
  • I've used PunchOut's LightBlue... since all the UUID's are the same, it isn't keeping track of each of the permissions of each of the characteristics. But if the UUIDs *are* the same... I'm not sure how notification is supposed to work since the client gets "UUID - new value" as a broadcast message... – Thor Johnson Aug 21 '19 at 18:41
  • ATT protocol notifications are sent in a ATT PDU that uses characteristic value handle as key, not characteristic type UUID. If there is ambiguity on display, it seems more like a bug in LightBlue, even if I dont remember this kind of issue with it. Are you certain you use relevant characteristic handles when sending notifications ? – Nipo Aug 22 '19 at 12:32
  • I haven't bothered with that yet... when it comes up in LightBlue, it looks like the first "instance" of a "uuid" sets the permissions, so in the above, "nothing is writeable" because even though the "SelfTest" char is writable, LightBlue seems to be picking the "writeable-ness" from "Bar Detected". If notifications use the handle, then it could be LightBlue's bug... Are you allowed to have duplicate UUIDs inside of a service (I know you can duplicate them as part of "subservices" and "combinations")? – Thor Johnson Aug 22 '19 at 15:41
  • Yes, having multiple characeristics with same type UUID is permitted, it is even mandatory for basic services like HID over GATT. That's why I'm suspecting you are not really searching for bug in the right direction. – Nipo Aug 22 '19 at 18:09

0 Answers0