I have created an app that communicates with esp32 and send data from and to the app every second. sometimes the app gets disconnected or while using the app in the background if I start using another app the app disconnects the Bluetooth.
I am not able to figure out what seems to be the problem because this happens randomly. sometimes everything works perfectly sometimes it disconnects.
Hi @Vrt,
your problem seems exactly the same as
Please start by browsing that post then, if you could not have help from its reading, please let us know.
Thanks for the reply
what seems to be working for me is I have given permission to the app manually by pausing > " Pause App Activity if Unused " and by giving "unrestricted" access to the app for battery permission.
still, the problem seems to be arising randomly.
can I give the backend side permission to the app to stay connected to Bluetooth even if we switch from one app to the other?
Hello,
this is a pretty good question. Maybe other PU's, which have used the "background" feature of AI2 can give you a more detailed answer.
What I've done in the past it has been to split the screen in two halves: in one half my app is always running, and it does not go in background, so the BT comm's never stops, while in the second half of the screen I can load another (i.e. Google maps) app that runs without interfering with my app. While maintaining in the first half my app always running, I can load/unload any other app in the second half of the screen (taking care to not load in the second half any app that is using the BT, otherwise this would create a mess to the BT comm's).
Lastly, since the user that was facing the same problem was also thinking about an ESP problem (but he didn't post the final solution,yet) you can try to ask him directly your question, by connecting yourself to the other thread.
for my application, I need the full screen. for now, I am stuck in this situation.
what else can be done to resolve it?
Ok you need the full screen, but you want also to use sometimes other applications which cause your app to go in the background. (f I've correctly understood): I've never had such needs therefore I don't have a ready answer.
Probably other PU's have already faced such issue.
@Juan_Antonio perhaps have you already had such experience ?
Thanks a lot.
Ugo.
PS
To be sure that it isn't the ESP32 that disconnects itself autonomously, if you make your app staying alive "forever" does it work without disconnecting ?
Does bluetooth disconnect when your app is idle and goes to background? The screen turns off and after a while bluetooth disconnects? What does your app do, what is it for? You probably need a BluetoothService extension that doesn't exist.
Thanks for the reply
Esp32 Bluetooth is always on. usually, it works fine if I give the permission I stated above. but at random times I have seen the app disconnects the app randomly without any reason. Even if I have the screen on, or if the screen is off, or if I start using other apps on the same phone.
thanks for the reply 
what my app does is esp32 has 2 connected sensor which measures voltage and current flowing through a circuit and send the data per second to my app and the app displays those data on the screen. the data is sent over Bluetooth. so at times during the testing of the app with different phones or even the same phone, the Bluetooth of the testing phone disconnects but the Bluetooth of esp32 is still on. so the relevant data that is being used to display doesn't show up on the screen.
no matter what the condition of the phone or the app the Bluetooth at random times even after giving relevant permission to the app disconnects from the esp32.
This is pretty weird: I have an application that works (a pad receiving data from an ESP32 every 50 milliseconds) for hours without any trouble. But, as I said, the app is always on; i.e.no save screen: I use a @Taifun extension to keep the screen on.
Do you have perhaps another BT device in the nearness (paired in the past with your phone) that can interfere ?
Is there any watchdog on the ESP32 enabled ?
Do you use the "delay()" function on the ESP32 ?
thanks for the reply
Esp32 uses delay() in my code but initially, it never used to have this kind of random disconnect.
the watchdog timer is not being used.
what will happen if I use that always screen on function and the user clicks the lock button will the always screen function still work?
Interesting: this means that at the beginning, when your code was (let me say) "simpler", the random disconnection was not present ? If yes, could you try to move backward by removing parts of code and seeing what happens ? One side at at time: i.e. before on the ESP32 and, if without improvement, as a second step, on the app.
In the worst case you can start from scratch, by making a simple app and a simple ESP32 code, communicating each other, and see if they stay alive.
OK no watchdog (on some 8266 the WD is factory enabled, but yours is an ESP32, therefore if you haven't enabled it, I don't think that there is one set by default).
The delay() function disables the interrupts (on some implementations) therefore the comm's is interrupted.as well. You can try to use the delaymicroseconds() in place. If you need details, @ChrisWard has this chunk of code in his web site (and in many posts here in the forum).
Best wishes.
"what will happen if I use that always screen on function and the user clicks the lock button will the always screen function still work"
Never tried, sorry
In my opinion it will cease to work, but "never say never".
Does the app collect data? Does it save them to a spreadsheet or other database? Does it just display the current value on the screen?
yes, the app stores the data on an Excel sheet and displays the values every second.
Hi, thanks for the reply
I am already using USB to power the esp32. Still, the random disconnection is still present.
OK, I agree that what I suggest you now could cost you a lot of work, but it seems that the last chance is to go backward 'till you find a stable situation, or to start from a basic stable code, then by adding on that version the features you want, until you find the one that causes the failure.
