Add support for nzxt krakens 2023

[brokenmass]

Adds support for new NZXT Kraken AIOs (2023 standard and elite). Protocol is pretty much identical to krakenZ with following differences:

• max bulk size write buffer is 2MB
• new devices do not have color channels
• new devices have different resolutions than kraken Z ( 640x60 for kraken elite, 240x240 for kraken standard)
• when setting fan speed byte 3 and 4 must be 0x1 0x1 instead of 0x0 0x0
• when setting pump speed byte 3 and 4 must be 0x1 0x0 instead of 0x0 0x0 (but even 0x0 0x0) works

Closes: #596

---

Checklist:

• Adhere to the development process
• Conform to the style guide
• Verify that the changes work as expected on real hardware
• Add automated tests cases
• Verify that all (other) automated tests (still) pass
• Update/add documentation
  • README, with "new/changed in" notes
  • applicable docs/*guide.md device guides, with "new/changed in" notes
  • liquidctl.8 Linux/Unix/Mac OS man page
  • protocol documentation in docs/developer/protocol
• Submit relevant data, scripts or dissectors to https://github.com/liquidctl/collected-device-data

New device?

• Regenerate extra/linux/71-liquidctl.rules (instructions in the file header)
• Add entry to the README's supported device list with applicable notes (at least e) and git MRLV

[brokenmass]

pushed a fix to allow to correctly set fan speed on kraken 2023

[maxawake]

When I try to set the same GIF on the lcd screen two times i always get this error

[DEBUG] (cli) (main): device: NZXT Kraken 2023 Elite
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 01: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:01:bb:8c:90:82:0e:58:0a:31:00:00:00:00:05:00:80:00:00:10:80:02:80:02:64:01:03:ff: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
[DEBUG] (usb) (write): writing report 0x36 with 63 bytes: 03: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 75:02:bb:8c:90:82:0e:58:0a:31:00:00:00:00:01:1e:02:12:05:1e:1e:01:02:fc:03:32:32: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
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 37:03:bb:8c:90:82:0e:58:0a:31:00:00:00:00:01: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:01: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:00:01:02:00:00:7e:14:01:01: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:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:02: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:01: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:03: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:02: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:04: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:03: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:05: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:04: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:06: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:05: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:07: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:06: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:08: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:07: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:09: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:08: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:0a: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:09: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:0b: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:0a: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:0c: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:0b: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:0d: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:0c: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:0e: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:0d: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x30 with 63 bytes: 04:0f: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:0e: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x32 with 63 bytes: 02: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 31:04:bb:8c:90:82:0e:58:0a:31:00:00:00:00:0f: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 33:02:bb:8c:90:82:0e:58:0a:31:00:00:00:00:09: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x32 with 63 bytes: 02:01: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 33:02:bb:8c:90:82:0e:58:0a:31:00:00:00:00:01: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x32 with 63 bytes: 02:01: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 33:02:bb:8c:90:82:0e:58:0a:31:00:00:00:00:01: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:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (write): writing report 0x32 with 63 bytes: 01:01:02:00:00:7e:14:01: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:00:00:00:00:00:00:00:00:00:00:00:00:00:00:00
[DEBUG] (usb) (read): read 64 bytes: 33:01:bb:8c:90:82:0e:58:0a:31:00:00:00:00:05: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:00:00:00:00:00:00:00:00:00
[ERROR] (kraken3) (_send_data): Failed to setup bucket for data transfer
[ERROR] (kraken3) (_send_data): Failed to switch active bucket

This can be solved however by setting the screen back to "liquid" mode and then setting to gif again.

Apart from this everything works like a charm for me! Great work

[guygastineau]

@brokenmass are you still interested in working on this? I have this kraken model in the mail for a new build. I am willing to finish your work if you don't have time or interest anymore.

[john484848]

I would be really interested in helping with this is there anyway I can help

[guygastineau]

@john484848 I got my new PC together a few days ago. So far, I am pleased with the default performance of the AIO based on the cpu_fan output, and the liquid temp screen is most of what I need. I suppose it would be nice for the liquid screen to change color depending on temperature, and I wouldn't mind seeing the RPM for the fans and the pump on the display. This should be motivation enough for me to try this branch out this weekend.

Once, I have it doing something useful on my machine, I'll chime back in here and start working on clearing out the rest of the check boxes. Are there any outstanding TODOs that you feel confident tackling?

[john484848]

I have had mine for a little while and when i was compiling wine i saw my 13900k spike to 80 degrees celsius and wondered if potentially the cooler not functioning properly could be to blame

[john484848]

I am sorry if I seem stupid on this one but i wasn't sure if that was expected

[john484848]

I will try to tackle some of the documentation stuff

[guygastineau]

@john484848 80°C is pretty hot. It is probably within the operating spec for your chip though. I'm curious, what was the liquid temperature displayed on your kraken when you hit those temps?

Also, Im sure, with liquidctl you should be able to program a better curve for tackling those high temps if you don't mind a little extra noise.

Yes, documentation work would be appreciated. It is my least favorite part of programming, lol. It seems like it is mostly what is left to do though.

---

We'll probably need to fetch this branch and rebase it on main, since it has conflicts. I need to read the contributor docs to see if that is acceptable. We also need to figure out why that one file is binary now instead of being recognized as UTF-8 encoded text. I'll probably try to fix that before rebasing.

We could then try to make PRs to the branch @brokenmass is using for this PR. If they are unresponsive, then one of us will have to make a new PR, and the other will have to make PRs to that in order to get them into the PR for the original liquidctl (unless there is a new workaround for non-maintainers to add commits to a PR). I don't mind either way. I don't know your level of comfort with git. I am very comfortable with it, so I don't mind managing all this jumping around. If you make docs PRs to the branch I'll make on my fork, then you will still get credit for your commits when the PR gets merged into the main branch.

[john484848]

Ok yeah will try to get the documentation done today

[john484848]

I think the liquid temp was in the 30s

[john484848]

I know that the 13900k is supposed to go up to 100 degrees so i think the chip will be ok i also have intel's thermald to help keep temps more under control

[john484848]

Also how do i get write access so i can contribute

[guygastineau]

Also how do i get write access so i can contribute

It'll have to be through PRs. I am finally making time for this today. I'll send you a link to my branch when I have it set up and tested locally. If you make PRs to that, then your commits will show up here when the work is merged. I'll mess with it a bit, and then I'll make a new PR here with a WIP status, so it is easier to track what's happening.

[guygastineau]

I ran into a few issues with this branch last night. I was able to change brightness reliably, but beyond that things were quite wonky.

1. I couldn't change orientation after initialization. Later I managed to change orientation by using the commands without ever running the initialization command.
2. It failed to find bulk_out. This one was weird. I think it is a bug in PyUsb. Basically, the serial number that is retrieved during enumeration of the USB devices had three trailing null bytes in the string. I altered the loop to strip the trailing null bytes during comparison, and it got past that.
3. Once liquictl could find the bulk output device, I tried to send an image to the screen. Momentarily, an image appeared in glorious detail. Within 2 seconds, the lcd went black, and trying to set it back to liquid did nothing (sending a new image also did nothing.
4. Thankfully, the pump and fan settings didn't change through this strange behavior.

After getting my screen stuck blank, I tried rebooting. It was still blank, so I fully powered off. After rebooting, I was greeted by the familiar liquid screen, but it's orientation had been changed (weird). I tried changing orientation (after initialization), and it still didn't work. I powered off again, and then tried orientation changes before initializing, and then orientation changes worked. This felt like weird behavior, and I was a little worried from the whole experience, so I powered down again, observed the changes (orientation restoration) were persistent. Then I didn't mess with liquidctl anymore. I felt like playing games the rest of the evening instead of fearing bricking my AIO.

---

I am willing to work through these hurdles in order to get this AIO supported, but it will take longer.

1. I wonder if anyone else has ever experienced the same weird behavior for usb serial number strings through PyUsb. I searched about it, but I just found some people having utf8 encoding problems. This seems like some weird problem where they are taking too much of a cstring and getting some null padding from the c side.
2. I am not so familiar with the protocols for AIO and RGB peripherals. I assume people figure this stuff out by snooping on connections betwee4n CAM and the AIO. I am using linux, so I don't think I can run CAM; I am not sure how to reverse engineer if I can't observe such traffic. I don't mind binary protocols. I implement them for some embedded projects, but I usually have a datasheet to follow. I assume NZXT doesn't give us a data sheet with the comms protocol laid out (the most wishful thinking, lol).

---

Maybe I just missed something while messing with it, but I read the relevant sections of the manpage for my purposes as well as a decent amount of source code to get as far as I did. Given my experience, I am skeptical that the difference in protocol between my kraken 3 elite and the z series is so trivial. I would greatly appreciate any advice from people more experienced in this space, as I would like to pick up this work.

PS. I did all of this straight from this PR's branch. I will rebase it on main to see if that fixes anything. I don't think it will, since the same PyUsb package will be used, and I think there is something wrong in the protocol alterations in this PR. It's worth trying though anyway.

[aleksamagicka]

I am using linux, so I don't think I can run CAM

That's right, in that case you can download a Windows VM and passthrough the device, then monitor the traffic. We're in (semi) uncharted waters for every new model/device.

I am not sure how to reverse engineer if I can't observe such traffic

It can indeed be futile unless someone captures the traffic and jotts down settings. But even that can get you so far.

I assume NZXT doesn't give us a data sheet with the comms protocol laid out

They don't. Neither do other manufacturers, that I know of. There was some movement in that direction with OpenRGB, but that's not very relevant right now.

[jensmeindertsma]

What could I do to help test this on my 2023 Kraken 240 black? Dual-booting windows and linux, how could I observe traffic from CAM when running in Windows?

Will this support the CPU-temperature graphics that CAM offers? Not sure if those are generated by CAM as images or by a pump logic board

[guygastineau]

@aleksamagicka thank you for clarifying. Unfortunately, installing Windows VMs is very far from a priority for me :/ I can try to find the time and motivation, but it will definitely impede my progress.

@jensmeindertsma at this point we don't know if those are on-board or generated by CAM. My bet would be generated by CAM. I have been planning to make a tool for generating stats based images for use with the display, so if it turns out we don't get them for free, I will point you to that project when finished. I am not familiar enough with Windows to know how to capture the traffic, but surely some other kind soul here has the proper tips. Since you are already dual-booting, I would be incredibly grateful if you are willing to capture that traffic and drop the dumps with context here!

[aleksamagicka]

installing Windows VMs is very far from a priority for me :/

Understandable, just know that the ones I linked are premade - they boot straight into Windows.

I am not familiar enough with Windows to know how to capture the traffic, but surely some other kind soul here has the proper tips.

There are great writeups for creating a VM and capturing USB traffic on both platforms in this repo. Boils down to Wireshark.

[jensmeindertsma]

I'm still considering my purchase of the NZXT Kraken over a Arctic Freezer because of the hassle with CAM. I like it's aesthetic better so maybe I'll get NZXt anyway.

IMO it's a bad thing that AIO manufacturers have decided to go with the USB controlling approach over regular BIOS control via PWM headers. If it were for lack of power they could read the speed signal from the header and just use the SATA for power.

A side question that I'm wondering about: do the Kraken's have a "default" mode they operate under when started without CAM? Surely they can't not run at all, right?

[brokenmass]

A side question that I'm wondering about: do the Kraken's have a "default" mode they operate under when started without CAM? Surely they can't not run at all, right?

default is silent mode (pump at 30% fixed speed)

[jensmeindertsma]

A side question that I'm wondering about: do the Kraken's have a "default" mode they operate under when started without CAM? Surely they can't not run at all, right?

default is silent mode (pump at 30% fixed speed)

damn okay, so if you push some workload on linux it will give you a hard time :sweat?

[aleksamagicka]

They do have a default state:

IMO it's a bad thing that AIO manufacturers have decided to go with the USB controlling approach over regular BIOS control via PWM headers

They need USB for firmware, LEDs, display and (perceived) fancy software. Not having fan control clumped in there as well would make it look self-inflicted IMO, and probably introduce more cables.

[brokenmass]

What could I do to help test this on my 2023 Kraken 240 black? Dual-booting windows and linux, how could I observe traffic from CAM when running in Windows?

Will this support the CPU-temperature graphics that CAM offers? Not sure if those are generated by CAM as images or by a pump logic board

non elite version of kraken 2023 are a bit peculiar. they only have 46kb memory , no bucket mode (like Z3 or 2023 elite have), and accept only gif static image (no rgb).
liquid temperature mode does not work autonomously on this model as the tempaerature graph( that is nothign else than a static gif image) is constantly rendered and sent by cam every x ms.

said so you can write a program in python that generates the gif and sends it to the pump and is not that hard to code. Obviously you need some datasource to read temperature/cpu usage/etc data from (look at this other project of mine for reference: https://github.com/brokenmass/AIOLCDUnchained)

[matooch]

Nice! That worked. Thank you

[brokenmass]

@brokenmass, thanks!

The code changes look good to me. Can you fix the test case and complete the PR checklist?

Thanks again for working on this!

@aleksamagicka,

Can you check again that all is still well with the latest version of these changes and an older Kraken Z?

Tests are now fixed and checklist should be completed

[aleksamagicka]

My thoughts:

• The docs should mention explicit support for the 2023 models.
• Same goes for the header docstring.

[jonasmalacofilho]

Most of the previously failing test was left commented out. And I spotted a few minor/documentation things.

Also, in addition to Aleksa's comments, two items of the checklist were mistakenly checked off.

First, the guide document for this family should include "New in git: [...]" notes highlighting that support for these new devices was added (see development process document).

(When preparing a release, these notes are changed to the reference the appropriate version, helping users and even ourselves quickly identify obvious "not actually supported by the currently running version" bugs).

Second, the liquidctl.8 man page should list the new devices.

---

For history reasons, documentation on the protocol and traffic captures for this family of devices can be left out. (But, if you have the time, it's still a good thing to include and preserve whatever information/notes you have).

[brokenmass]

@jonasmalacofilho pushed a new commit with required documentation improvements. let me know if anything is missing or need modifications.

[brokenmass]

@jonasmalacofilho @aleksamagicka anything outstanding ?

[aleksamagicka]

Just note the models in the driver docstring.

Thanks for the detailed protocol docs, BTW!

[aniongithub]

@brokenmass Thanks SO MUCH for this PR, I was able to clone your repo and test out a few commands on my Kraken 360.

What works:

• Brightness
• Rotation
• RGB
• liquid mode

What doesn't work

• GIF/Static images - this fails with the error
  ERROR: NZXT Kraken 2023 (experimental): unexpected error: AssertionError('missing messages (attempts=12, missing=1)')

Here is the call-stack

_read_until_first_match (/workspaces/liquidctl-kraken/liquidctl/driver/kraken3.py:730)
_delete_bucket (/workspaces/liquidctl-kraken/liquidctl/driver/kraken3.py:1035)
_prepare_bucket (/workspaces/liquidctl-kraken/liquidctl/driver/kraken3.py:1018)
_send_data (/workspaces/liquidctl-kraken/liquidctl/driver/kraken3.py:879)
set_screen (/workspaces/liquidctl-kraken/liquidctl/driver/kraken3.py:794)
_device_set_screen (/workspaces/liquidctl-kraken/liquidctl/cli.py:287)
main (/workspaces/liquidctl-kraken/liquidctl/cli.py:479)
<module> (/workspaces/liquidctl-kraken/liquidctl/cli.py:509)

[brokenmass]

Just note the models in the driver docstring.

@aleksamagicka sorry, what does this mean exactly ?

[brokenmass]

@aniongithub

What doesn't work

• GIF/Static images - this fails with the error
  ERROR: NZXT Kraken 2023 (experimental): unexpected error: AssertionError('missing messages (attempts=12, missing=1)')

thanks for reporting. I know what's the issue:

Kraken 2023 non elite only has a small 46kb memory and only accept static image encoded as gif (not RGBA).
On windows cam app sends animated gifs one frame at a time but liquidctl cannot obviously do that.

I might be able to at least send a static image but i need some support from someone with the device. Said so i think it would be better to do this change in a follow-up PR as the core functionality of pump and fan control works well

[aleksamagicka]

Just note the models in the driver docstring.

@aleksamagicka sorry, what does this mean exactly ?

Sorry for being unclear; I meant noting them here.

[aniongithub]

@aniongithub

What doesn't work

• GIF/Static images - this fails with the error
  ERROR: NZXT Kraken 2023 (experimental): unexpected error: AssertionError('missing messages (attempts=12, missing=1)')

thanks for reporting. I know what's the issue:

Kraken 2023 non elite only has a small 46kb memory and only accept static image encoded as gif (not RGBA). On windows cam app sends animated gifs one frame at a time but liquidctl cannot obviously do that.

I might be able to at least send a static image but i need some support from someone with the device. Said so i think it would be better to do this change in a follow-up PR as the core functionality of pump and fan control works well

Thanks for the reply! I have this device and I'm glad to help. If you could enable issues/discussion on your fork, we can continue this discussion there. Any development could also be a different branch, created from brokenmass/liquidctl/tree/nzxt-kraken-elite. Also, it doesn't seem to be a just a memory issue - with some more debugging, I've figured out that even this line self._read_until({b'u\x02': parse_lcd_info}) fails, with the prefix b'u\x02' being returned (not b"\x31\x01" as is passed in).

As for the gif issue, I do plan to take out some of this code and possibly write an installable service that can apply animated GIFs (and possibly even other stats by rendering them to a static image and applying them over some update interval) to the Kraken 360. If you could help me with applying a single static image, I can take this further from there.

Again, thanks so much for putting all this together, I bought this AIO months ago and was losing hope I'd ever be able to use it properly in my build.

[brokenmass]

@aniongithub you can look at this other project of mine https://github.com/brokenmass/AIOLCDUnchained that sends data continuously to the lcd (works with all krakens with an lcd) (https://youtu.be/-EUDxjzwlcg?si=FSxXDDkC5Y2P2k5t)

what’s using is a fast writing mode (so no need to create and write a memory bucket) that’s also supported in kraken elite but with smaller memory for non elite (and elite now support different image format)

[aniongithub]

@aniongithub you can look at this other project of mine https://github.com/brokenmass/AIOLCDUnchained that sends data continuously to the lcd (works with all krakens with an lcd) (https://youtu.be/-EUDxjzwlcg?si=FSxXDDkC5Y2P2k5t)

what’s using is a fast writing mode (so no need to create and write a memory bucket) that’s also supported in kraken elite but with smaller memory for non elite (and elite now support different image format)

Thank you! I'll give that a shot and report back on that issues thread if I run into any trouble.

[sossw]

The Kraken 2023 (non elite, non rgb) has had a firmware update (2.0.1 as reported by CAM) . (I think the previous version was 1.2 if I remember correctly.) CAM automatically upgraded itself without asking, so there was no choice.

Since then, setting an image using liquidctl on linux has given this error:
[ERROR] (cli) (log): NZXT Kraken 2023: unexpected error: AssertionError('missing messages (attempts=12, missing=1)')

All other functions of liquidctl seem to be unaffected.

[aniongithub]

@sossw - see my comment on this thread, I believe I ran into the same issue with both this PR and the AIOLCDUnchained project by @brokenmass.

I believe the protocol has changed (I didn't realize my AIO updated itself) and we may need to take that into account before this PR would work for the updated devices.

Note that my non-elite, RGB version has also updated itself and gives me the same error, which makes me think this applies to a broader group of NZXT AIOs.

[jonasmalacofilho]

Merged as is. It will be easier to work on fixing the new issues with firmware 2.0.1 on a separate PR.

And thanks to everyone that got involved here!