NZXT NZXT RGB Controller

[ghost]

Device type

Fan RGB Controller

Product page

https://nzxt.com/product/f140-rgb-duo

First-party software

NZXT CAM

What monitoring functionality does the device support?

No response

What configuration functionality does the device support?

lighting of embedded LEDs, lighting of accessories like RGB fans or LED strips

Physical connection

USB Header

Connection protocol

No response

Additional information about the device

No response

Can you help with implementing or testing the changes needed for liquidctl to support this device?

testing changes on Linux

[ghost]

[jonasmalacofilho]

I think you included the wrong URL.

Also, can you mention whether this 1e71:2012 variant has 2 or 6 lighting channels?

[ghost]

This is the only link which has the particular controller as part of the package. I couldn't find it as a separate unit.

Mine has 3 channels, but only for RGB. It doesn't have the Fan control channel like the 6 channel one does

[ghost]

Attaching a link to the product with the packaged controller

https://nzxt.com/product/f140-rgb-twin-pack

[jonasmalacofilho]

Thanks for the explanation.

---

You could try modifying the SmartDevice2 class/driver so that it binds to your device, and seeing if that works.

[ghost]

Have never looked at the liquidctl code. What would be the easiest way to try and do this?

[jonasmalacofilho]

There are a couple of levels of indirection, but the gist of it is that SmartDevice2 will use _MATCHES as a table of devices to bind to.

After that you'll need to check and test every method (including the ones that shouldn't be supported by that device, like set_fixed_speed/set_speed_profile).

[maxawake]

I added the USB ID to the _MATCHES list. I am able to get liquidctl to recognize the controller and even get a status. However the resulting values make no sense

NZXT RGB Controller
├── Fan 2 speed            49155  rpm
├── Fan 2 voltage         133.03  V
├── Fan 2 current         172.23  A
├── Fan 2 control mode       PWM
└── Noise level

especially since the controller should only control the RGB lighting of the fans and not the fan speed, as the smart device can. This is done by the CPU cooler itself.
Trying to set the LED with

liquidctl --match RGB set led color fixed 00ffff

results in

ERROR: NZXT RGB Controller: operation not supported by the device

[jonasmalacofilho]

What values did you use for speed_channel_count and color_channel_count?

[maxawake]

I used speed_channel_count=0 and color_channel_count=3.

However, after looking at the USB traffic between the windows driver and the controller, i could infer that the protocol of the new NZXT NZXT RGB controller is slightly different than the protocol of the Smart Devices.

For example, the byte string sent by the host to set the first fan to all white is

2a 04 01 01 00 32 00 ff ff ff 00 00 00 00 00 00   *....2..........
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................
00 00 00 00 00 00 00 00 01 00 08 03 00 00 00 00   ................

I have noted all the USB packages of every change in the driver and already programmed a simple pyUSB driver which is able to control the device. However I can not see a straightforward way to include it into the smart_device.py classes. Maybe i am blind but wouldn't it be more reasonable to create a new class/file in this case? The driver implements basically the same color modes, but with other codes, so the tables have to be altered anyways.

I have some free time in which i could do the integration of my driver into liquidctl, but as i am not a real expert in driver development i might need some guidance. Do you agree that creating a new class and inheriting from the UsbHidDriver class in this case is a good idea or should it be possible to include the device into the smart devices class?

Also i have not looked into reading firmware version or other information from the device, just plain control over the lighting

[jonasmalacofilho]

Do you agree that creating a new class and inheriting from the UsbHidDriver class in this case is a good idea or should it be possible to include the device into the smart devices class?

A new class is the better approach, based on your description. But it should probably still live in the smart_device module, based on how it's still is a variant of NXZT "smart devices", that is, RGB and/or fan controllers.

Also i have not looked into reading firmware version or other information from the device, just plain control over the lighting

Reading the firmware version is very useful when debugging issues down the line, since some of them might be related to changes in the firmware. And reading the LED accessory types and counts is sometimes useful to users.

Beyond that I don't think/expect there to be anything of interest, but check if CAM reports any other, useful, information.

[jonasmalacofilho]

I just noticed that this issue and #550 both refer to the same device.

[maxawake]

I already forked liquidctl and integrated most of the functionality here. I still need to add a couple of options like controlling individual LEDs but in principle the PR can be done soon.

Further i have only the version with F140 RGB Core fans and can thus only read out its ID. I just assume that the ID of the F120 Fans are one increment below the ID of the F140 but i can't tell for sure. If someone owns the version with F120 fans it would be great if this person could check the ID and share it here.

[jonasmalacofilho]

Great, thanks!

[frans-slabbekoorn]

@maxawake when running lsusb with F120 version fans, I get the following:
Bus 001 Device 005: ID 1e71:2012 NZXT NZXT RGB Controller
If you need more information regarding the F120 version controller, let me know!

[mthier]

I have another RGB Controller for the LED fans of my AIO Kraken 240 RGB with a different ID ID 1e71:2021 NZXT NZXT RGB Controller. I have extended the implementation of @maxawake and add my device to it. Maybe someone have the same RGB Controller. The code is available on my fork.

[maxawake]

@frans-slabbekoorn Could you maybe print the accessory_id and tell me what it is? You can do that in my fork e.g. in this function

def parse_led_info(msg):
    channel_count = msg[14]
        offset = 15  # offset of first channel/first accessory
        for c in range(channel_count):
            for a in range(HUE2_MAX_ACCESSORIES_IN_CHANNEL):
                accessory_id = msg[offset + c * HUE2_MAX_ACCESSORIES_IN_CHANNEL + a]
                if accessory_id == 0:
                    break
                print(accessory_id) # ADD THIS LINE
                ret.append((f'LED {c + 1} accessory {a + 1}', Hue2Accessory(accessory_id), ''))

This way i could check if the F120 has a different id. Btw, is your fan a core or a frame version?