Custom user sensors in HWiNFO

1. You can pass any values to HWiNFO including time, you just need to have an application that will write the data in required format into registry.
2. Correct
3. I don't see the problem here. You have written 0x47, which is 71 decimal and shown as such by HWiNFO.
 
1. But what is the appropriate format for time/uptime values?
2. Would it be possible to HWiNFO to check for new custom devices/sensors after it has started? Otherwise users that autostart HWiNFO will need to orchestrate the initialization order by themselves, which is tricky. A single third-party application could try to do that for the user, but it would be fragile and break as soon as the user wants custom sensors from two different sources.
3. There's no major issue with 71 being being displayed as 71.000; however, if all values are handled according to internal rules regardless of the datatype, then what's the objective behind supporting multiple datatypes? Other than the very minor efficiency gain from using a DWORD instead of a string when reading/writing to the registry.
 
Another small thing I notice: HWiNFO is not able to recover if a custom sensor (i.e. its registry key) goes away, even after if has become available again. The real world scenario is the user closes or experiences a crash in the third-party application, which clears its stuff from the registry before exiting. Once the application is restarted, all registry keys are recreated, but even if they are identical as before, the values remain grayed out in HWiNFO until it is restarted too.

I imagine that once reading from a key fails, you never try to do that again. Isn't that too extreme/could that behavior be made more tolerant?
 
1. Any format you choose, use OtherX with a value of string type (REG_SZ).
2. That would not be quite efficient as HWiNFO would have to be polling dozens of registry entries all the time if there perhaps appears a new value. Given the small success rate (99.9% machines don't use custom sensors), this would not be a smart idea.
3. And what's the disadvantage here? I don't see anything against supporting both types.

I will check how to improve the situation when the sensor disappears.
 
Another small thing I notice: HWiNFO is not able to recover if a custom sensor (i.e. its registry key) goes away, even after if has become available again. The real world scenario is the user closes or experiences a crash in the third-party application, which clears its stuff from the registry before exiting. Once the application is restarted, all registry keys are recreated, but even if they are identical as before, the values remain grayed out in HWiNFO until it is restarted too.

I imagine that once reading from a key fails, you never try to do that again. Isn't that too extreme/could that behavior be made more tolerant?

This will be updated in the next build.
 
1. I decided to skip uptimes, as without a specific time-based format the resulting displayed values would be fairly ugly (e.g. 752.342 h, or even worse if I were to stick to SI seconds).

2. Perhaps a middle-ground of polling for new devices, but not new sensors? Also, for users not using any custom sensors, wouldn't a single check that no subkeys exist in Sensors\Custom be sufficient? But I admit I don't have any experience with the Windows Registry, so I could be grossly underestimating the cost of a check like that. For now I added (re)starting of HWiNFO once the program has finished initializing its keys in the registry.

3. No major disadvantage, though I perhaps wouldn't have bothered implementing this conversion had I know before that it doesn't improve the resulting value that the end-user sees.

> This will be updated in the next build.

Ok, great.

Thanks again, Martin!
 
Yo Martin,
I 've got some wired issues placing all the HWinfo64 data into the "AquasuiteX25 software.
Opening the Aquasuite and choosing the data sources it seams like lots of the data are cut out:

Aquasuite2.PNG

These are all the data I've got in the Aquasuite.
For some reason I am having a large free space in the data list.
I am not able to work on the layout list because it end on VBAT. All the other data below are not reachable for any work.
What am I supposed to do?
HWINfo.PNG
 
Yo Martin,
I 've got some wired issues placing all the HWinfo64 data into the "AquasuiteX25 software.
Opening the Aquasuite and choosing the data sources it seams like lots of the data are cut out:

View attachment 4950

These are all the data I've got in the Aquasuite.
For some reason I am having a large free space in the data list.
I am not able to work on the layout list because it end on VBAT. All the other data below are not reachable for any work.
What am I supposed to do?
View attachment 4951

Try to click the "Restore Original Order" button in sensor settings - Layout, and/or enable "Fixed order".
 
Martin. In the first post you said that string value should be used to store floats, but you've also said that one can use "Any format you choose, use OtherX with a value of string type (REG_SZ).".
Does that mean I should be able to store arbitrary string values (not just numeric ones) and be able to see them?

I noticed that HWinfo sensors are storing only numeric and boolean values, not strings. I tried to set reg key Value to foo but the sensor will cast it to int and show 0. Is it even possible to show string values?

I figured I could store this string as a Unit instead of Value as a workaround. I encountered few problems though
- The Unit/Name once read by HWinfo, won't be refreshed if changed
- Even if I delete the reg key (ie Other0), close HW, restart PC, then create new Other0 key with different Name, HWinfo will still show the old name (and Unit)
- If unit was refreshed dynamically, I'd still always have a numeric value visible next to it, which wouldn't show anything relevant although that wouldn't be a big deal.

I have a use case where I would like to show an arbitrary string value (i.e. IP address) using RTSS OSD and for HWinfo to help me relay this information to RTSS.
 
I'm sorry, but HWiNFO won't accept other values than integer/float numbers (even though stored as string). This is because of the internal logic that always expects a number, which is also used for min/max/average evaluations.
 
Hey Martin,

I figured out that using an OtherX key with the Unit set to "Yes/No" displays yes or no instead of a number which is a really neat feature, I use this to show the device connection status of my custom hardware.
But that is not mentioned anywhere on this thread, so it might be nice of put that in the original post. And just out of curiousity are there more of these hidden features.

I have a other question regarding critical red color, is there a way to set this via the registery.
When my program generates the necessary register key it would be nice if that could also set the critical >/< limits (user override should of course have priority). This way the user doesn't have to do that manually. This could also possibly mean that the external sensor could change those limits depending on its state for example, might be nice as well.
 
There are no other such hidden features and sorry, currently it's not possible to specify the critical limits via registry.
 
What am I doing wrong here -- I want my minimum and maximum CPU clocks to be read out on my 3700X. They're both reading out as "0.0MHz"

Code:
Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors\Custom]

[HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors\Custom\CPU]

[HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors\Custom\CPU\Clock0]
"Name"="Min Freq"
"Value"="min(\"Core 0 Clock\",\"Core 1 Clock\",\"Core 2 Clock\",\"Core 3 Clock\",\"Core 4 Clock\",\"Core 5 Clock\",\"Core 6 Clock\",\"Core 7 Clock\")"

[HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\Sensors\Custom\CPU\Clock1]
"Name"="Max Freq"
"Value"="max(\"Core 0 Clock\",\"Core 1 Clock\",\"Core 2 Clock\",\"Core 3 Clock\",\"Core 4 Clock\",\"Core 5 Clock\",\"Core 6 Clock\",\"Core 7 Clock\")"
 
First, you should remove the backslashes, these are not to be used in registry (unlike in C ;)).
Second, the value names like "Core 0 Clock" need to match values shown in the GUI. Since you didn't post a screenshot of what's shown in your case, I can only speculate that these items might also contain a " (perf #x)" string. This needs to be included there, so the names in registry need to exactly match those shown in GUI.
 
First, you should remove the backslashes, these are not to be used in registry (unlike in C ;)).
Second, the value names like "Core 0 Clock" need to match values shown in the GUI. Since you didn't post a screenshot of what's shown in your case, I can only speculate that these items might also contain a " (perf #x)" string. This needs to be included there, so the names in registry need to exactly match those shown in GUI.
I knew you were going to comment on the backslashes, haha. They're not there in my registry, regedit adds them when you export registry files. They're added in this case to show that the quotes are quotes in the string, not the end of the value.

I'll check if my core numbers have a # in front of them when I get back to my pc later today
 
I knew you were going to comment on the backslashes, haha. They're not there in my registry, regedit adds them when you export registry files. They're added in this case to show that the quotes are quotes in the string, not the end of the value.

I'll check if my core numbers have a # in front of them when I get back to my pc later today
If any of the sensors are hidden or not monitoring, the custom sensor will not work.
 
First, you should remove the backslashes, these are not to be used in registry (unlike in C ;)).
Second, the value names like "Core 0 Clock" need to match values shown in the GUI. Since you didn't post a screenshot of what's shown in your case, I can only speculate that these items might also contain a " (perf #x)" string. This needs to be included there, so the names in registry need to exactly match those shown in GUI.
That was indeed the problem -- I had perf # tags on my values. Are those similar to the values shown by Ryzen Master and ClockTuner? Showing which cores are rated as "better"? Having a 1/1, etc is kind of strange.
 
Yes, those determine the preferred core order. The first number is the CPPC order, the second one is the hardware-fused value.
 
Hi Martin,

I write programs for arduino (moderate skillset in C lang), is there anyway to fetch any reading from HWinfo by Serial port or the opposite where HWinfo sends selected data to serial port in a string format every "x" seconds . I am willing to help to develop such kind of serial port feature, I can help validate things on the arduino side. There are some very important use cases for this feature, for eg. in this way I can regulate the fans/HVAC system of a server room based on the selected readings(temperature/voltage/etc.) in HWinfo.
 
Back
Top