Custom user sensors in HWiNFO

Martin

HWiNFO Author
Staff member
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?
 

Martin

HWiNFO Author
Staff member
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.
 

Martin

HWiNFO Author
Staff member
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!
 

DedSec

New Member
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
 

Martin

HWiNFO Author
Staff member
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".
 

Morfi717

New Member
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.
 

Martin

HWiNFO Author
Staff member
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.
 

youpko

New Member
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.
 

Martin

HWiNFO Author
Staff member
There are no other such hidden features and sorry, currently it's not possible to specify the critical limits via registry.
 
Top