Multiple services/characteristics with the same UUID

BLE seems to support multiple of the same UUID for services and characteristics, for example you could use the automation IO service with 4 digital characteristics. With Espruino, specifying the services as an object seems to prevent that as the keys won't be unique, ie:

NRF.setServices({
  0x1815: { // automation
    0x2A56: { // digital
      readable: true,
      value : 1,
    },
    0x2A56 { // digital --> gets ignored as it's a duplicate key
      readable: true,
      value: 0
    }
  }
});

Is there any way around this?

As I understood it, you weren't really meant to do:

1815
  2A56
  2A56

But instead might have different services that contained the same characteristic:

1815
  2A56
1816
  2A56

However I could well be wrong - is your example something that people are actually doing?

As you noted, in Espruino it's not easy to do. One solution is to alternate between using Strings and Integers:

NRF.setServices({
  0x1815: { // automation
    0x2A56: { // digital
      readable: true,
      value : 1,
    },
    "0x2A56" { // digital --> gets ignored as it's a duplicate key
      readable: true,
      value: 0
    },
   // could use `"0x2a56"` and `2A56` as well in this case...
  }
});

However it is a bit of a hack! It'll also be virtually impossible to then change the value with NRF.updateServices at a later date as well.

It's in the spec and I've seen it done, it doesn't seem to be a common thing though. Most devices only have a single temperature reading, magnetometer or whatever.

I was looking at how to have a bunch of generic I/O using the standard characteristics. No big deal for me to use 128 bit UUIDs or do it some other way, I was just trying not to reinvent the wheel.

Well, I'm afraid it's not in there yet. It'd be a good thing to fix though.

To be honest the whole services/advertising API could do with a bit of love. It doesn't make that much sense as-is.

All good, thanks for looking. 👍