Add support for ICUE LINK System Hub

[walkerp07]

Device type

System Hub

Product page

https://www.corsair.com/us/en/p/pc-components-accessories/cl-9011116-ww/icue-link-system-hub-cl-9011116-ww

First-party software

Corsair ICUE

What monitoring functionality does the device support?

temperatures, fan/pump speeds or duty cycles

What configuration functionality does the device support?

fan/pump speeds or duty cycles, lighting of accessories like RGB fans or LED strips

Physical connection

USB Header

Connection protocol

USB

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

[walkerp07]

I believe this device is fairly new but most of my RGB fans are connected to it. The benefits of using a system hub is you can reduce the number of cables needed for each fan when compared to a commander pro for instance. And since this device controls most of my fans, it’s vital to get Linux support. I have an extra system hub laying around so if you need one let me know and I would be happy to test any solutions you come up with.

[methylDragon]

+1

[forrest-h]

+1

[jurkovic-nikola]

I was tinkering around with this project and the actual LINK System Hub device.
A couple of things regarding LINK System Hub:

• Most of the commands and opcodes are similar to other Corsair hubs, a couple of them got changed and a couple of channels got changed.
• This device operates in 2 different modes, one is default hardware mode, and the second one is software mode which is activated via commands.
• The device requires constant USB traffic to remain in software mode, if no communication is made in the range of 10 seconds, the device switches back to default hardware mode, causing lights and speeds to reset
• Packet headers moved to 512 bytes from 64 or 96. Probably due to amount of devices you can connect to it.

I've built a small Go application that runs as a daemon and controls this device, from temperature control, fan curve, and simple RGB per channel.

I've started porting this code into Python, but I've hit a dead end because when the Python process quits, the device goes back to default hardware mode, since it requires constant communication and data pulling.

Example of device pulling and their data via python.
[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=13, device_type=1, device_id='0100136032035898E900007609', name='QX Fan', rpm=825, temperature=23.1, led_channels=34, contains_pump=False)

[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=14, device_type=7, device_id='0292D70F00AEA4610336A80000', name='H150i', rpm=1852, temperature=21.2, led_channels=20, contains_pump=True)

[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=15, device_type=1, device_id='0100282F8203582BFB00018643', name='QX Fan', rpm=811, temperature=23.4, led_channels=34, contains_pump=False)

[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=16, device_type=1, device_id='0100136032035898E90000555B', name='QX Fan', rpm=814, temperature=23.5, led_channels=34, contains_pump=False)

Any thoughts? I've gone through most of the project files and didn't find any reference about running it as a daemon process constantly.

Best,
Nikola

[keis]

I was poking around at this myself but didn't get very far. Do you have that python code published somewhere @jurkovic-nikola ?

I found some examples of creating a daemon in the extras that use liquidctl as library https://github.com/liquidctl/liquidctl/blob/058a26ba956c2994e2c33b3d5583137dfd80bd0c/extra/yoda.py

I'm not sure if that's a good pattern to follow though, hopefully one of the maintainers can chime in on that

[jurkovic-nikola]

@keis This should help you to burst the bubble, https://gist.github.com/jurkovic-nikola/45790cfc2f615d32670bc95b029bdd8e

$ python3.10 -m liquidctl --serial 5C126A3EB51A39569ABADC4C3A1FCF54 initialize --debug

[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=13, device_type=1, device_id='0100136032035898E900007609', name='QX Fan', rpm=480, temperature=25.9, led_channels=34, contains_pump=False)

[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=14, device_type=1, device_id='0100282F8203582BFB00018643', name='QX Fan', rpm=482, temperature=25.7, led_channels=34, contains_pump=False)

[DEBUG] (corsair_link_systen_hub) (init_devices): Device initialized. Device: LinkDevice(channel_id=15, device_type=1, device_id='0100136032035898E90000555B', name='QX Fan', rpm=483, temperature=25.7, led_channels=34, contains_pump=False)

Corsair iCUE LINK System Hub
├── Firmware version 2.4.438
├── Device QX Fan - 480 RPM - 25.9 C
├── Device QX Fan - 482 RPM - 25.7 C
└── Device QX Fan - 483 RPM - 25.7 C

Let's wait for maintainers and their opinion about this since this is completely a new device that controls everything related to LINK devices.

[keis]

Thanks, I can confirm I'm able to list the fans and aio connected to the link hub with that

[jurkovic-nikola]

@keis this will set your devices to white color and initialize default speeds: https://gist.github.com/jurkovic-nikola/4db1383c4e073d21703d0e365285e28a

You can control color brightness via _COLOR_BRIGHTNESS variable and you can operate fan speeds in 2 modes: percent and fixed RPM mode.

self.set_device_speed(devices, _DEFAULT_FAN_PERCENT, _SPEED_TYPE_PERCENT) this will set fans and pump in percent mode. Please note, pump can be controlled only via percent mode, RPM mode is not supported for pumps.

self.set_device_speed(devices, 2000, _SPEED_TYPE_RPM) this will set your fan channels to fixed 2000 RPM, but pump will be overwritten to a default pump percent mode defined in _DEFAULT_PUMP_PERCENT

You will notice that speed and light will reset after 10 seconds of Python process exiting, this is due to device needs to have constant communication with client.

This is overall basic device control, from speeds to simple RGB. All of this can be extended to support RGB mode per device, multiple RGB modes, speed control per device, etc...this is just an example for all devices in the system.

I was analyzing usb traffic for RGB modes like (watercolor, rainbow, etc...) client is constantly sending RGB color updates for a device per each LED channel on the device. Channel update is in range of 30-40 ms.

Best,
Nikola

[jonasmalacofilho]

In its current design, the liquidctl CLI is simply a configuration tool for firmware-only features, and liquidctl APIs should support more complex things to be built... by others.

(Beyond the base APIs, drivers can and sometimes do expose additional method for features that only make sense for callers other than the liquidctl CLI).

A new, daemon-based design has been discussed, but honestly there's no one to work on it right now.