Latest version of NZXT cam has broken the reporting of fan, pump speed & water temps from the USB in HWiNFO

[sgtsixpack]

The values are reported in CAM itself but HWiNFO has dropped monitoring them on the sensors panel. The pump speed is read via 2nd motherboard fan header, but fan speed and h20 temp are only reported via usb so are completely missing from HWiNFO.

I sent a bug report to CAM and this is how they responded:

"
Anthony Vega (CAM by NZXT)


Apr 10, 1:58 PM PDT


Hi there,

Our products are not designed to specifically work for HWiNFO which may be why it isn't being detected in that program.

As far as the CAM settings being reset that may have been an issue with that I believe there may have been a fix yesterday that fixed the issue with the settings being reset.


CAM by NZXT
camwebapp.com
"
The second part of his reply contains next level PR spin. How can an update that wiped my custom profiles in lighting and cooling be the same update which fixes it? To top it off they just asked me to rate their customer service.

 

[Martin]

It's possible that a new firmware version for the cooler (supplied in latest CAM) has changed the communication format.
Please attach the HWiNFO Debug File with sensor data, I will analyze it.

 

[sgtsixpack]

Yes I did update the firmware of my NZXT X72 Kraken a couple of weeks ago. I didn't realise a CAM update could update the firmware. I attach the required files. Is it safe to upload my report file including serial numbers? I edited some of the serial numbers which are still RMAable.

 

[Martin]

The problem here seems to be the presence of CAM software. Later versions block access to this device and don't allow other software to use it while CAM is running.
Try to close it and you should get the values in HWiNFO.
Unfortunately there's no workaround for this as NZXT refuses to play fair.

 

[sgtsixpack]

Got rid of CAM after that update.

GitHub - liquidctl/liquidctl: Cross-platform CLI and Python drivers for AIO liquid coolers and other devices

Cross-platform CLI and Python drivers for AIO liquid coolers and other devices - liquidctl/liquidctl

github.com

-Need to put liquidctl.exe in the system "path"
-Can put filename.bat with below commands into startup folder (or using a scheduled task but its harder to enable it vs windows 7, so I stuck with startup folder).

My batch file:
@echo
liquidctl --version
liquidctl initialize all
liquidctl -m Kraken set fan speed 24 55 25 60 26 66 27 83 28 100
liquidctl -m Kraken set pump speed 24 60 25 75 26 90 27 100 28 100
liquidctl -m Kraken set ring color fading FF2608 0B03FF F35B10 --speed faster
liquidctl -m Kraken set logo color fading F35B10 0B03FF FF2608 --speed fastest
liquidctl status
TIMEOUT 30

 

[ozzed]

Hi!
New here, first post, Hi.
I actually registered just to report my findings on this in hope that it can help someone else.

I, like others, have written to NZXT with the only response being invalid excuses for the sensor exclusivity.

Something I have found however is that sometimes when I started my computer the sensors would show up and report pump speed, fan speed, and water temp even when CAM was running (I have both HWINFO and CAM starts when windows starts), so this got me thinking... When the sensors would be grayed out in HWINFO I closed CAM, so the sensors showed up, but my profile in CAM was no longer active, so CAM needs to be running. The "solution" seems to be to just close and open CAM multiple times until the sensors can be read with CAM open. Sometimes it works on the first try, sometimes it takes 10 minutes before it works, so whatever they're using to lock the sensors to CAM seems to have a glitch that can be exploited.
I don't know what it might be, but I'm more than happy to provide whatever logs might be needed to investigate the issue further, if there's time and energy for it.
When it does work, there's no problem, CAM does it's thing, reporting temps in its clunky, non granular way, adjusting the fan-speed according to the profile I have set, and HWINFO can read and report the sensors in it's fine-grained, graceful manner without interfering,
So it's complete nonsense that CAM "needs" exclusive sensor reading to function, and it's sad that NZXT want us to think that.

Anyway, sorry for the rambling nature of the post. I'm happy to help with anything needed if anything can be done to make it work, and if not, I at least hope that my findings of a tedious workaround can help someone else in a similar situation. Cheers!

 

[Martin]

I'm afraid, there's nothing else we can do on our side. If one application claims exclusivity, the general protection mechanism doesn't allow others to override this.
Perhaps if more and more users will continue to bang NZXT, they will be forced to listen to them and reconsider their unjustified point of view.

 

[ozzed]

I'm afraid, there's nothing else we can do on our side. If one application claims exclusivity, the general protection mechanism doesn't allow others to override this.
Perhaps if more and more users will continue to bang NZXT, they will be forced to listen to them and reconsider their unjustified point of view.

