Support for Corsair Commander Pro (I figured out the protocol)

Question

Support for Corsair Commander Pro (I figured out the protocol)

pvh1987 opened this issue 6 years ago · comments

pvh1987 commented 6 years ago

Hello :-)

I am so glad I found OpenCorsairLink. I recently decided to build a new workstation. I purchased the H115i as well as the HX850i - I guess that was a lucky choice because, as I later found out, OpenCorsairLink supports both devices already. However, I also got a Corsair Commander Pro that works with Corsair LINK as well. I use this to control various fans in my PC case.

Instead of being disappointed that there is currently no support for the Commander Pro in OpenCorsairLink, I decided to figure out the protocol myself before I post anything here on GitHub. I succeeded, well almost - there is still a lot of RGB LED related stuff I have yet to figure out - but the most important things like fan control and temperature measurement are clear by now. I have included a very tiny test program to show that it works.

I hope that the protocol details below are enough to implement support for this device in OpenCorsairLink. Then soon, I can have my workstation just as silent in Linux as in M$ Windows. Thanks in advance :-)

Oh, by the way - what is the future goal of OpenCorsairLink? I get that at the moment, it is just a small tool to set up fans and the like, with no real monitoring support. I know that the official LINK software is able to monitor and inform devices, such as the Corsair Commander Pro, about temperature. That way, the temperature of a H115i or HX850i can control the fans connected to the Commander Pro. I guess a possible solution is to create a simple daemon that can run at boot time, constantly monitoring temperatures (at a set interval) and also have a small API that can be used to connect to GUI apps or panel applets, like the "MATE Sensors Applet" and similar. I think this is better than to connect/disconnect to the USB devices all the time directly... and what happens if more users are logged in at the same time, both monitoring/controlling Corsair LINK devices? Well... just some of my thoughts :-)

Please let me know if I can be helpful in more ways. I'm an electronics engineer and programmer, but I have little to no experience in Unix/Linux system programming. I do, however, have quite a bit experience with cross-platform desktop GUI programming (mainly C++ with wxWidgets) - so if a GUI for OpenCorsairLink is needed, I might be willing to contribute if I can find the time.

Anyway, still thanks - and below are my findings regarding the protocol and workings of the Corsair Commander Pro :-)

Introduction

The Corsair Commander Pro is a device that can connect to

6 fans (3- or 4-pin)
4 temperature sensors (included)
2 RGB LED channels
2 internal USB devices such as Corsair PSUs and CPU water coolers (acts like a hub)

The device can also measure the rail voltages from the PSU (supplied by a SATA power connector).
Each of the six fans can be monitored (RPM measurement).

The device connects to an internal USB connector on the motherboard.

Link: http://www.corsair.com/en-us/corsair-commander-pro

I have sniffed the protocol using a VirtualBox with Windows 7 and the so called "Free USB Analyzer" from HDD Software. BTW, it is actually not free software.
Link: https://freeusbanalyzer.com/

The protocol is described below. Additional notes are found below in the NOTES section.

IMPORTANT: The LED functionality of this device is complicated. I have not been able to figure out what is really going on with most of the LED commands. Some modes seems to work in a completely different way than others - some modes only transmits commands when applying settings, other modes "spam" the device with commands all the time. So much more research is needed here. Since I do not intend to use the LED channels myself, I doubt I can find the time to do this. My experiments so far with USB packet sniffing have already been very time consuming. I have tried to document some of it below, especially in the "Additional notes for LED channel operation".

Device Information (lsusb)

Bus 001 Device 005: ID 1b1c:0c10 Corsair
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 8
idVendor 0x1b1c Corsair
idProduct 0x0c10
bcdDevice 0.04
iManufacturer 1 Corsair
iProduct 6 Commander PRO
iSerial 128 0905031174181010
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 41
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xc0
Self Powered
MaxPower 0mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 3 Human Interface Device
bInterfaceSubClass 0
bInterfaceProtocol 0
iInterface 0
HID Device Descriptor:
bLength 9
bDescriptorType 33
bcdHID 1.11
bCountryCode 0 Not supported
bNumDescriptors 1
bDescriptorType 34 Report
wDescriptorLength 27
Report Descriptors:
** UNAVAILABLE **
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 1
can't get device qualifier: Resource temporarily unavailable
can't get debug descriptor: Resource temporarily unavailable
Device Status: 0x0001
Self Powered

