Introduction

Cemuhook is modification for Cemu WiiU emulator which allow to do all sorts of cool stuff, including custom button/motion sources.
Purpose of this document is to shed light on previously undocumented protocol it uses.
Only one known and existing version of protocol at the moment of creation and last modification of this document is 1001 which is described below.

Common information

• Cemuhook use UDP protocol, which may make things tricky but very efficient
• Cemuhook use server at localhost:26760 (number is a port)
• Your application should serve all sources it can, not few different instances of it.
• Each (valid) packet either from cemuhook or your server contain:
• • Header (16 bytes)
• • Message type (4 bytes)
• • Other data

Numbers encoding

You can refer to C# implementations of BitConverter for details on this.
Numbers are encoded as little endian, which is also native endian on most platforms in the world (but not all).

Header structure

Below I'll refer to all positions after cutting out first 20 bytes and implying that structure above is included in your response at the beginning.

Message types

Same constants are used both for incoming and outgoing messages. So if you got message with some type, response(s) to it will have same type value.

Protocol version information

This message type carry no extra incoming payload and require you to reply with maximal protocol version supported.

Incoming packet structure

Outgoing packet structure:

Shared response beginning for message types below

Both "Information about connected controllers" and "Actual controllers data" responses begin the same way that is described below:

This structure is 11 bytes long.

Battery values

Information about connected controllers

This request type is a bit more complicated. When you receive it, you should report all controllers you serve (up to four).
This message have length of 12 bytes (32 total with structure from above).
If controller for some port is not connected, you can respond with 12 zero bytes (plus header).

Incoming packet structure

For every requested controller slot you should send one packet structured like described below.

Outgoing packet structure:

Actual controllers data

When you get this type of message, no instant response is required. Instead, you should begin or continue sending data from requested controller to this server. There is no way to know when client is gone, so you should implement some kind of timeout to stop sending data when client didn't requested data for some time.

If requested controller is not connected, message should be ignored.

Total message length (with packet header) is 100 bytes.

Incoming packet structure

Outgoing packet structure:

Bitmasks are described in descending order:, as bits in number go: 128, 64, 32 and so on.
All sticks use full 8-bit range (0-255). Set them to 128 for neutral value.
Analog buttons use full range as well. If button is not analog, report 0 for released and 255 for pressed states.
Acceleration values are in g's (1 g ≈ 9.8 m/s²), gyroscope ones are in deg/s.
There is no standard range for touch values aside from requirement to have x axis point rightward and y to point downward. Clients interested in using touch input should implement some sort of calibration method to determine touch range.

Touch data structure

(Unofficial) Information about controller motors

Query how many rumble motors specified controllers have.

Incoming packet structure

Outgoing packet structure

(Unofficial) Rumble controller motor

Set rumble intensity for controller motor. Only incoming packet.

Clients should periodically (twice to ten times per second) re-send rumble state (both zero and non-zero) to account for potential packet loss. Servers should reset motor's rumble strength to zero if they haven't received rumble packets for it for prolonged period of time (whatever you use for client timeout is a good estimate, which should be about 5 seconds) to avoid controllers getting stuck rumbling in the event client disconnects disgracefully.

Incoming packet structure