I see. So it's probably a bug in the protection mechanism rather than CAM then? Bummer. Well. Hopefully the workaround can be of some help to some people. For me it's well worth spending the extra time frantically closing and opening CAM to see the sensors in HWINFO as CAM's reporting is not fine-grained enough for my needs. It's a shame because the sensors are obviously capable of it.

 

[Martin]

No, it's not a bug in the protection mechanism. It's because the CAM thinks no one else should access the cooler when it's active.

 

[ozzed]

No, it's not a bug in the protection mechanism. It's because the CAM thinks no one else should access the cooler when it's active.

I was referring to the fact that it's possible to keep the sensors reporting to HWINFO by repeatedly closing and opening CAM until CAM opens and the sensors don't get grayed out in HWINFO.

For NZXT, the desired behavior is that if CAM is open, no other application can access the sensors, in HWINFO, this translates to the sensors becoming grayed out and not reporting new values.

What I found is that this can be circumvented by repeatedly closing and opening CAM, and sometimes the sensors will keep reporting to HWINFO even when CAM is opened and running. It's that specific chain of events that I was curious to know if there's a way to trigger other than closing and opening cam, repeatedly until it decides to happen.

Steps to reproduce:
1;: Have CAM and HWINFO running simultaneously
2: take note of the fact that the senors for Kraken are greyed out in HWINFO (because CAM has claimed exclusive access to the sensors)
3: Close CAM
4: Take note of the fact that the Kraken-sensors are now reporting correctly in HWINFO again
5: Open CAM again.
6: Check the Kraken-sensors in HWINFO
7a: if the sensors once again are grayed out, close CAM, repeat step 5 AND 6
7b: if the sensors are still reporTING IN HWINFO, even though CAM is open, you have successfully circumvented the exclusivity lock.

It's the mechanism above I'm curious about. What causes CAM to sometimes fail in claiming exclusivity to the sensors, and is there and easier way to circumvent it than the one I have found?

Sorry for being blurry in my earlier posts.

 

[Martin]

I'm really not sure how exactly CAM has this implemented.
I can only speculate that if it fails to claim exclusive access, it will somehow fall-back to accept the non-exclusive one.

 

[ozzed]

I'm really not sure how exactly CAM has this implemented.
I can only speculate that if it fails to claim exclusive access, it will somehow fall-back to accept the non-exclusive one.

I think I might have made a useful discovery. I got to thinking that maybe CAM can't claim exclusivity if another application is actively polling the sensors for values, so I set the global polling period to 50ms in HWINFO, and then did a bunch of opening and closing CAM, and now it happens far more often that both CAM and HWINFO can access the sensors simultaneously. Sometimes HWINFO still gets locked out, but not nearly as often as when the polling rate is 2000ms, so it seems that if HWINFO polls the sensor when CAM tries to claim exclusivity, it fails to do so and falls back on the non-exclusive mode that lets both HWINFO and CAM access the sensors.

I'm not sure if that information can be of any help as far as HWINFO's approach is concerned, and I realize that this is an edge case. But maybe you can use the info for a specific setting or something that would help circumvent the issue?

Like I said the issue doesn't go away with an insanely high poll rate, but it reduces the time that needs to be spent closing and opening cam to get it to work.

And no, I do not recommend that users affected by this set a poll rate of 50ms and keep it that way, such a high poll rate could hurt performance especially of the CPU since it wakes up when polled. So... If nothing can be done in HWINFO, this is my workaround:

1: Set global polling period in HWINFO to 50ms
2: Close CAM
3: Open CAM
4: if the sensors are still grayed out, in HWINFO repeat 3 (hopefully fewer times are needed than with a longer polling period)
5: If the sensors report correctly in HWINFO after CAM is opened, set the polling period back to whatever it was before (default is 2000ms).
All set!

Sadly this would have to be repeated every time HWINFO can't read the sensors, but at least it works, and reducing the polling period temporarily reduces the time it takes before it works, or rather the likelihood of it working, as the more often the senor is polled, the more likely it is that CAM can't claim exclusivity due to the sensor being polled at that moment by HWINFO,

 

[Martin]

This is an interesting observation and I think I can explain this.
HWiNFO doesn't hold access to the device all the time, but only for a brief time to read values, then it releases it. This is for several reasons, i.e. older CAM versions refused to run if something else was using the device and also to handle situations like sleep/resume. And only during the time an application has access to the device open, the exclusivity (exclusive/shared) mode is applied.
Now, according to your observation, it seems the CAM first tries to claim exclusive access. If that fails, it seems to satisfy with shared access. So if you catch the brief moment when HWiNFO is accessing the device and CAM fails to get exclusive access, it continues with shared access.

 

