I'm developing an application using MIT App Inventor to communicate with an ESP32 device over BLE. The initial connection works flawlessly, and I've implemented a PING/PONG mechanism to maintain the connection.
Issue:
The problem arises when I close the app or navigate away from the BLE-connected screen. Upon returning, the app fails to detect or reconnect to the ESP32 device. It appears to be scanning but doesn't find the device. However, if I manually turn Bluetooth off and then on again on my phone, the app can detect and reconnect to the ESP32.
Observations:
The issue seems specific to the MIT App Inventor app not recognizing the device after the app is closed and reopened.
The app includes explicit disconnection logic using the BluetoothLE1.Disconnect block when navigating away from the BLE-connected screen.
Request:
Has anyone encountered a similar issue or have suggestions on how to resolve this reconnection problem? Any insights or guidance would be greatly appreciated.
Dear, first of all so many blocks are collapsed that it is a bit difficult to correctly follow the flow of your code. Anyway, please bear in mind that typically when you change screen (i.e. from Screen1 to another one) the BT ceases to work. This applies for sure to the classic BT, and most probably aslo to the BLE. Moreover I see in your blocks that you use alternatively blocks related to the classic BT (the BluetootClient1 ones) and those related to the BLE: do you have both BT's active in the same app ? This is possible and to achieve that you can see my post
but is this what you really want ?
When you leave the app (you say you navigate away from it) what does the ESP32 ? is it still sending the Ping/Pong (I suppose it is a handshake) or it ceases to do that and waits for a new connection ?
Please also be aware that when you disconnect the BT or BLE, this does not mean that the device's BT is switched off, but that the connection has been interrupted on device side only. Therefore a device's BT switch off and on, as you do, resets completely the BT circuitry inside the device, and this allows a new pairing in case of classic BT a a new BLE scanning in case of BLE.
If you don't need actually to have both classic BT and BLE, could you use only the classic BT for your application ? (the ESP has both available). Probably it is more simple and reliable.
Best wishes.
Hello, thank you for your answer. I collapsed the block that are not related to the issue, (Label text changes eg...).
When i change screen my device Bluetooth is still on. Even tho "it cease to work".
I use the BluetootClient1 because its the only way i found to verify if the device Bluetooth is turned on, for it to proceed to the connection.
I only need the BLE i don't use the classic bluetooth. I do need the BLE because of its "automatic connection", where for the classic B the user needs to connect outside the app, BLE can connect without user.
The ping pong, is to verify connection, Every 10 second a pong is send. When the ESP32 stop receiving a pong it automatically disconnect, I haven't done the receiving end in Mit app invetor yet, because it it solved with :
Dear @Fryan,
honestly I'm not that confident that by testing the Classic BT connection is a valid means to verify whether also the BLE is still operating.
Also because to be sure that the BT (Classic) is not disconnectd you should have connected it before (do you connect the classic BT somewhere else in your code ?).
And if you disconnect the classic BT, the BLE can still work (you can use my example to check that).
In the forum there is also another post of mine in which I explain how to make a true handshake between a BT server and a BT cllient (Classic ones), to perform a reconnection trial if the BT fails (i.e. an unwanted disconnection happens).
At the end, my hint is to have a simpler app, that performs a BLE comm's toward the ESP32, and to verify the connection/disconnection/reconnection capabilities (without any Classic BT blocks) and only once you are done with that, you can add the rest of features.
Best wishes.
