Layer 1

We're creating a new communication standard for our sex toys and we're looking for your input. Does this framework support your workflow?

How do we enable play between all R+D devices, without any configuration or servers (N:N decentralized)? That's the problem Alex posed to me in early September. And my response was the R+D JSON framework. It's a very simple protocol designed to enable fun immediately.

It works for our use cases today, but we need to make sure it works for our community devices as well. So, now is your chance for input! Help me design this framework so that it meets your needs as well.

Proposal

The R+D communication protocol is a set of user experiences and standards to uphold those experiences.

These rules must be true for all R+D Integrated devices and apps.

Experiences

When a user turns on 2 to 20 R+D devices/apps in physical proximity, all must immediately do something fun with zero configuration.
If a Wi-Fi connection is enabled, the device must also be controllable from the R+D app, anywhere in the world.

Standards

Compatible devices must be EspNow ready.
Wifi is strictly optional.
All devices communicate over EspNow constantly.
All devices can communicate concurrently over a private websocket associated with that user's profile
Each device broadcasts (on channel ff:ff:ff:ff:ff:ff) iits own state using R+D JSON.
Each device listens for all broadcasts.
Listener functions may never trigger another broadcast. (ex: I received "failure" so I send "failure" so they send "failure" so I ...)
However, Each device controls its own state and may choose to ignore or act on these generic broadcasts.
Broadcast events must occur between 4-30 times per second.
The Listener function must be called on every loop.

R+D JSON

This structure is in development.
But here are the rules that govern it so far:

All data packets have the same structure. - early example below.
Event names are standard and identical across all devices "start", "data", "fail", "succeed", etc.
All values included in the data packet are three-dimensional vectors scaled to integers from 0 to 100.
All data packets must include the type of device from a shared, universal enum - "DTT", "OSSM", etc.
All data packets must include the MAC address or another unique identifier for the device.
The data must include the current "mode" for the communication. Right now this may be "play" or "control"
If "control" is defined, then a single target must be specified by id. If multiple are required, then multiple messages are required.

Examples

// Example broadcast from a DTT to all nearby devices.
{
  "id": "40:CD:E7:90:F4:0C",
  "device": "DTT",
  "mode": "play",
  "target": "",
  "event": "data",
  "value": [23, 0, 0],
  "position": [0, 0, 100],
  "velocity": [0, 0, 0]
},

// Example broadcast from a Web-based controller to a specific device.
{
  "id": "19:53:E0:4D:6A:8B",
  "device": "WEB",
  "mode": "control",
  "target": "04:E7:68:F8:85:8B",
  "event": "data",
  "value": [0, 100, 50],
  "position": [0, 0, 0],
  "velocity": [0, 0, 0]
}

What do you think?

Any device that follows these protocols will be considered officially R+D Compatible. But, more importantly, these designs are hackable! This means any creative project that uses these communication rules can integrate with or control our devices (don't worry, we've got security installed for web-based controllers).

But, does it work for you? Will you be able to integrate your devices?

Click here to email me! I want to hear your opinion. AJ@ResearchAndDesire.com