Did you plan to implement notifications and also callbacks on descriptors (this enable notifications)? For reading sensors I use this a lot and also working on some kind of cheap ESP32 BLE logging multimeter. So the BLE client can decide by enabling notifications when to be flooded by sensor data or on the other hand by disabling notification keep the BLE server quite.

You betcha my friend. Callbacks for a peer read request and write request are already in place. When a read request arrives at the ESP32, the default is just to return the current value of the ESP32 managed characteristic but we have the option of providing a callback that is invoked to provide a new value ... and that would be the value returned. Correspondingly, we have the notion of a write callback. When the peer writes a new value to the ESP32, a write callback is invoked to that our logic can be signaled that the data has changed and we can perform some action. We also have outbound (from ESP32) inform() and notify() methods. These allow the ESP32 to indicate to the peer that the value of an ESP32 characteristic has changed and the peer might then choose to "do something" with that knowledge.

I've seen it possible. One thing to do is remap you memory map to get rid of OTA. But it's a challenge as they share the same radio

Howdy David. Its a good question. I can offer my opinion ... While the ESP32 and ESP8266 can obviously be used by hobbyists, that is not the primary market for these products (opinion). Instead, they are designed to used by OEMs who will build high volume products of which the ESP32 and ESP8266 are components. When one builds high-volume anything, a small difference in price of a component scales up when you but in large quantities. While the ESP32 has much more power and function as compared to the ESP8266, that currently comes at a literal price cost. You should currently expect to pay more for a unit of ESP32 than for an unit of ESP8266. When designing a product for high volume production, you will then want to choose the "cheapest" component that will do the job. If what one needs for a given product is withing the specification of an ESP8266 then one could argue that you would be wasting monies using a higher specified product (the ESP32). The flip side, of course, is that if your product requires capacity or a feature found in the ESP32 but not present in the ESP8266, the story becomes moot. If you are a hobbyist and employed .... and not contemplating high volume production, I personally would recommend working with the ESP32. The capabilities of that device are "so much better" while the price differential appears to be about the cost of a large cup of premium coffee.

Hello Mr. Kolban, first of all let me tell you that your videos are amazing. Thank you for your reply to my inquiry. I am working on a project which needs a wireless sensor node. So far i am developing on a STM32 based mcu and my research for alternatives lead me to your videos. I am still undecided if i should use the arduino adaptation or not. Andreas Spiess who is also on youtube and you should team up and make the perfect esp powerduo to be honest.. Thank you for providing such quality.

There is a sample BLE scanner found here ... github.com/nkolban/esp32-snippets/blob/master/cpp_utils/tests/BLETests/SampleScan.cpp

Hi Eddie. BLE does indeed provide a wealth of security possibilities. This is the start of the project and we'll add more security features as requested. There will be a few options that immediately come to mind. The first is that we have the notion of "passkeys". Imagine, for example, that when you connect to the ESP32, the ESP32 presents a pass-key to the user. This would require I/O. The same pass-key would be presented on your "phone" and you would be asked to confirm that they are the same. Another option would be to initially allow connection from anyone but, once you have "married" your ESP32 and "phone", the ESP32 would maintain a white list of only those devices allowed to connect. There might be a reset button on the ESP32. These are only two choices and I'll be there are more. Have a look around at how other devices are secured with Bluetooth and what ever they do, we can expose at a high level with the ESP32.

No problems ... see the following ... esp32.com/viewtopic.php?f=13&t=2330