Added generic_btle protocol to support diy/generic devices over btle

[orangejuice24]

I am interested in trying to develop a simple esp32-based toy and get it integrated with buttplug. I did some looking on how to use BLE to connect with buttplug and I didn't find anything obvious. So after some work I cobbled together this code to get a proof of concept working.

It allows a 'generic' device to connect over BLE to buttplug and dynamically report its actuators and sensors. I did some simple testing to verify that setting vibrators and subscribing to sensors works on the surface.

I chose to use CBOR as the messaging API to keep message size low and keep requirements on the esp32 light. I tried to use some other serialization libraries, like FlatBuffers, but the result turned out to be pretty complicated. CBOR seems to produce pretty small messages and seems pretty fast, so I stuck with that.

The actual message API is not documented anywhere other than the code. I can write some docs up if that would help, or I can rework the message API to fit better with buttplug. Maybe there is a way to actually pass buttplug messages from the esp32 directly to the server. Not sure how large those messages can get though.

I also had to make some additions to the device-config.yml files but I wasn't 100% sure how to regenerate all the json files so I left that out for now.

The code in its current form is probably not up to standards with this project, but I am interested in working to get something merged.

The corresponding esp32 code is here: https://github.com/orangejuice24/esp32-generic-btle/

Thanks for taking the time to look at this!

[CLAassistant]

All committers have signed the CLA.

[qdot]

First question: why this instead of tcode, which is already widely supported and what we've been recommending for years?

[orangejuice24]

I took a second look at the tcode information on the protocols page and I think that tcode could definitely work here instead of the cbor code.

The first time I had looked at the documentation I didn't think that the protocol supported reading/subscribing to data from the toy. That's one of the main features that I am looking to support and one of the reasons that I didn't look closer at using tcode for this.

The second reason I went down the CBOR path was to facilitate dynamic construction of toy actuators and sensors. After looking again at the tcode protocol, the device commands could support that use case if a way to return data from the toy is added.

If the tcode protocol can be extended or updated I would be open to reworking this code to use that protocol instead of the cbor-based one.

[qdot]

This PR has zero chance of coming into the codebase until there is some sort of widespread device support for it. I'm not committing a new protocol for a single user's DIY device.

We do need a better way of supporting protocols than having to bring them directly into the library (I'm considering some scripting options like lua), but until then, I've usually been pointing our users to our websocket device system. Unfortunately that pushes the onus of bluetooth control onto you, which I understand is a pain. So I'm not quite sure how to balance this right now.

[orangejuice24]

No worries, I totally understand where you're coming from.

I probably should have been more clear in my original post about the 'generic' protocol. I was imagining that it could be used more as an API for toy development than as an implementation for one specific toy.

There doesn't need to be a specific protocol for this generic device though. That just seemed like the most obvious path to me.

Maybe I could add more functionality the buttplug_passthru protocol? Then a toy could send and receive json (buttplug) messages with that as the protocol and btle as the communication. Then the toy would be able to fit itself to the buttplug spec instead of something that is derived from it.

I don't think the dynamic addition of actuators and sensors is critical. In the case where someone is building/developing a toy I doubt the sensors and actuators will change so much that they would need to dynamically add and remove them. The user device config files would definitely work in this case.

[qdot]

I probably should have been more clear in my original post about the 'generic' protocol. I was imagining that it could be used more as an API for toy development than as an implementation for one specific toy.

Until you actually have traction on this, it's a implementation for one specific toy. That's why we went with tcode for this beforehand. It was proved out on other hardware then we brought it in. While the idea of actually setting our own protocol specs for DIY integration with our library is interesting, it's going to need a ton of design thinking and consideration that is not currently anywhere on our roadmap, and that I definitely don't have resources for right now.

In other words: I meant what I said in the contributions portion of our README. https://github.com/buttplugio/buttplug/tree/master/buttplug#contributing

If you want to keep discussing this, open an issue, and link to this closed PR for examples.