I am rather new to MIT App Inventor. With the help of several tutorials I managed to implement my project quite efficiently. The testing environment works mostly well except the Bluetooth feature. I intend to control an ESP32 project with MIT App Inventor.
I have created an app menu structure consisting of several pages or what is called screens on MIT App Inventor. When I set up a bluetooth connection on a screen with the structure provided below all works perfectly well and I can send different commands to the ESP32. However when I switch from one page to another in the App, I get the bluetooth connection error 515 and I have to re-establish the connection on that MIT page/screen first.
I monitor the bluetooth connection on the ESP32 with an event function in a Terminal Monitor and there is no issue on that side as far as I am concerned. However for my MIT App the Bluetooth connection seems to be lost whenever I switch from one page/screen to an other.
How can I "define the bluetooth connection globally" within MIT App regardless of which menu/screen I select without re-establishing the connection on every screen first?
I found several posts regarding Error "515" but the ones I found are not related to switching issues betweens App screens.
Yes you are right. Changing screens disconnects the BT device. You could say that changing the screen is like opening a new application. If you need pages, use the Arrangement to build virtual pages.
This is a related question concerning Bluetooth Low Energy and multiple pages. I've used an astronomy app for several years that has four pages with two Bluetooth connections on the main page. The App continuously reads data from the two BLE connections, processes it and displays a set of results. I can move to other pages transfer data between them and the main page and return and the Bluetooth app will still be running. This happens whether or not I have AutoReconnect enabled. So my question is whether the Bluetooth is running when I'm on another page or whether it is reconnecting when I return to the main page?
I use a combination of multiple pages and virtual pages on each of the multiple pages because the app is complex and if placed on a single page would become unreadable and too slow to edit i.e. many minutes between editing operations.
That is correct, I am using the bluetooth classic as power supply isn't an issue in my project. I haven't tried switching pages with the auto-connect feature but I might try this out as my project is also getting bigger and the virtual pages concept has become rather complex. I will report if I have (positive) findings.
The property I use is the Blue Tooth Low Energy (BLE) AutoReConnect and this is isn't available with Bluetooth Classic. So it looks as if it is necessary to reestablish the connection using the IsConnected property, which I think you have already considered and is probably too slow. I believe the ESP32 is dual mode Bluetooth and can accept BLE commands, alternatively you could move to a BLE device such as the Arduino Nano BLE 33 but I recognise that is a very radical step.
The best alternative is not to use physical screens. then we get rid of the problem not only with BT but also with the transfer of data from the screen to the screen. It also prevents the screens from switching incorrectly. Not many people open their screens properly.
Using virtual screens, I easily download about 2kB of data from my device via both BT and USB. I split data into 20 pages, displaying this data in various text boxes, checkboxes, list selectors. After editing, the data is saved back to the device. So it's possible to live without physical screens.
Of course you can use screens, but you should do it carefully and correctly.
I agree it is very important to open and close the screens properly and virtual screens are a neat solution. However I sometimes use a combination of virtual and multiple pages because it is the only way I can keep the blocks easily readable - partly due to the complexity of the program but also because the bigger a single page gets the slower it is to edit until it can become impossible to edit.
I've attached an astronomy App that shows an approach to transferring data between multiple pages that relies on closing each page after use and returning to the main page when leaving a subordinate page. Best to focus on the first few blocks in each page to get an idea of how multiple pages can be used. This app transfers data between pages an runs multiple BLE data read connections which continue to run after a page has been switched.
The first few blocks on the main page show a method for reading two separate Bluetooth sensor devices and unpacking their hexadecimal data strings. The remaining blocks on the main page are only relevant to amateur astronomers. The additional pages are for calibration and for an editable data base but their relevance to Cervino's question is just the screen button and the first few initialisation blocks in each page.
Thanky you very much Peter and Patryk. It has been quiet here from my side for the last few days. I was very busy with the ESP32 microcontroller as I first needed to finish the project/code on the hardware side before continuing the work on the app. I now concentrate again on my App. Many thanks also for your valuable aia's. That's an excellent starting point for me with my App. For time being I will stick to the plan with the virtual screens (as suggested). More to follow.
Once, I also did something similar when I was still convinced that physical screens were the only option . On the other hand, one has to consider whether we really need a permanent connection. In some of my applications, I use auto-connect when sending data. The connection is interrupted after the data has been sent. Of course, this method will only be appropriate when we don't expect incoming data. However, if we only expect confirmation from the device, we can disconnect the connection after receiving the confirmation.
@ Patryk_F: just a general question for better understanding: is this page disconnect procedure an intended "feature" or is this just a limitation or flaw within MIT App Inventor?
I have figured this out due to having the same issue.
Its a little obnoxious but should help others.
But its much simpler than the above link
Step 1:
Locate the screen you want to Pick your Bluetooth device.
Create a Variable: Initialize Global "Name" to -> Make this a NUMBER out of the MATH menu
Set up the traditional
List_Bluetooth.BeforePicking
Set List_Bluetooth.Elements to BluetoothClient1.AddressesAndNames
-----Whatever other code you want----
Here is the Magic:
List_Bluetooth.AfterPicking
Set "Variable Created Above" to List_Bluetooth.Selection
Set List_Bluetooth.selection to -> Call Bluetooth Client1.Connect address -> get "Variable Created Above"
Call TinyDB1.StoreValue -> Make a nice Tag thats easy to remember and use, -> get "Variable Created Above"
BOOM!! you now have the Bluetooth selected address stored for access across the screens.
To move to new screen:
When "Name of Button for Screen".Click
Call BluetoothClient1.Disconnect
Open another Screen -> Screen Name
On New Screen:
Create a Variable: Initialize Global "Name" to -> Make this a NUMBER out of the MATH menu
When "Screen Name".Initialize
Set "Variable Created On THIS Screen" to -> Call tinyDB.GetValue -> "The tag you created"
If-> NOT->BluetoothClient1.Connected
Then
Set "Something Like a TextBox" to ->Call BluetoothClient1.Connect-> get Variable Created on THIS screen
There will probably be errors if you are trying to send or receive when changing screens so stop all BT communication before.
Be sure you call BluetoothClient1.Disconnect when leaving the screen otherwise you cant reconnect and it gets locked up. So add in the back button from the screen and if you have your own back button.
. On the other hand, one has to consider whether we really need a permanent connection. In some of my applications, I use auto-connect when sending data. The connection is interrupted after the data has been sent. Of course, this method will only be appropriate when we don't expect incoming data. However, if we only expect confirmation from the device, we can disconnect the connection after receiving the confirmation.