[Video]: Bluetooth BLE and C++ classes

[Shcreasey]

@kolban

Hey Neil, just wondering which version of the IDF your'e testing this code against?

2.0 being the current stable release, but further changes and enhancements are in 2.1r1

Regards,

[elsabz]

Hello Kolban, you're a light in the sea thanks for your work ...
I wanted to ask you: Should I vibrate a TW64 bracelet from ESP32, is TW64 a BLE server?

[kolban]

Howdy Steve, as a matter of course (and for no great reason) I always work against the very latest ESP-IDF master version of the code from Github.

[kolban]

Howdy elsabz,
The light in the sea is from my cell phone as I try and call for help ... I too am alone and lost and the sharks are getting closer.

In principle, I believe we can interface with a TW64 ... and I have a box of them. However I haven't played with those yet as I tinker with getting the C++ classes right first to make tinkering at BLE level consumable (for me).

[elsabz]

Hi Kolban, Thank You for the answer...
If I connect to a blescanner app, from smartphone to TW64, I can connect and even bonded, see the generic access profile, generic attribute and custom service, write values are only two attributes one in the generic attribute and one in the custom service. I tried to write something, but I do not know what I have to write to make it vibrate, I'm pretty lost in the sea and the sharks know I'm coming soon

[kolban]

When we look at a 3rd party BLE device (eg. the TW64) they can design their own services and characteristics and don't have to publish the protocols that we would need to know in order to interact with it. For example, if we read here:

http://www.ideyatech.com/hello-android- ... ow-energy/

We see a good article on scanning such a device and we are presented with the "front door" information. This is the information that BLE makes known as part of the BLE protocol exchanges. However, looking at the exposed items, I think I am seeing two services:

UUID: 0xffe0 and UUID: 0xfff0 with characteristics that are not architected by the BLE specification. This means that in order to interact with the device, we seem not to have enough public information to do so.

Now what does that mean to us?

Well ... if the manufacturer choose not make the protocols publicly available, we have to hunt around the Internet looking for reverse engineered data (or reverse engineer the information ourselves). This causes me to wonder (out loud) what the legalities of that are? For example, if you or I were to start examining the BLE protocol packets and somehow discovered the underlying protocol ... what laws might be being broken if we then started publicly sharing that or even built our own apps to exploit this reverse engineered protocol?

[Shcreasey]

@Kolban

Hi Neil, I have a few questions / suggestions:

1) Given your answer to my question about IDF version, do you not find that you encounter problems as things are changed (potentially daily) in the latest active IDF? Or do you take a snapshot of the latest IDF when you begin to develop a new project?

2) I wonder if you could modify your organisation of the CPP classes on your GItHub repo, to make it a little more accessible?
My suggestion would be:
a) Place it all in a /BLE sub-folder
b) Place all the client classes in a /BLE/client sub-folder
c) Place all the server classes in a /BLE/server sub-folder
d) add example code (i.e. based on that shown in your video) to the /server folder as example.cpp etc.
(so that people browsing the repo have a starting point for understanding the usage)

3) Does the top level BLE class need to be instantiable? or would it perhaps be better to make it static? exposing functions for creating either a client or server object (and probably also containing common constants etc.) and then move client or server specific code to either the client or the server classes?

I'm still trying to get to grips with both the ESP-IDF BLE APIs and your CPP classes, so please excuse me if my comments aren't helpful

Also, I don't know if you have a more efficient means of communication than this forum you would like to use, but it seems to take quite a long time to get my posts moderated and published, so the time lag is quite painful for a detailed discussion.

Best wishes,

[kolban]

Howdy Steve,
Good discussion points.

1) In my environment (Ubuntu on Virtual Box on Windows 10) I have a single directory which contains the ESP-IDF and a Makefile which, when run, deletes it completely and scripts the re-creation of it from master at Github. I don't run the Make continuously, but once a week is about right for me. I may have been lucky, but so far, Ive never had the need to go back to a previous build. No regressions for me.

2) My coding of the BLE C++ classes has about come to an "minimum viable release". I started with the hard part (to me) which was the creation of encapsulation of a BLE server and over the weekend, finished up on a working BLE client. I am personally pleased (proud?) of the results and want to get them out there now for the examination of the community. Issues, concerns and suggestions will be examined carefully and in a timely manner. The first order of business is some good documentation and some good examples in a written form that can be followed (hopefully) easily. Too often great programs and libraries are written and the documentation left as a poor after thought such that no-one can consume. I want to try and do a good job on documentation and consumption.

The C++ classes started as "snippets" of code that I wrote for myself but wanted to make available to the community in case they were useful. The BLE project took on a life of its own and, because of its nature, became more than one class ... and hence we have multiple class files. I fully agree that this likely deserves its own folder structure.

The BLE class (top level) is meant to be a singleton ... an ESP32 is ONE BLE device ... from that one can instantiate one or more servers and one or more clients at the same time. The good news is that now I have got the core "working" the refactoring into a better structure can take place gradually over time.

I believe that the first hand-ful of posts one makes in the forum are moderated but after you pass a certain number (I don't know what that number is ... anyone know?) ... then you are "trusted" and your posts show up immediately.

If you or anyone else needs a more convenient mechanism to reach me, I suggest ping me on IRC in #ESP32 channel. From there, we can open up a private conversation as needed.

Neil

[Shcreasey]

That sounds great Neil. How can I help?

Regards,

[kolban]

Here is a link to the first draft of a programmer's guide on the BLE C++ Wrappers ...

https://github.com/nkolban/esp32-snippe ... 0Guide.pdf

I'll keep it updated as we move along.