(I don't know why it says "can't get device qualifier: Resource temporarily unavailable". It says that for all or at least most of my USB devices on my new Gentoo Linux PC. If you have any idea what is wrong, please let me know. The devices work just fine, however...)

Protocol Overview

The device operates as an USB HID device.

Commands are transmitted to device, 63 bytes long. The first byte indicates the request type.
Responses are received from device, 16 bytes long.
ALL commands are replied with a 16 byte response, often all zeros.

The first byte in all commands defines the type of command or request. In general
0x0? commands are for device information such as firmware version
0x1? commands are for temperature and voltage measurement
0x2? commands are for fan configuration and measurement
0x3? commands are for LED channel control

Command overview (number refers to the first byte in the command)

0x02 GET firmware version
0x03 Not sure what this does... maybe a request for an ID of some kind?
0x06 GET bootloader version
0x10 GET temperature sensor config. (Connected/Disconnected)
0x11 GET temperature (for each of the connected sensors)
0x12 GET voltage (Measure 12V, 5V or 3.3V rail)
0x20 GET fan mode configuration (Auto/Disconnected, 3-pin or 4-pin)
0x21 GET fan RPM
0x23 SET fan configuration (Fixed %)
0x24 SET fan configuration (Fixed RPM)
0x25 SET fan configuration (Graph)
0x26 SET fan temperature info (if the group is chosen to be an external sensor)
0x28 SET fan mode configuration (Auto/Disconnected, 3-pin or 4-pin)
0x32 (LED channel stuff, for RGB LL Fan mode? Hmm...)
0x33 (LED channel stuff, probably a "refresh" command of some kind)
0x34 (LED channel stuff, not 100% sure what it does)
0x35 SET configuration for a particular LED strip/fan on a LED channel
0x36 SET temperature info for LED channel 1 or 2 (if "Temperature" mode is chosen and an external sensor in "Group")
0x37 (LED channel stuff, not 100% sure what it does)
0x38 (LED channel stuff, not 100% sure what it does)
0x39 SET change brightness for LED channel 1 or 2
0x3B SET change mode? (from "RGB LED Strip" to "RGB HD Fan" or similar)

Protocol Details

0x02 commands are a firmware version request:
All other bytes in the request are zero.
Byte 0 is always zero.
Byte 1 is X.
Byte 2 is Y.
Byte 3 is Z.
The firmware version can then be interpreted as X.Y.Z. Example 0x0004AD => 0.4.173
The rest of the response is zero.

0x03 commands are somekind of a request. I don't think it is important for normal operation. It is transmitted only once, when the device connects with the LINK software. I suspect it could be a request for some kind of ID. I know that all other bytes in the commands are zero.
The response could be something like 00 85 69 B0 45 00 00 00 00 00 00 00 00 00 00 00. Not sure if what it is :-)

0x06 commands are a bootloader version request:
All other bytes in the request are zero.
Byte 0 is always zero.
Byte 0 is X.
Byte 1 is Y.
The bootloader version can then be interpreted as X.Y Example 0x0004 => 0.4
The rest of the response is zero (or is it possible to have a third number?)

0x10 commands are temperature sensor configuration request:
All other bytes in the request are zeros.
The response is an indication of which of the four temperature sensors are connected.
Byte 0 is always zero.
Byte 1-4 indicates if sensor 1-4 is connected or not: 0x00 => not connected, 0x01 => connected.
The rest of the response is zero.

0x11 commands are temperature requests:
Byte 1 is the selected temperature sensor (0..3 => sensor 1-4)
All other bytes in the request are zeros.
The response is the temperature of the selected sensor.
Byte 0 is always zero.
Byte 1 and 2 is the temperature as a two-byte big endian number. The temperature can be converted to degrees Celsius by dividing by 100.
The rest of the response is zero.

