The attached program seems to work fine, however, when I close the device in the app, or close the app altogether, I cannot restart that device because it never shows up again “in range.” In order to restart the app, I have to compile and download again for my one-chance-only opportunity to connect to the device.light on_off_feedback.atmo (113.6 KB)
I will try and take a deeper look into this. I do know that there are issues with the ESP32 based devices being able to maintain a WiFi and BLE connection at the same time. So normally when you connect over BLE it will shut down the WiFi and once disconnected it only uses BLE to advertise and starts the WiFi connection back up.
But if I am understanding your situation correctly you can provision the device and connect to it once over BLE but afterwards you are never able to connect again?
Things you can try also is see if the device shows up in a BLE debugging app like https://punchthrough.com/lightblue/ to see if you can detect it advertising at least. It will show up with shot name like “D” or “P” that will at least tell us if the device is sending out advertisement packets over BLE
So played around with the project a little, I see that it tries to poll the BLE characteristic at 100ms at a time. I slowed that down to 1000ms and it is working better? It might be that the ESP32 is being overwhelmed with BLE read requests? I am seeing a lot of BLE read errors when trying to run the interval as fast as 100ms. I’ll keep poking at it and see if there is something else that can be done to make it work better.
I used LightBlue, filtered by RSSI to eliminate all but the closest and ended up with one device, D0B92. Cycling the power to the Huzzah32 caused LightBlue to loose contact, then reconnect with D0B92. The Atmosphere app shows no devices in range.
Perhaps I was premature in selecting the Huzzah32 for my project. Can you recommend something less “buggy”? All I need are seven GPIO ports.