HWiNFO loses some sensors

[chjohans]

I'm using a registered version of HWiNFO to visualize my temperatures, fan speeds and others through a sidebar gadget. I'm also using it with FanControl (https://github.com/Rem0o/FanControl.Releases) and the HWiNFO FanControl plugin (https://github.com/Rem0o/FanControl.HWInfo). This plugin reads the same registry values (written by HWiNFO) as the sidebar gadget, it can use speed and temperature sensors.

I rely on some of the sensor values reported by HWiNFO in order to control my fans. The problem is that HWinFO loses some of the sensors for a moment, exactly how long I'm not sure, but it seems like it's just momentarily for one update cycle. This happens in my case for sensors from my Corsair AiO cooler (pump speed, coolant temperature, and fan speeds). Others have reported similar for other sensor sources. There is a thread re this here: https://github.com/Rem0o/FanControl.HWInfo/issues/29

I assume that HWiNFO just deletes the registry entries for any missing sensor in each update cycle. The sidebar gadget seems not to be affected by this, but it breaks FanControl as it throws an error and requires a "manual refresh" to re-read the sensor (which is then always back).

I'm assuming the update cycle for the registry values for the sidebar gadget follows the Global polling period as set under "Configure Sensors"?

Would it be possible to change the error handling a bit so that instead of just deleting the registry key for a missing sensor on the first update cycle it's missing, to just reuse the previous value for another update cycle or two, and then delete the registry key if the sensor is still missing?

Maybe not ideal, but to miss an update cycle or two would not be critical, and this would solve the issue and make things more robust. Ideally this would be solved at the source, but I don't see that happening any time soon. Would this be possible, please?

 

[chjohans]

A follow-up question that will help me debug this:

Exactly what happens if HWiNFO "loses" a sensor for a few seconds, and "Report value in Gadget" has been enabled for that sensor?

Will HWiNFO then delete the sensor and its value from the registry the next update cycle, and will it re-order the IDs in the registry the same way it does when "Report value in Gadget" is enabled or disabled for a sensor in the settings?

Or will it just delete that sensor and it's values from the registry, without re-ordering the IDs of the other sensors in the registry?

Or will it do something else entirely?

@Martin - it would be extremely helpful to know this, please!

 

[Martin]

Yes, HWiNFO deletes the respective entry in registry if it fails to read a valid value from sensor.
But it doesn't reorder the indexes in this case.

 

[chjohans]

Great, thanks @Martin !!!

 

[chjohans]

@Martin The issue I'm having seems related to this: https://www.hwinfo.com/forum/threads/sensor-reports-from-corsair-h115i-aio-are-glitching.7991/

I see that you added a workaround when HWiNFO momentarily lose sensors from the Corsair AiOs, except it does not seem like that workaround extends to the values written to the registry for the "gadget"?

I'm using HWiNFO (paid version) as I explain in the first post, some of my fan control depends on values read by HWiNFO from my Corsair H115i AiO. HWiNFO fails to update the registry values for these sensors maybe once or twice every day, the situation kind of resolves itself but it totally breaks my fan control.

Could you please extend your workaround to the registry values? What I'm asking is basically that you continue to write the last correct value read to the registry as long as these values are shown "In grey" in HWiNFO. This would totally fix the issue I'm having, thanks.

 

[Martin]

The registry interface was never meant to perfectly deal with all situations and quirks. It's not even an official feature, only some use it (as a sort of backdoor).
It's much better to use the Shared Memory Interface that's more reliable and provides a lot more details.

 

[chjohans]

The registry interface was never meant to perfectly deal with all situations and quirks. It's not even an official feature, only some use it (as a sort of backdoor).
It's much better to use the Shared Memory Interface that's more reliable and provides a lot more details.

That might very well be, but I have no control over what is being used. So it would be very helpful if you could do the mentioned change.

 

[Martin]

This was intentionally added to make some other clients work properly, so I'm sorry there's no plan to change it.

 

[chjohans]

Yes I saw that, and "this client" - also a paying "subscriber", was asking for a similar change! But I get it, you won't do it.

 

[Martin]

It's easy to manage this on the client side - if the client saw a certain value which has disappeared from the registry, consider it as currently invalid and use the previous one in the case.

 

[chjohans]

I was referring to myself as a client, or rather a paying customer.

As for the "client" (as in software) using the data from HWiNFO, I have no control of that, or I would have just done it.