0x12 commands are voltage commands:
The second byte (byte 1) is the rail number. Following voltage rails are available for requests:
Rail 0: 12 V
Rail 1: 5 V
Rail 2: 3.3 V
The response (16 bytes) begins with 0x00 followed by a two-byte voltage in big endian. The actual voltage can be calculated by dividing the two-byte number by 1000.
The rest of the response is zero.

0x20 commands are a fan get mode configuration request:
Byte 1-63 are zero.
The responses is an indication of the fan configuration in the following format:
Byte 0 is always zero.
Byte 1-6 describes mode for each fan (6 fan connectors are available in the Commander Pro):
0x00 => Auto/Disconnected
0x01 => 3-pin
0x02 => 4-pin
0x03 => ?
The rest of the response is zero.

0x21 commands are fan get RPM requests:
These requests are transmitted regularly (~ 1 second intervals) for each fan set to "3-pin" or "4-pin" mode when monitoring with the Corsair Link software.
The second byte (byte 1) is the fan number, (0-5 for fan 1-6). All other bytes are zero.
The response (16 bytes) begins with 0x00 followed by a two-byte RPM count in big endian.
The rest of the response is zero.

0x23 commands are fan set mode "Fixed %" commands:
These commands are transmitted when selecting mode "Fixed %" or "Max" and applying in the "Configure Fan" dialog.
The second byte (byte 1) is the fan number, (0-5 for fan 1-6).
The third byte (byte 2) is the percentage. Example: 0x28 => 40%. In "Max" mode, this is 0x64 => 100%.
The response is all zeros.

0x24 commands are fan set mode "Fixed rpm" commands:
These commands are transmitted when selecting mode "Fixed rpm" and applying in the "Configure Fan" dialog.
The second and third byte is the RPM as a two-byte big endian number. Example: 0x1f4 => 500 RPM.
The response is all zeros.

