Yes, that looks spot on. Espruino will advertise that in the Scan Response packet, but that should be totally fine for most things.
So I feel like I'm very close, but not quite there. I've been successful in switching between UART being set true and false, so I can test my custom advertisement, and then switch back to the default Nordic UART service to reprogram wirelessly, without having to reset the Puck.
I don't know if my service UUID is being "advertised" correctly though. I've been using the iOS versions of nRF Connect (by Nordic Semiconductor) and BlueSee BLE Debugger (by Synapse), and I see both the custom Name and the custom Service UUID advertised from the Puck, and appearing exactly like the thing I'm trying to mimic (the phone advertisement). Meaning from both of those apps, the name and UUID appear to be advertised identically between the Puck and what I'm trying to mimic, using the code snippet below:
uart : false,
advertise: [ 'ABCDABCD-ABCD-ABCD-ABCD-ABCDABCDABCD' ]
However, on the custom hardware I'm trying to communicate to, the Puck isn't being picked up at all. Let's say the custom name I'm advertising is "Puck.js" and the service UUID is "ABCDABCD-ABCD-ABCD-ABCD-ABCDABCDABCD"
Looking into the RAW BLE packet from NRF Connect, the Puck looks like it's advertising this:
Which looks like 2 advertisements in 1 BLE packet.
Type: 0x01 (Flag)
Type: 0x09 (Complete Local Name)
Value: 0x5075636b2e6a73 ("Puck.js" in hex, using ASCII table)
However what I'm wanting to see, is 3 advertisements in the packet, the missing one being the service UUID. Something like
Length: 0x11 (17 in hex, 1 for the type, 16 for the UUID itself)
Type: 0x07 (Complete List of 128-bit Service Class UUIDs)
Value: 0xabcdabcdabcdabcdabcdabcdabcdabcd (the service UUID)
So the overall RAW BLE packet looking something like this:
What am I potentially doing wrong to where the service UUID isn't being brodcast in the RAW BLE packet?