Using HWiNFO with Rainmeter

[jsmorley]

I'd personally be hesitant to try to over-automate this. The sensor element labels may be pretty consistent across Intel / AMD CPU hardware, but then there are tons of motherboards and chipsets, various generations of nVidia / AMD graphics cards, and various HDD / SSD hard drive types and all that. In addition, I personally already went in and "renamed" a lot of my sensor elements to eliminate vague and duplicate "GPU" names and such.

I'd be a bit resistant about any effort to automatically base any of this on a sensor element "label".

[raiguard]

I have another question about this... how does this prevent commercial entities from using this info? It's very easy to go in and enable all the sensors, then simply query the registry. Wouldn't people who want to profit off of HWiNFO's information just do the same thing we're doing? Or am I misunderstanding something important?

[jsmorley]

I have another question about this... how does this prevent commercial entities from using this info? It's very easy to go in and enable all the sensors, then simply query the registry. Wouldn't people who want to profit off of HWiNFO's information just do the same thing we're doing? Or am I misunderstanding something important?

That is something I try not to push too hard on with Martin. He believes that the combination of having to manually select the desired sensors on a machine by machine basis, combined with the fact that "remote" computer monitoring still requires the Shared Memory stuff, will be enough to discourage at least the larger of the bad actors. I'd like to not put a worm in his brain about this. The first thing he would do is disable the ability to multi-line select in that dialog, and the second would be to say "well never mind... I'm turning this all off", and we are back to square one.

[raiguard]

That is something I try not to push too hard on with Martin. He believes that the combination of having to manually select the desired sensors on a machine by machine basis, combined with the fact that "remote" computer monitoring still requires the Shared Memory stuff, will be enough to discourage at least the larger of the bad actors. I'd like to not put a worm in his brain about this. The first thing he would do is disable the ability to multi-line select in that dialog, and the second would be to say "well never mind... I'm turning this all off", and we are back to square one.

It's also another reason why trying to automate the configuration is a bad idea. The fact that there is no 100% consistent way to get the right sensors automatically will also be a good deterrent for "bad actors". I'll explore other options for making the configuration easier.

[jsmorley]

It's also another reason why trying to automate the configuration is a bad idea. The fact that there is no 100% consistent way to get the right sensors automatically will also be a good deterrent for "bad actors". I'll explore other options for making the configuration easier.

I haven't fully chewed on this yet, but my thinking is that if we can use Lua or something to create a somewhat prettier and easy to read list of the stuff stored in the registry, something the end-user can use as a reference, then having them just set #Variables# in some .inc file with a clear name for the variable, all they need to do is set the index number for each variable.

[jsmorley]

I'd be tempted to have the Lua create a text file of the formatted results, and then just open the text file in the default text editor. Then you can "search" and all that. Having the list be in a "skin", like my scrollable example in the .rmskin, particularly if they select all sensor elements, would be hard to use.

[SilverAzide]

I haven't fully chewed on this yet, but my thinking is that if we can use Lua or something to create a somewhat prettier and easy to read list of the stuff stored in the registry, something the end-user can use as a reference, then having them just set #Variables# in some .inc file with a clear name for the variable, all they need to do is set the index number for each variable.

Note sure if you saw it, but see my PowerShell command above. I can't figure out how to get PS to grab the second Value line to tack on as an example. I was trying to get it to list stuff like this, so you could get a "list" or reference of your indexes:

Code: Select all

0 = Core 0 Clock (3,610 MHz)
1 = Core 1 Clock (3,620 MHz)
2 = Core 2 Clock (3,600 MHz)
3 = Core 3 Clock (3,610 MHz)
4 = Core 0 (45 C)
5 = Core 1 (48 C)
6 = Core 2 (43 C)
7 = Core 3 (45 C)

[jsmorley]

Note sure if you saw it, but see my PowerShell command above. I can't figure out how to get PS to grab the second Value line to tack on as an example. I was trying to get it to list stuff like this, so you could get a "list" or reference of your indexes:

Code: Select all

0 = Core 0 Clock (3,610 MHz)
1 = Core 1 Clock (3,620 MHz)
2 = Core 2 Clock (3,600 MHz)
3 = Core 3 Clock (3,610 MHz)
4 = Core 0 (45 C)
5 = Core 1 (48 C)
6 = Core 2 (43 C)
7 = Core 3 (45 C)

I'd prefer something like:

Code: Select all

Index 0
Sensor		CPU [#0]: AMD Ryzen 7 2700X
Label		CPU Core 0 Speed
Value		4,298.9 MHz
ValueRaw	4298.9

Index 1
Sensor		CPU [#0]: AMD Ryzen 7 2700X
Label		CPU Core 1 Speed
Value		2,865.9 MHz
ValueRaw	2865.9

Shouldn't be that hard in Lua.

Maybe create the list as a table in HTML and output that and open it in the default browser.

[pul53dr1v3r]

Good job by Martin and your effor Morley but...
If every possible entry has its static index, it would be much easier for the end users to configure as they would only have to enable reporting of some of the sensors in the menu. Nothing else. but in this case Sensor0, Label0... etc. can be anything that is firstly selected in the HWiNFO Gadget menu. In your example it is CPU, but if someone won't use CPU data, anything can be under that index number.

This is how's it done in AIDA64 for CPU temperatures, where the sensor names are always unique and static for all the sensors:



AMD CPUs have TCPUPKG sensor name and Intel TCPU for general CPU temperatures and so on. So, you know in advance which sensor name is for certain data, while in HWiNFO the index numbers make it more complicated but it caould be simpler.

[jsmorley]

Good job by Martin and your effor Morley but...
If every possible entry has its static index, it would be much easier for the end users to configure as they would only have to enable reporting of some of the sensors in the menu. Nothing else. but in this case Sensor0, Label0... etc. can be anything that is firstly selected in the HWiNFO Gadget menu. In your example it is CPU, but if someone won't use CPU data, anything can be under that index number.

This is how's it done in AIDA64 for CPU temperatures, where the sensor names are always unique and static for all the sensors:



AMD CPUs have TCPUPKG sensor name and Intel TCPU for general CPU temperatures and so on. So, you know in advance which sensor name is for certain data, while in HWiNFO the index numbers make it more complicated but it caould be simpler.

I understand, but that is not going to happen. Martin doesn't have a lot of time to mess with this, and he is leveraging some existing functionality. Nowhere in HWiNFO is there any concept of a "static" name for sensor elements.

Martin is going to resist any suggestions to make this any "easier" for the end-user than it is. In his perfect world, every Rainmeter user would fork up the $25 a year and use the existing plugin. He understands that that won't happen, and he wants to support us consistent with his needs to lock commercial users into a paid version, but he has far bigger and more lucrative fish to fry.