@Zivo Not that I am an expert, but can you post the relevant blocks.. If you do not use a 16-bit UUID it will not work.
My Slave device (HM-10) is set to 16-bit UUID (AAA0).
Running these blocks, AdvertiserServiceUuids return 128-bit (0000aaa0-0000-1000-8000-00805f9b34fb).
At this example I'm using as it's it, and getting null.
If I'm changing the AdvertisementData serviceUuid to use global variable with just 16-bit, AAA0, I'm getting "Invalid String"
I thought you were talking about creating advertisements on Inventor, not receiving them... (this post was about creating and advertising from your app)
if u can, post your block for the advert. Thanks
I'm trying with a lot of numbers with no success. I`m not seeing the adv anywhere and the return from is adv= false.
All help is welcome. 
1 Like
After I updated the plug in, it worked for a little bit and the this happened:
Was working fine, then the session ended and puff...
The issue is that with the device name and a 128-bit UUID there isn't much if any room left in the advertising packet for data. You'll have better success if you use a 16-bit UUID. The Android docs also state that the UUID should be a 16-bit UUID.
You probably have both the old and new BLE extensions in your project. They use different names for various functions, and this disabling effect happens due to the collision where the functions are present in one but not the other and a conflict occurs. You'll need to take apart your project file, remove the older extension, and then reload the project in App Inventor.
1 Like
Done , done aaand done. Thanks everyone!
1 Like
I tried just the same
On android 10 it didn't produce any result on the receiver. Nothing was received.
After many tries the phone started to send random Mac (but no advertising) like crazy also with Bluetooth turned off, and to stop it i had to restart the phone.
On android 8 i can see on the receiver the name of the device, the MAC (fixed, not random), the RSSI but the field of the advertising is empty.
Any idea?
As I mentioned a few posts above, according to the Android documentation only 16-bit UUIDs are allowed. Try specifying a 16-bit service identifier instead of a 128-bit identifier.
I tried with 0xFEF0 or FEF0 and it gives me an error of invalid format.
can u suggest one? 
Not a lot of documentation, but I appreciate the effort put into this tool.
- Can I set the device name? At the moment the client is reading "Galaxy Tab A" but different users (humans) will have different android devices with different names, so I'd like the app to set a defined name the client can read and recognize.
- From what I understand a peripheral can broadcast characteristics and any client can listen for a specific ServiceUUID and read the characteristics. How do I do?
We don't provide an API to do this right now. It appears that we can do this programmatically, but it's unclear to me from the Android documentation whether this is an app-level setting or if doing so actually changes it at the system level. The latter is less desirable.
Once you've connected to a peripheral using the BluetoothLE extension, the extension will read the services/characteristics from the device and make the information available through the DeviceCharacteristics property. More information on the properties, methods, and events of this extension are available here.
Hi @ewpatton ,
Does the requirement for 16bit Service UUIDs imply that one can only advertise a Bluetooth SIG Standard UUID (i.e. heart rate, battery level etc.) using the BluetoothLE extension?
And just to clarify, assuming the above is correct, does the text for the 'ServiceUUID' field in the 'StartAdvertising' block still need to be in 128bit format?
Regards,
Paul.
The implementation is a bit rudimentary, as it asserts both a service UUID and data for the the same. The extension sets up the following when it constructs the advertising data packet:
- Requests that the device name be included
- Adds the service UUID
- Adds a mapping of service UUID to the data
The data in an advertising packet is limited to 37 bytes (Bluetooth 4.0), of which 6 are reserved for the device's public or randomized address. If you use a 128-bit UUID, that's 16 bytes per UUID. The UUID gets repeated twice, which would require 32 bytes. The Android documentation specifically mentions that the UUID used for service data must be 16 bits.
As regarding the format, that code still requires a full 128-bit UUID even though you can only store the 16-bit identifiers. There's some code in the extension to do the conversion automatically, so this method should be updated to take advantage of that.
Lastly, you don't have to use one of the pre-registered 16-bit UUIDs. You could use one that isn't mapped for custom data. It might cause problems if the UUID you pick is one day given a proper mapping by the Bluetooth SIG.
Hi @ewpatton,
Many thanks for your reply and clarification. Using an 128-bit UUID (based on one of the Bluetooth Standard SIGs) worked for me.
Am I right in thinking though that currently the BluetoothLE extension is more designed to be used with the parent App Inventor app taking on the central role, rather than the peripheral role?
Regards,
Paul.
Yes. The advertising piece was written back in 2016 when the first iteration of the BLE extension was done. Most of the functionality has been improved over the years as use cases demanded, but we haven't had much of a case to improve the advertising side of things. Generally, it seems to me like the Android APIs aren't great either on this end as most phones are expected to play central to IOT peripherals.
Hi Everyone,
I've downloaded the latest BLE extension @ewpatton referenced in this post and I can see my BLE device advertising the correct service but no idea what blocks are needed to allow a connection? At the moment it just hangs
If anyone has managed to get further than me please let me know!
Martin