[ozzed]

This is an interesting observation and I think I can explain this.
HWiNFO doesn't hold access to the device all the time, but only for a brief time to read values, then it releases it. This is for several reasons, i.e. older CAM versions refused to run if something else was using the device and also to handle situations like sleep/resume. And only during the time an application has access to the device open, the exclusivity (exclusive/shared) mode is applied.
Now, according to your observation, it seems the CAM first tries to claim exclusive access. If that fails, it seems to satisfy with shared access. So if you catch the brief moment when HWiNFO is accessing the device and CAM fails to get exclusive access, it continues with shared access.

Yes, that is my conclusion as well, when HWiNFO accesses the sensor, and CAM simultaneously tries to claim exclusive access, it fails to retrieve it and thus falls back on shared access. Is there a way to implement some kind of solution or at least a mitigation of the issue in a HWiNFO-setting? It's an edge-case like I said so if there's a way to do it, it would be best if it was an opt-in option for people experiencing the issue.

 

[sgtsixpack]

Now I have liquidctl.exe I would never run cam because its a resource hog. Liquidctl.exe runs on startup (and my X72 remembers the settings until a shutdown) and it not needed after. Cudos to you though for finding a workaround. I have fitted 3000rpm noctua fans and when the liquid temp hits 32'c they go full whack. They are actually more efficient with their 6-pole motor than the NZXT aer's they replaced, using slightly less current and watts to get to 2.87kRPM. From reading the specs of the 140mm 3000rpm Noctuas I wished I had bought a case capable housing 140mm. They give more CFM @ lower decibels.

 

[ozzed]

Now I have liquidctl.exe I would never run cam because its a resource hog. Liquidctl.exe runs on startup (and my X72 remembers the settings until a shutdown) and it not needed after. Cudos to you though for finding a workaround. I have fitted 3000rpm noctua fans and when the liquid temp hits 32'c they go full whack. They are actually more efficient with their 6-pole motor than the NZXT aer's they replaced, using slightly less current and watts to get to 2.87kRPM. From reading the specs of the 140mm 3000rpm Noctuas I wished I had bought a case capable housing 140mm. They give more CFM @ lower decibels.

I have 4 Noctua NF-A14 industrialPPC-2000 IP67 PWM 140mm in Push-pull on my X62. The stock NZXT ones are not satisfactory to my needs either. I have heard about liquidctl but haven't tried it myself. Is it only command line? How does it work with setting light effects and such? Would I have to make new profiles for everything or can they be migrated from CAM? Sorry for all the questions. I would like to stop using CAM if possible. It's bloated resource hogging garbage for sure.

 

[sgtsixpack]

You do have to make a profile because the concept is to set fan and pump automation based on the liquid's temperature (which gets around having to find what temp a CPU/GPU is at ). Its a standalone executable which means that you can call it from the command line without installing its dependancies like python. You just need to set it in the system path. Once you do this it is a recognised command in the command prompt no matter which directory you are currently in. You set the pump, fan, and lighting (although lighting doesn't change once you set it once) when u boot to the desktop.

This is my .bat file which I put in the start-up folder of the start menu (not sure the equivalent, I'm using classic shell start menu):

@echo
liquidctl initialize all
liquidctl --version
TIMEOUT 2
liquidctl -m Kraken set fan speed 24 55 26 60 28 72 30 88 32 100 --verbose
liquidctl -m Kraken set pump speed 24 75 26 100 28 100 30 100 32 100 --verbose
liquidctl -m Kraken set ring color fading FF2608 0B03FF F35B10 --speed faster
liquidctl -m Kraken set logo color fading F35B10 0B03FF FF2608 --speed fastest
liquidctl status
TIMEOUT 30

Readme:

GitHub - liquidctl/liquidctl: Cross-platform CLI and Python drivers for AIO liquid coolers and other devices

Cross-platform CLI and Python drivers for AIO liquid coolers and other devices - liquidctl/liquidctl

github.com

 

[ozzed]

You do have to make a profile because the concept is to set fan and pump automation based on the liquid's temperature (which gets around having to find what temp a CPU/GPU is at ). Its a standalone executable which means that you can call it from the command line without installing its dependancies like python. You just need to set it in the system path. Once you do this it is a recognised command in the command prompt no matter which directory you are currently in. You set the pump, fan, and lighting (although lighting doesn't change once you set it once) when u boot to the desktop.

This is my .bat file which I put in the start-up folder of the start menu (not sure the equivalent, I'm using classic shell start menu):

@echo
liquidctl initialize all
liquidctl --version
TIMEOUT 2
liquidctl -m Kraken set fan speed 24 55 26 60 28 72 30 88 32 100 --verbose
liquidctl -m Kraken set pump speed 24 75 26 100 28 100 30 100 32 100 --verbose
liquidctl -m Kraken set ring color fading FF2608 0B03FF F35B10 --speed faster
liquidctl -m Kraken set logo color fading F35B10 0B03FF FF2608 --speed fastest
liquidctl status
TIMEOUT 30

Readme:

GitHub - liquidctl/liquidctl: Cross-platform CLI and Python drivers for AIO liquid coolers and other devices

Cross-platform CLI and Python drivers for AIO liquid coolers and other devices - liquidctl/liquidctl

github.com

I tried it out and it works nicely and I hope I can replace CAM one day. However It seems that it's only capable of adjusting the speed of the fans based on every 2 degrees C. which is not fine grained enough for my liking. I don't know if it's a limitation of the Liqctl or my X62 but when comparing "identical" fan curves from Liqctl and CaM in HWinfo it seems that CAM is capable of adjusting the fan speed much more finely, so I don't know what's up with that.

 

[sgtsixpack]

Its true that it works on 2'c steps but that is the current version 1.3.3. I already had a conversation with the programmer and he said that if you compile your own version of the master code into a standalone exe you get finer control; he said he would update it in version 1.4. This is what the programmer said:

"

This is a limitation in liquidctl that's being relaxed in the next release.


Without oficial documentation on the protocol, liquidctl initially (and up to version 1.3.3) used the same number of steps as CAM (21 steps), just in a more useful range (20°C to 60°C instead of CAM's 0°C to 100°C). Having only 21 steps to work with resulted in 2°C increments, but that was still an improvement over CAM's 5°C increments.¹


More recently I've been able to test and confirm a hypothesis that, in fact, the protocol allows much more steps than that (63). So starting on version 1.4.0 liquidctl will be able to set profiles with 1°C increments.²


While 1.4.0 isn't out, you can run the latest code in the master branch, which already has this improvement.



¹ Back when CAM supported saving profiles to the cooler.


² To reduce the number of writes to the device (and thus client delays, CPU usage, and USB bus contention), the profiles are still capped to the 20°C to 60°C range and 1°C increments are only used up to 50°C.

"

Trying to set fan speed to 100 @ 29'c doesn't work · Issue #113 · liquidctl/liquidctl

@echo liquidctl initialize all liquidctl --version TIMEOUT 2 liquidctl -m Kraken set fan speed 25 55 26 60 27 66 28 83 29 100 liquidctl -m Kraken set pump speed 25 60 26 75 27 90 28 100 29 100 liqu...

github.com

 

[ozzed]

Its true that it works on 2'c steps but that is the current version 1.3.3. I already had a conversation with the programmer and he said that if you compile your own version of the master code into a standalone exe you get finer control; he said he would update it in version 1.4. This is what the programmer said:

"

This is a limitation in liquidctl that's being relaxed in the next release.


Without oficial documentation on the protocol, liquidctl initially (and up to version 1.3.3) used the same number of steps as CAM (21 steps), just in a more useful range (20°C to 60°C instead of CAM's 0°C to 100°C). Having only 21 steps to work with resulted in 2°C increments, but that was still an improvement over CAM's 5°C increments.¹


More recently I've been able to test and confirm a hypothesis that, in fact, the protocol allows much more steps than that (63). So starting on version 1.4.0 liquidctl will be able to set profiles with 1°C increments.²


While 1.4.0 isn't out, you can run the latest code in the master branch, which already has this improvement.



¹ Back when CAM supported saving profiles to the cooler.


² To reduce the number of writes to the device (and thus client delays, CPU usage, and USB bus contention), the profiles are still capped to the 20°C to 60°C range and 1°C increments are only used up to 50°C.

"

Trying to set fan speed to 100 @ 29'c doesn't work · Issue #113 · liquidctl/liquidctl

@echo liquidctl initialize all liquidctl --version TIMEOUT 2 liquidctl -m Kraken set fan speed 25 55 26 60 27 66 28 83 29 100 liquidctl -m Kraken set pump speed 25 60 26 75 27 90 28 100 29 100 liqu...

github.com

Awesome, thanks! I tried the latest build and it works like a charm, and yes even more fine-grained than CAM. Super thankful for this. So long, CAM, thanks for nothing