I see you are using Neil Kolban code.
There are 4 hits on this board for Kolban.
They should be worth reading.
Hello rowifi
Ensure that your phone has Location switched on - this is a Google Security requirement and Bluetooth comms will not work without it.
I may be wrong but I think 'ConnectToDeviceWithServiceAndName' parameter 'name' would be the whole string representing the Device in the Device List - the idea being that the Device is selected via the Device List as a one-off task and there after you can store that List Item (name) in TinyDB and recall it for subsequent App sessions.
How did you obtain the Service UUID? Make sure you have the correct UUID and it is perfect (no typos, match the character case exactly).
Concerning the 'ConnectToDeviceType' Block, I have no idea what 'Device Type' actually means in the context of an AI component Block - the official MIT Help:
http://iot.appinventor.mit.edu/#/bluetoothle/bluetoothleintro
does not mention 'component':
ConnectToDeviceType - Connect to a given device type with a given name. Extensions that use BluetoothLE can leverage this API to simplify establishing a connection.
However the pop-up help of the Block itself does mention 'component', but really does not make any sense (not in English anyway!). I shall ask Evan Patton what he really means.
Edit:
The questions I have put to Evan:
The device parameter
Should this be a text block containing the device's Service UUID? The term 'Device Type' is the confusing bit because it suggests that there may be a formal list of types to be referred to - but that is not the case?
The name parameter
Is this a name from the Device List (which could be/include the MAC address) and should it be the entire string of the List Item or only the name extracted from that string?
Let me just clarify.
The BLE module is an ESP32 and the code is posted above.
It provides serial Uart functionality and appears to work correctly because the nordic BLE app can see it and display it's properties and the data it sends out.
The appinventor code also works - to a degree in that it will send a command string when buttons are pressed and it also displays received data ( when that section of the app is enabled.)
The UUIDS and Device name are known and coded into the ESP32 and are used to get the appinventor code to connect successfully when done manually - using a selection from a list.
The permissions must therefore be ok for it to work.
To offer a demo app to a potential customer - I would like the app to do things automatically.
I already start scanning when the app is opened, but now I want it to connect automatically when it finds the known BLE target device. i.e to provide a seamless app that allows the user to turn something on and off without having to go through the manual scan and select process - ( ok for development but not great to show a customer ).
So it's currently the automatic connection to my known device that is not working. Neither using 'Connect to device type ' nor 'Connect using service UUID and name'
Both blocks cause the strange behaviour when added to the 'Device found' block.
Normally the Device found block executes a limited number of times - whenever a new device is found, and makes a ping sound ( for convenience and debug). So normally ( without the connection block included ) it pings a few times and stops. The manual select and connect subsequently works fine.
If either connect block is attached within the device found block, to facilitate an automatic connect, the pinging repeats indefinitely, which to me makes no logical sense regardless of whether the parameters are correct or not.
Correctly assumed I don't know much about the blocks at this point - I've copied much from examples, and what you're seeing is me using the lists and labels to see what is being placed in the variables and elements - as a debug and learning phase.
I'm only a day into playing - but am pleased to see how far I've got, but some of the battles at the moment are knowing if it's me or the tools that are buggy. 
Further experimenting..
I created a separate block that connects to a specific device when a button is pressed.
If the device is in the scanned list then it should connect, if not .. it won't.
What happens is that the app pings during scanning when devices are found and eventually stops pinging - even though the scanning is still active.
If, after that point the button is pressed to attempt a specific connection - the ping occurs again, and everytime the connect button is pressed.
I suspect that in the process of trying to connect, the block damages or deletes the data in the scanned list such that it is re-filled whenever the scan finds the 'new' devices again.
As to why it doesn't connect - that is still a mystery. But I'm convinced something untoward is happening to the device list.
You need to have a little 'If' test there, and use a stop scanning Block 'If' the required device is found (and thus is in the Device List).
This is how we did it before the new direct connect Blocks were added (Silent Device List pick using an 'If' test).
Your App might need a manual connection as a backup (which can be hidden unless required) and an ability to repeat the connection request (but never repeat accidently) because BT radio signals can suffer from interference, especially if the distance between the ESP32 and the phone nears the BT limit, but for other alien reasons too, such as temperature and obstacles (e.g. walls).
In your 'Device Found' Block, the List Picker is populated with the Device List, something we have all coded in a similar way - but I remember a recent(ish) remark by Evan where he suggested there was a flaw in this method as the Device List could be incomplete. Therefore, better to make a List (internal AI2 Block List) within a Clock Timer Block, then feed that List to the ListPicker (for manual Select) or pick from it (for auto Select), or indeed not have a List, just test for the Known Device.
This is causing me grief.
I can't iterate through the BLE 'devicelist' because it isn't a 'list' - The blocks don't connect.
I tried to make a new 'List' and add items from the BLE 'devicelist' whenever a device was found but failed.
I'd sooner not use a clock - - and still would need to do as above ( which I haven't worked out how).
Is there an example anywhere of achieving this since it would appear to be a reasonable thing to do instead of having the user keep pressing buttons.
And I'm still in the dark as to what's happening to the device list when I try to connect to a specific device.
Help appreciated BTW.
- stop the scan sooner.
That depends on what devices might already exist in your customer's premises and all other circumstances that can affect the BT radio signal between your device and your App, but in ideal conditions you do not need a Device List at all because the "unknowns" are already known by you.
Let's wait for Evan's response concerning the direct connection Blocks. He is an extremely busy chap so patience is required.
First news snippet:
The 'ConnectToDeviceType' Block should not be used.
OK, I do not have confirmation as to what the Device Name should comprise in terms of what gets fed into the 'ConnectToDeviceWithServiceAndName' name parameter - should it be the whole device list item collected or should we extract the name from that list item.
If the mac address is to be used in other BLE Blocks, we are not required to extract that from the device list item, the Block function does that for us. So, I'm expecting the same kind of thing for device name, but awaiting Evan to confirm.
Concerning the UUID and Name - are those going to be identical for every customer or unique? That obviously affects how the App is coded. If values are identical for every customer, they can be hard-coded in the App (they can be encrypted if required but relying on Android security is reasonable in most cases). If however the values will be unique to each customer, the code will have to pick the values up first via the ESP32 BT advertising.
I put this code together but at this moment I have no devices to test it. I think it explains the basic idea better than a description. As-is, it always scans to check that the device is available, which is probably best.
BLE_ConnectToKnownDevice.aia (192.8 KB)
The UUID and name will be the same for each customer, ( It's flashed into the ESP device ), however I've yet to work out how devices get 'bonded' to the phone or how to prevent anyone with the app simply connecting and controlling some other persons devices.
I'm sure it's all explained somewhere.
I'll check out your code.
Couple of things noticed in the program. I did extend the timer time to 8 seconds and disabled the 'not found' message so I could see the displayed list. ( I could have appended it of course )
- If the target device isn't active, then it does end with the message target device not found.
- If it is active, then we don't get the message, ( it is therefore 'found' by the code ) but it doesn't actually connect.
- The displayed list quite often has duplicates.
I added the 'connecting message' - which does run.
I'll continue playing.
OK, So I got it connected by extracting the Mac address ( which will be the unknown) from the device that matched.
It then connected )
Then replaced the connect block to use the Address.
BLE_ConnectToKnownDevice (1).aia (193.4 KB)
Hi rowifi
- Good to see progress!
- We have had the 'ConnectWithAddress' Block for a long time, but it very much depends on how dependant the device is on Service UUIDs. It also has to be found every time if the MAC Address is dynamic.
- The reason for duplicates - nothing in my code to remove them! (not important)
- Making the unit unique for each customer - much depends on the number of customers. It's relatively easy to make Scripts with a unique variable, but not easy to make an App that 'knows' the same value unless it is in a hard-coded List, because the App of course is compiled.
I'm going to keep working on this for a while.
The BLE devices will have a fixed MAC address as they are ESP32 modules, so I assume they are reasonably unique and permanent. I haven't examined where the MAC is defined, but hey -- it's there for now.
I'm going be working on the security aspect which means working with local storage blocks.
I'll post an update when worthwhile. But I did note ( and in another thread ) that the RSSI value does not update itself - so that looks like a bug.
Yes, it probably is, but there are many issues with Bluetooth itself, mostly brought about by manufacturers not implementing the standards correctly. If you buy the cheaper ESP32 modules from the open markets, overall they are good performers and can save a lot of money, but the devil is in the details......
Since this topic has been very useful to me in my first project with MIT App. Even though it's been a long time since it opened, I want to contribute with the solution that I have found.
The typical mechanism proposed for the extension MIT BLE, although it works perfectly, I find it very inelegant if it is to connect a known device and it is not a simple experiment. Also, the number of keystrokes and the entire connection process, it is very cumbersome and only understandable to someone who knows how BLEs work.
My intention is that the App, just start, connect automatically and without user intervention to the known BLE device whose NAME has been previously configured. Of course, since the connection is not made instantly, The App should be giving simple messages that allow to know in which stage the connection is: start SCAN, stop SCAN, connect ... And, of course, give the corresponding OK or error messages.
Attached is a small test that I have used, isolating only the connection process.
I have carried out tests with HC-05 modules from different manufacturers until it works in all of them.
In the building where I live, the number of neighbors is huge and the number of BLE devices that appear when doing the SCAN, it is surprisingly high. It even depends a lot from the room where you run the App. This also created certain problems for me, but this version has worked correctly.
I have used the BLE extension 20200828 and the 20201223. With both it works.
PrbaConexBLE.aia (409.7 KB)
If anyone finds it useful, I would be very happy to have been able to contribute to the MIT App community.
3 Likes
Hello sangarfe
Thank you for taking the time to contribute your efforts. It probably won't surprise you to learn that a level of automation has been done before 
HC-05 Modules however are not specifically BLE (they are Bluetooth version v2 + EDR).
See my website for a tabulation of Modules:
https://www.professorcad.co.uk/appinventortips#TipsBluetooth
Two posts by joao_ramires_diafuco deleted as they are part of a separate Topic.