Hi! We've fully reverse-engineered the BLE protocol for a new device and would like to discuss the feasibility of Buttplug support.
Device
Nipple Cup Mirai by SSI Japan (WildOne Japan), released March 2026. Features rotation (forward/reverse) and suction motors.
It uses the Meiyu OEM platform by RongShengQuan (Shenzhen, China), which is shared across multiple adult toy manufacturers. Supporting one Meiyu device could enable support for many others.
Key Finding: BLE Advertising, Not GATT
This device does not use BLE GATT connections. Instead, it uses BLE Advertising (Beacon mode):
- The phone acts as a BLE Advertiser, broadcasting commands as Manufacturer Specific Data
- The device passively listens and executes received commands
- Communication is one-way (phone → device only)
- Manufacturer ID:
0xFFA0 (65440)
- Advertising type: ScannableUndirected (Type 2)
Protocol (Verified via Packet Capture)
AA 0B [motor] [direction] [speed]
5 bytes, fixed length, no encryption.
| Byte |
Name |
Values |
| 0 |
Header |
0xAA (fixed) |
| 1 |
Command |
0x0B (motor control) |
| 2 |
Motor |
1 = rotation, 2 = suction |
| 3 |
Direction |
0 = stop, 1 = forward/on, 2 = reverse |
| 4 |
Speed |
1 to 10 (10 = max) |
Verified Commands (captured from Meiyu app)
| Action |
Bytes |
| Rotation forward, speed 9 |
AA 0B 01 01 09 |
| Rotation forward, speed 10 (max) |
AA 0B 01 01 0A |
| Rotation reverse, speed 9 |
AA 0B 01 02 09 |
| Suction, speed 9 |
AA 0B 02 01 09 |
| Suction, speed 10 (max) |
AA 0B 02 01 0A |
| Stop |
AA 0B 01 00 00 |
Device Behavior
- Continuously executes the last received command
- Stops after a few seconds when advertising ceases (watchdog)
- Meiyu app sends commands every ~500ms in 1-second advertising bursts
OEM Platform: Meiyu / RongShengQuan
- Package:
com.RongShengQuan.SiYuPlay
- App variants: Meiyu, SubtlePlay (same developer)
- Communication methods:
"2.4g" → BLE Advertising mode (Mirai uses this)
- Other → Standard BLE GATT (same command format, UUIDs contain
ffa0/ffc0)
- Multiple manufacturers use this platform, so one implementation could support many devices
Methodology
- APK decompilation with jadx — identified
sendBluOrder(), BeaconManager, and command structure
- Real-time packet capture using Windows BLE Advertisement Watcher — intercepted Meiyu app's advertising packets
- Device control verified from PC using BLE Advertisement Publisher
Discussion
We understand that Buttplug currently assumes GATT-connected devices. This device requires the controlling side to act as a BLE Advertiser rather than a GATT Central, which is architecturally different.
We'd love to hear your thoughts on:
- Is there interest in supporting BLE Advertising-based devices?
- Would a bridge approach (e.g., ESP32 translating GATT → Advertising) be more practical?
- Are there other Meiyu/RongShengQuan devices already known to the community?
We have the full decompiled source, a working PC control script, and detailed research notes available if needed. Happy to provide any additional data that would be helpful.
Thank you for the incredible work on Buttplug!
Hi! We've fully reverse-engineered the BLE protocol for a new device and would like to discuss the feasibility of Buttplug support.
Device
Nipple Cup Mirai by SSI Japan (WildOne Japan), released March 2026. Features rotation (forward/reverse) and suction motors.
It uses the Meiyu OEM platform by RongShengQuan (Shenzhen, China), which is shared across multiple adult toy manufacturers. Supporting one Meiyu device could enable support for many others.
Key Finding: BLE Advertising, Not GATT
This device does not use BLE GATT connections. Instead, it uses BLE Advertising (Beacon mode):
0xFFA0(65440)Protocol (Verified via Packet Capture)
5 bytes, fixed length, no encryption.
0xAA(fixed)0x0B(motor control)1= rotation,2= suction0= stop,1= forward/on,2= reverse1to10(10 = max)Verified Commands (captured from Meiyu app)
AA 0B 01 01 09AA 0B 01 01 0AAA 0B 01 02 09AA 0B 02 01 09AA 0B 02 01 0AAA 0B 01 00 00Device Behavior
OEM Platform: Meiyu / RongShengQuan
com.RongShengQuan.SiYuPlay"2.4g"→ BLE Advertising mode (Mirai uses this)ffa0/ffc0)Methodology
sendBluOrder(),BeaconManager, and command structureDiscussion
We understand that Buttplug currently assumes GATT-connected devices. This device requires the controlling side to act as a BLE Advertiser rather than a GATT Central, which is architecturally different.
We'd love to hear your thoughts on:
We have the full decompiled source, a working PC control script, and detailed research notes available if needed. Happy to provide any additional data that would be helpful.
Thank you for the incredible work on Buttplug!