0x25 commands are fan set mode "Graph configuration" request:
These commands are transmitted when selecting mode "Default", "Quiet", "Balanced", "Performance" or "Custom" and applying in the "Configure Fan" dialog. A "Graph Configuration" is set by six points of temperature and RPM. The default points for each mode can be seen in the NOTES section below.
The second byte (byte 1) is the fan number, (0-5 for fan 1-6).
The third byte (byte 2) is the group:
0xFF = N/A or an external sensor such as the H115i (The LINK software then transmits temperature regularly by 0x26 commands in this case)
0x00 = "CP Temp #1" (Commander Pro Temperature Sensor #1)
0x01 = "CP Temp #2" (Commander Pro Temperature Sensor #2)
0x02 = "CP Temp #3" (Commander Pro Temperature Sensor #3)
0x03 = "CP Temp #4" (Commander Pro Temperature Sensor #4)
Then follows 6 two-byte temperatures in big endian (divide by 100 to convert to Celsius) and then 6 two-byte RPMs in two-byte big endian:
Byte 3,4 is temperature for point 0.
Byte 5,6 is temperature for point 1.
Byte 7,8 is temperature for point 2.
Byte 9,10 is temperature for point 3.
Byte 11,12 is temperature for point 4.
Byte 13,14 is temperature for point 5.
Byte 15,16 is RPM for point 0.
Byte 17,18 is RPM for point 1.
Byte 19,20 is RPM for point 2.
Byte 21,22 is RPM for point 3.
Byte 23,24 is RPM for point 4.
Byte 25,26 is RPM for point 5.
The rest of the bytes are zero.
The response is all zeros.

0x26 commands are for temperature info notification to fans.
If the "Group" for a particular fan is set to an external sensor (like the H115i) in the "Configure Fan" dialog, this temperature is regularly transmitted to the Commander Pro with this request.
Byte 1 is the sensor number.
Byte 2 and 3 are the temperature as a two-byte big endian number. This can be converted to degrees Celsius by dividing by 100.
The rest of the bytes are zeros.
The response is all zeros.

0x28 commands are fan set mode configuration commands. The request is on the form
0x28 0x02 n m (the rest of the bytes are zero)
where
'n' is the fan number (0-5 for fan 1-6)
'm' is the mode as described in the description for 0x20 commands.
The response is all zeros.

0x33 commands are transmitted as the last command after a sequence of 0x3? commands.
It could mean something like "refresh all LED channels" or "I'm done transmitting 0x3? commands for now". I don't know for sure.
Byte 1 is always 0xFF.
The rest of the bytes are zeros.
The response is all zeros.

0x35 commands are transmitted for each LED strip/fan enabled, for each LED channel.
Byte 1 is the LED channel number
0x00 => "LED channel #1"
0x01 => "LED channel #2"
Byte 2 is the strip/fan number where
0x00 => Strip/Fan 1
0x0A => Strip/Fan 2
0x14 => Strip/Fan 3
0x1E => Strip/Fan 4
Byte 3 is the type of LED
0x0A => "RGB LED Strip"
0x0C => "RGB HD Fan"
0x01 => "RGB SP Fan"
0x04 => "RGB ML Fan"
(other types are not listed, since some of these seems to work in a totally different way and does not use 0x35 commands, but instead transmitting a lot of 0x32 and 0x33 commands all the time. Research is needed)
Byte 4 is the mode or effect (not named in the GUI) where
0x00 => "Rainbow Wave"
0x01 => "Color Shift"
0x02 => "Color Pulse"
0x03 => "Color Wave"
0x04 => "Static"
0x05 => "Temperature"
0x06 => "Visor"
0x07 => "Marquee"
0x08 => "Blink"
0x09 => "Sequential (channel effect)"
0x0A => "Rainbow"
Byte 5 is "Speed" where
0x00 = high
0x01 = medium
0x02 = low
Byte 6 is "Direction" where
0x00 = "Backward"
0x01 = "Forward"
Byte 7 is alternating/random color where (also see note below)
0x00 = "Alternating"
0x01 = "Random color"
Byte 8 is always 0xFF.
Byte 9-17 are colors where
Color 1 (R,G,B) is byte (9,10,11)
Color 2 (R,G,B) is byte (12,13,14)
Color 3 (R,G,B) is byte (15,16,17)
Byte 18-19 are the temperature corresponding to color 1 (in "Temperature" mode).
Byte 20-21 are the temperature corresponding to color 2 (in "Temperature" mode).
Byte 22-23 are the temperature corresponding to color 3 (in "Temperature" mode).
The rest of the bytes are all zero.
The response is all zeros.
NOTE: If "Random color" is chosen, all color bytes (9-17) are zeroed as well.
NOTE: Byte 18-19, 20-21, 22-23 are 16-bit temperatures in big endian. Convert to degrees Celsius by dividing by 100.

0x36 commands are transmitted regularly by the LINK software to notify temperature to each LED channel. These are transmitted for each LED channel, one for all strips/fans configured on that channel, if "Temperature" mode is enabled AND "Group" is set accordingly.
Byte 1 is the LED channel number
0x00 => "LED channel #1"
0x01 => "LED channel #2"
Byte 2 is always 0x00.
Byte 3-4 are the temperature as a 16-bit big-endian number. Convert to degrees Celsius by dividing by 100.
The rest of the bytes are zero.
The response is all zeros.

0x39 commands are "change brightness for a particular LED channel" commands :-)
Byte 2 is the brightness where
0x00 => 0%
0x21 => 33%
0x42 => 66%
0x64 => 100%
Values other than these are not possible to set in the official Corsair LINK GUI.
The response is all zeros.

0x3B commands seems to only get transmitted after a change of LED Channel mode,
such as a change from "RGB LED Strip" to "RGB HD Fan". Usually, it is like this:
Byte 1 is the LED channel number
0x00 => "LED channel #1"
0x01 => "LED channel #2"
Byte 2 is usually 0x01. Changing from "RGB LL Fan" to "RBG SP Fan" it was 0x02 instead. Research is needed.
The rest of the bytes are zero.
The response is all zeros.

Notes

If a fan is configured as "Auto" or "Disconnected", status (RPM) are not requested for the particular fan.
If a fan is configured as "Auto", the fan is turned on at some speed, possible the mode and settings is what is currently saved in the Commander PRO device itself and can be changed with the "Configure Fan" dialog.
If a fan is configured as "Disconnected", the fan is turned off.
If a 3-pin fan is connected and the fan is configured as 4-pin, the RPM count is returned as 0x0000 for the particular fan.
The Corsair LINK software sets fan modes for all fans when the buttons OK or Apply is pressed in the Configure dialog. In total, six 0x28 commands are transmitted.
It appears that the mode for a fan in the "Configure Fan" dialog is never requested. It is known that when the LINK software connects to the Commander, it sets these modes at startup as well as RGB LED Channel configurations.
The temperature monitor shows the temperatures rounded to 1 decimal.
When the LINK software connects to the Commander Pro, various settings are performed including setting fan configuration (Auto/Disconnected, 3- or 4-pin) so these settings must be stored in a file.
Settings and default values in the "Configure Fan" dialog:

Modes are listed in this order (shown with default values)
"Default" (graph configuration request 0x25) 20 degC, 600 rpm ; 25 degC, 600 rpm ; 29 degC, 750 rpm ; 33 degC, 1000 rpm ; 37 degC, 1250 rpm ; 40 degC, 1500 rpm
"Quiet" (graph configuration request 0x25) (same points as in "Default" mode above)
"Balanced" (graph configuration request 0x25) 20 degC, 750 rpm ; 25 degC, 1000 rpm ; 29 degC, 1250 rpm ; 33 degC, 1500 rpm ; 37 degC, 1750 rpm ; 40 degC, 2000 rpm
"Performance" (graph configuration request 0x25) 20 degC, 1000 rpm ; 25 degC, 1250 rpm ; 29 degC, 1500 rpm ; 33 degC, 1750 rpm ; 37 degC, 2000 rpm ; 40 degC, 2500 rpm
"Custom" (graph configuration request 0x25) 20 degC, 600 rpm ; 30 degC, 600 rpm ; 40 degC, 750 rpm ; 50 degC, 1000 rpm ; 60 degC, 1250 rpm ; 70 degC, 1500 rpm
"Fixed %" (percent configuration request 0x23) 40%
"Fixed rpm" (rpm configuration request 0x24) 500
"Max" (percent configuration request) (100%)
Note that the default mode seems to be "Balanced".

Additional notes for LED channel operation

The configuration of the LED channels are clearly the most complicated part of the Corsair Commander PRO. It is not totally clear what some of the commands really are doing.

In general, when the Commander Pro is connected and recognized by the official Corsair LINK software, or when settings are changed in the GUI, a sequence of commands are transmitted for each channel

If the channel is DISABLED, the following command sequence is transmitted
0x37, 0x34, 0x38
If the channel is ENABLED, the following command sequence is transmitted
0x37, 0x34, (0x39/0x3B), 0x38, X * 0x35
where X is the number of strips/fans enabled for the channel.
0x39 is only transmitted if the brightness setting have changed.
0x3B is sometimes transmitted instead of nothing or 0x39, usually when changing the type of the channel (like a change from "RGB LED Strip" to "RGB HD Fan").
I have seen 0x3B commands in other situations as well, but they seem to be rare.

Strangely, when only channel 1 is enabled, channel 2 commands are sent first.
After command sequences for both channels are transmitted, a 0x33 command is
sent as a terminator.

NOTE: In all 0x3? commands, the second byte indicates the LED channel:
Byte 1 is the LED channel number
0x00 => "LED channel #1"
0x01 => "LED channel #2"
Also note that all responses to 0x3? commands are all zeros.

It gets really weird in some LED modes. If "RGB LL Fan" is chosen,
the LINK software constantly sends 0x33 commands to the Commander Pro.
These are on the usual "0x33 0xFF 0x00 ..." form. It is speculated that this is
a way of saying "refresh all LED channels" or something.
If an animated mode, such as "Rainbow Wave" is selected, a lot of 0x32 commands
are transmitted as well.

As stated above, I have given up documenting the LED related communication since it is just too confusing, complicated and time consuming for me. I think I have documented enough to get it working in the "RGB LED Strip" and "RGB HD Fan", probably other modes as well. Other modes, such as the "RGB LL Fan" seems to work in a different way where the Commander is spammed with 0x3? commands all the time.

Sample program

I wrote a small test program in C using hidapi-libusb just to check operation.
It works :-)

// Tiny demo of Corsair Commander Pro Communication with hidapi-libusb.
//
// The program requests the firmware version, then prints out the response
// as string of hex values.
//
// Then the first fan is set to 100% speed for 5 seconds before slowing down
// to 30%. The program then exists.
//
// The code is very quick and dirty so it will most likely segfault if
// no Corsair Commander PRO is connected.
//
// Compile with gcc -I/usr/include/hidapi -lhidapi-libusb (filename.c)
// Run with ./a.out

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include "hidapi.h"

#define MAX_STR 255

int main(int argc, char* argv[])
{
	int res;
	unsigned char outbuf[63];
    unsigned char inbuf[16];

	wchar_t wstr[MAX_STR];
	hid_device *handle;

	// Open the device using the VID, PID, and optionally the Serial number.
	handle = hid_open(0x1b1c, 0x0c10, NULL);

	// Read the Manufacturer String
	res = hid_get_manufacturer_string(handle, wstr, MAX_STR);
	printf("Manufacturer String: %ls\n", wstr);

	// Read the Product String
	res = hid_get_product_string(handle, wstr, MAX_STR);
	printf("Product String: %ls\n", wstr);

	// Read the Serial Number String
	res = hid_get_serial_number_string(handle, wstr, MAX_STR);
	printf("Serial Number String: %ls", wstr);
	printf("\n");

    // Clear the outbuf array
    int i = 0;
    for (; i < 63; ++i)
        outbuf[i] = 0x00;

    // Construct a command
    outbuf[0] = 0x02;   // Get firmware version
    
    // Write 63 bytes, then read 16 bytes.
    res = hid_write(handle, outbuf, 63);
    res = hid_read(handle, inbuf, 16);

    // Print result
    for (i = 0; i < 16; ++i)
        printf("%x ", inbuf[i]);
    printf("\n");

    outbuf[0] = 0x23;   // Set fan to fixed %
    outbuf[1] = 0x00;   // Select fan number 1
    outbuf[2] = 0x64;   // Set speed to 100%
    res = hid_write(handle, outbuf, 63);
    res = hid_read(handle, inbuf, 16);

    sleep(5);

    outbuf[0] = 0x23;   // Set fan to fixed %
    outbuf[1] = 0x00;   // Select fan number 1
    outbuf[2] = 0x1E;   // Set speed to 30%
    res = hid_write(handle, outbuf, 63);
    res = hid_read(handle, inbuf, 16);

    return 0;
}

Sean Nelson · Answer 1 · Tue Jan 16 2018 09:14:35 GMT+0800 (China Standard Time)

Nice! I was planning on reverse engineering the Pro protocol, but been really busy.

PostalBlab · Answer 2 · Tue Apr 10 2018 23:05:15 GMT+0800 (China Standard Time)

Here are all available pro commands, hope it helps:
ReadStatus = 0x01;
ReadFirmwareVersion = 0x02;
ReadDeviceId = 0x03;
WriteDeviceId = 0x04;
StartFirmwareUpdate = 0x05;
ReadBootloaderVersion = 0x06;
WriteTestFlag = 0x07;

ReadTemperatureMask = 0x10;
ReadTemperatureValue = 0x11;
ReadVoltageValue = 0x12;

ReadFanMask = 0x20;
ReadFanSpeed = 0x21;
ReadFanPower = 0x22;
WriteFanPower = 0x23;
WriteFanSpeed = 0x24;
WriteFanCurve = 0x25;
WriteFanExternalTemp = 0x26;
WriteFanForceThreePinMode = 0x27;
WriteFanDetectionType = 0x28;
ReadFanDetectionType = 0x29;

ReadLedStripMask = 0x30;
WriteLedRgbValue = 0x31;
WriteLedColorValues = 0x32;
WriteLedTrigger = 0x33;
WriteLedClear = 0x34;
WriteLedGroupSet = 0x35;
WriteLedExternalTemp = 0x36;
WriteLedGroupsClear = 0x37;
WriteLedMode = 0x38;
WriteLedBrightness = 0x39;
WriteLedCount = 0x3a;
WriteLedPortType = 0x3b;

Sean Nelson · Answer 3 · Wed Apr 11 2018 02:20:39 GMT+0800 (China Standard Time)

The only barrier I see, is changing the Driver API to accommodate the expanded RGB system in CL.

pvh1987 · Answer 4 · Wed Apr 11 2018 03:41:06 GMT+0800 (China Standard Time)

I have worked on reverse engineering the RGB stuff as well... but this is where the Commander Pro gets complicated. In some of the RGB modes (certain types of fan/strip lighting) there seem to be quite heavy USB transmissions all the time. Maybe some of the fans or strips are "dumb" and thus the official Corsair LINK software transmits "change color and brigtness to " to the Commander Pro constantly. So I gave up on this... also terribly inefficient to waste CPU cycles and USB packets just to change colors.

So I only reverse engineered the "easy" RGB modes, where commands are only transmitted once during setup and then only when settings are actually changed by the user - the fan/strip handles the animation itself in this case.

I don't use RGB myself, so I think fan control, temperature measurement etc. is much more important and I could live without RGB support entirely. I think it is nice to have rather than need to have... but of course, this is my personal opinion. Always nice to have full support, but I hope the fans and sensors are first on the list, regarding the Commander Pro :-)

PostalBlab · Answer 5 · Wed Apr 11 2018 04:30:20 GMT+0800 (China Standard Time)

@pvh1987 is it possible to get in contact with you in private, so i can send you more information about the pro protocol?

Sean Nelson · Answer 6 · Wed Apr 11 2018 21:52:41 GMT+0800 (China Standard Time)

~~I think the H115i Pro and Commander Pro use the same protocol.... We should be able to expand the current support for both.~~

The commands are different between the devices....

Leon Kiefer · Answer 7 · Thu May 23 2019 04:44:03 GMT+0800 (China Standard Time)

@PostalBlab do you want to share some more information about the commands?
#70 (comment) these were already very helpful to build an arduino library, but there are two command which I have yet seen and do not know exactly what they are doing:

WriteLedRgbValue 0x31
WriteLedCount 0x3a

PostalBlab · Answer 8 · Sat Jun 01 2019 18:41:13 GMT+0800 (China Standard Time)

Sorry but i don't have more informations about these commands. Take a look at protocol/commanderpro/led.c , there are more infos then i have.

Sean Nelson · Answer 9 · Sun Jun 23 2019 06:15:44 GMT+0800 (China Standard Time)

@pvh1987 Again, thanks for documenting the Commander Pro. I had to reverse engineer command 0x29 (using SIV) and figured out the command format.

0x29 commands are fan get mode configuration commands. The request is of the form:
0x29 0x01 n (the rest of the bytes are zero)
where
'n' is the fan number (0-5 for fan 1-6)
The response is:
0x00 0x02 n
where
0x02 is the response size
'n' is the fan number (0-5 for fan 1-6)

Sean Nelson · Answer 10 · Sun Jun 23 2019 06:17:59 GMT+0800 (China Standard Time)

@PostalBlab If you could, please post any other information you may have.

Leon Kiefer · Answer 11 · Sun Jun 23 2019 16:02:01 GMT+0800 (China Standard Time)

@audiohacked I have have a working implementation of the Commander Pro as an Arduino library:

Tim Loderhose · Answer 12 · Sat Nov 16 2019 21:15:00 GMT+0800 (China Standard Time)

Hi everyone,
I have a setup with the H100i GT V2 and the Commander PRO.
I would like to turn all LEDs off.
Is this possible, if so, what command does it? I have tried the usage instructions, but keep getting Unsupported Generic LED Function.
Thanks!