BluetoothLE extension 20190701 released

News/Announcements
1

Hello everyone,

We have officially published BluetoothLE extension version 20190701. As part of this release, we have also updated all of the example project files on iot.appinventor.mit.edu. You can get the latest extension from here.

Here is the set of changes since version 20181124:

  • Add new property NullTerminatedStrings to control whether sent strings should include a null character or not
  • Add new methods:
    • ConnectToDeviceType - Connect to a given device type with a given name. Extensions that use BluetoothLE can leverage this API to simplify establishing a connection.
    • ConnectToDeviceWithServiceAndName - Connect to a device advertising the given service UUID and the given device name.
    • ReadConnectedRssi - Read the Received Signal Strength Indicator (RSSI) of the connected device.
    • RequestMTU - Request a change in the size of the maximum transmission unit if the underlying hardware supports it.
    • ScanForDevice - Scan for a device of a specific type. Extensions that use BluetoothLE can leverage this API to simplify establishing a connection.
    • ScanForService - Scan for devices that advertise a specific service UUID.
  • Add new event MTUChanged to report a change in the maximum transmission unit
  • Allow ConnectWithAddress to connect without previously scanning
  • Fix accumulation issue in GetSupportedCharacteristics
  • Fix crash due to “addPos not implemented” error

Cheers,

Evan W. Patton, Ph.D.
Lead software engineer, MIT App Inventor
On behalf of the MIT App Inventor team

7 Likes
2

:star_struck: That’s going to make a lot of people very happy Evan

3

(added to FAQ)

4

I installed this new extension and I love the new features, but I’m running into an issue. I have several projects using the old extension. I loaded the new extension and example and got them working. When I exit AppInventor and get back in it seems that it goes back to the previous extension. This causes several of the code blocks to fail in the new program (greyed out and disconnected from other blocks). I have to reload the extension again, then I can replace the grayed out blocks with the correct block and it works again…until I start AppInventor again. This is very frustrating having to reload the extension and replace several block. Any ideas how to fix this? Do I need to create a new account without the old BLE projects?

5

Hi @Bill_Walter,

If you were using the BluetoothLE extension version 1 or version 2, you’ll have to do some surgery on your project to get rid of the old version. App Inventor handles upgrades of extensions based on the package name, and the earlier versions used a name different from the later versions. This results in App Inventor not knowing to delete the old copy, and so you get into a battle of the extensions.

If you export your project, you can rename the file to end in .zip, which will allow you to open it in most ZIP editing tools. You will want to go into assets/external_comps. If you see either com.google.appinventor.components.runtime.BluetoothLE or edu.mit.appinventor.ble.BluetoothLE, you will want to remove those (edu.mit.appinventor.ble is okay). Once you’ve removed the old version of the extension, rename the file back to end with .aia and upload it to App Inventor.

6

@ewpatton can I just delete the extension and import the new extension or will it still be infected? Also If I create a new project and import the new extension will it be OK? I’m OK with starting over, I need to make some significant changes anyway. I’ve never done any ZIP editing so that may be a whole new can of worms for me.

7

@Bill_Walter

The issue with deleting the extension is that it also deletes the instance and the corresponding blocks, at which point you’ll need to recreate the code. The methodology I proposed will remove the problematic extension without touching your code.

8

Got it. I’m going to completely change how I do the BLE communication now that I understand it a little better. I was passing the data in one log string and then parsing it all because I could not figure out how to use multiple characteristics with the old extension. The new extension seems to provide better tools for getting at the data than the old version. So I almost need to start over with how this is going to change what I’m doing. Honestly may be easier to just delete the extension and start over with coding the BLE the way I want it. It’s going to be a mess either way.

9

No worries. If you’re committed to doing the work there’s no reason to not start over based on what you’ve learned. Cheers!

10

@ewpatton

Thanks, you’ve helped me a lot. I’m really a hardware guy, I’m a total hack programmer :slight_smile:

11

Hello everybody. I am impressed from th power of the BLE extension, really great job! I would like to use the new ScanForService api, but I’m afraid I didn’t understand how. Is it a replacement of the StartAìScanning api? Is it an integration fo it? And in case, should I declare the ScanForService intent before calling StartScanning?
Thanks in advance for any clarification on this subject and best regards

Stefano (istvan54)

12

You can use BluetoothLE1.ScanForService method in place of the BluetoothLE1.StartScanning. The latter scans for and returns all devices whereas the former will only detect devices that advertise the specified UUID. You can use ScanForService to find only those devices that will work with your app (assuming it needs a specific service to work). We introduced this as part of a pilot of an improved IOT offering (yet to be published).

1 Like
13

If updating from an old Extension Version:
1)Clear the Backpack
2)Copy all Blocks to the Backpack
3)Delete the old BLE Extension
4)Import the new BLE Extension
5)Recover the Blocks from the Backpack

14

Thank you for the clarification, in fact that’s how I had tried to use it. But, though I used the right UUID for the specific service, I could not find the particular source that was issuing that service. However, I will try again and again.

Thanks again and best regards

Stefano

15

Hi Evan,

I was wondering in the BluetoothLE extension when you perform the connectGatt?

an example would be:
mBluetoothGatt=device.connectGatt(this,autoconnect, mGattCallback,BluetoothDevice.TRANSPORT_LE);

And if you do use the connectGatt, do you set autoconnect to true or false? And call the connect separately.

Thanks
Dave Carlson
Valencia, Ca.

16

Note that these steps are only required if upgrading from Version <= 2 to a newer version. If someone is going from a dated version, e.g., 20191118 to another dated version, the upgrade should proceed cleanly. The earlier versions had a different package name and different block names.

17

@dcarl661

There are 4 places where connectGatt is called in the BluetoothLE extension. I’m going to discuss its use in the Connect method since that seems the most relevant. The specific call is invoked on line 1573 of BluetoothLEint. We pass whatever the value of the AutoConnect property is at the time the Connect call is made.

1 Like
18

Thanks Evan,
Very nice code.

Btw last year I shared some of my work with Amna Greaves at MIT. I coded a sensor server for incident management that handles live and historic instrument readings. Amna’s team is compiling information on how different organizations share information. Our system shares data different ways with different organizations such as the EPA.

I’ve coded 70 instrument interfaces an I’m always researching and learning. I have one instrument where the timing of the BLE communication is strict, but the timing was different on some of the instruments. In my research I came across this site, and found it interesting.

Thanks again!
Dave Carlson
Valencia, Ca.

19

I have been quietly using this extension for awhile now and the filter scanning option is such a welcomed improvement.

I have also been working with other BLE modules where they are designated as central devices. One feature I have found to be extremely useful, which is not found here with the MIT BLE extention is the:

canRead / canNotify / canWrite checks you can make on the Characteristics discovered (once connected). Usually you do this check and if true you can then set up your Register or Read or Write Bytes/Strings etc.

Has this been considered at all? What would it take to include?

Look forward to the feedback.

20

Wow, I love it Thanks a lot @ewpatton for your News. im very happy :+1: :smiley: :+1: