E-stim systems 2B


#1

Let me first say that this project is a great idea. Having an universal open source api for talking to all kinds of sex toys opens up so many ways to have fun.

I have a E-stim Systems 2B e-stim device that I would like to connect to Buttplug. I’ve been reading the developer documentation but wanted to check if my idea on how to implement it is correct and I’ve got a couple of questions to get me started developing.

The 2B has a 9 volt battery besides a connection for a power adapter so I’d like to make a wireless solution for mobility. The idea I currently have is to use an Arduino with a BLE adapter (HM-10) that will connect to Buttplug and translate Buttplug commands to commands the 2B understands.

The 2B has a serial connection with an open API so connecting the Arduino to the 2B wouldn’t be a problem.

If I’m correct the Arduino would act as a Buttplug client and connect to the Buttplug server. It will then receive commands formatted in JSON over the Bluetooth connection.

There is support for the 312 from Erostek so I guess I could reuse the message types for that device. The device modes will probably differ so I’ll have to see what’s in the message types. I haven’t found those types in the documentation yet, are they available somewhere in a repository or is it still under development?

Would I need to make any changes on the server side for this to work? And the user UI, would that need any work?

I’m still wrapping my head around Buttplug and figuring out how I would implement this so any ideas, feedback and help is appreciated. I’m a Node.JS (Javascript) backend developer by trade so while I do have programming experience I’m not well versed in C# development.


#2

I also have a 2B. My current attempt is to have a raspberry pi 2 (+ usb to serial adapter + 2B link cable) act as a wifi client (using node and buttplug-js) and provide a serial port wrapper for the 2b (comparable to buttshock-js). BLE is too unreliable for such a “strong” device imo (imagine “off” messages get lost).

But I am not sure If it will actually work that way. Can a buttplug “client” delegate the control to an attached device to the server or is a clients sole purpuse to “control” a server (and its devices)?


#3

Ok, so on the 2B stuff, I’ll have to give you a followup reply in a bit, because it’s going to be pretty complicated.

However, if you want to stay in JS, we have a full node server that’s close to feature parity with the C# version. Still need to do ET-312 support.

I’ll probably be posting a CLI/native front end for it in the next day or two. :slight_smile:


#4

@rezreal, BLE has support for message ACK’s. I was thinking of implementing some retry mechanism on messages send to clients to prevent messages getting lost. All wireless communication methods have the problem that interference can cause message drops. You’ll have to find some way to work with that. Http has this build in untill your browser times-out. Some safeguards may be needed to be put in place like to shocking someone above a certain level for a certain duration.

I was planning on creating a central application that contains the control logic and runs the program. That can keep the device clients lightweight and run on simple hardware and keeps the control logic in one place for easier maintenance. Heck, maybe even Node-Red can be used to create the program.

@qdot You already have experience running the 2B using Buttplug? I read the docs of the JS implementation and I’ll give that a go shortly. Only thing I’m a bit confused about is the role of the server and who controls who? Does a client directly control an other client or will the server act on client messages and then send commands to other clients who should act on it?


#5

Ok, finally have some time to sit down and explain the state of stuff. :slight_smile:

So, first off, the ET-312. We’re releasing v0.2 of the C# libraries, and something like v0.5 of the JS libraries, tomorrow. In the C# library, there will be support for controlling intensity of the ET-312 signal as a ramp. There’s not even a specific command for it, they’re just piggybacking on the Fleshlight Launch commands. There’s a couple of reasons for this:

  • The implementor mostly wanted it working with movie sync
  • We haven’t really fleshed out how much ET-312 API surface area we want

That second part is REALLY difficult with the ET-312, since it only has 2 commands: peek and poke. Other than that, you’ve pretty much got access to all of the RAM, which could be fairly dangerous in hands you don’t trust. That’s why it’s such a slim feature set for right now.

I haven’t had time to port this to JS yet, so unfortunately I don’t have a good example of how it’d look there for you. If you’re considering taking a shot at it, first check out the Buttplug Spec, at https://metafetish.github.io/buttplug, which at least has some explanation of our protocol. The Developer Guide at https://metafetish.github.io/buttplug-developer-guide would also be worth a look, but it’s very half-finished. I’m happy to answer any questions after that.

I haven’t actually tried a 2B yet. Never been able to get my hands on one, and estim has been low priority while we get the base system working. If you’re gonna try putting in 2B support, you’ll want to implement your own DeviceSubtypeManager and have it connect to the 2B, then hand back a device that derives from IButtplugDevice and fills in all of the interface functions. There’s an example of this for the native Noble Bluetooth stuff at https://github.com/metafetish/buttplug-node-bluetoothle-manager, though that just fills in the required native bluetooth functions for the bluetooth devices that are already in the main library, so it’s not a 1:1 match for your needs.

We’ve got ET-312/ET-232/2B protocol docs available at https://metafetish.github.io/stpihkal in case you need references.

Also: You’re gonna need to be VERY careful about your choice of BLE radios. Cheap ones drop like crazy, and retry will still by slow as hell (like x100ms). I really dunno if I can recommend using bluetooth for wireless estim, but it’s not like people listen to what I recommend anyways. :slight_smile:


#6

Thank you for the info. I read the developer documentation that is available. Based on the npm package I’m developing a server and client application. For now I have the 2B connected to my laptop over USB until I get the parts needed for the Arduino solution.

You mentioned I have to implement my own DeviceSubtypeManager. Did you mean the DeviceManager or the IDeviceSubTypeManager? I don’t see a DeviceSubTypeManager in the api docs for the Typescript sources and the iDeviceSubTypeManager has methods for scanning for Bluetooth devices.

What I’m not sure about is if I have to implement the message types and DeviceManager in the client or the server or both.

Thank you for the feedback on using Bluetooth. I’ll see how it performs and if it doesn’t work well I’ll switch to using a different radio. I have some nRF24L01 radios or maybe websockets over Wifi using an ESP8266.

The 2B fortunately has a better API than the ET-312 so interfacing with it shouldn’t be much of a problem.


#7

I can at least tell from earlier experiments that the 2B is pretty robust when controlled via serial (even with a bare arduino uno as ttl-bridge) - as long as you keep the command rate < ~500 ms. Thanks for the stpihkal article qdot!