Using HWiNFO with Rainmeter

[jsmorley]

Important!

As of version 7.0 of the HWiNFO hardware sensor monitoring tool, the software has changed to require purchasing a yearly "Pro" license in order to use the Shared Memory feature of the software that allowed it to interact with the HWiNFO plugin for Rainmeter. This would make distributing Rainmeter skins to end-users problematic at best.

Martin Malik, the author of HWiNFO, has graciously worked with us to find a solution that will allow the software to be used for personal, non-commercial use in Rainmeter without having to purchase a license, while keeping his ability to monetize his application when used by commercial entities.

The approach consists of tweaking a feature of HWiNFO that was implemented years ago to support using the software with the now long-dead Windows Sidebar gadgets. This allows you to output the current values of one or more sensors to the Windows Registry, where it can be easily accessed using the Registry measure in Rainmeter. A distinct HWiNFO plugin for Rainmeter is no longer required.

All skins that use HWiNFO will need to be changed. While the new approach is actually easier to configure for the end-user of your skins, it is significantly different, and requires that skins be adapted to work.

This thread can be used to discuss this change, and help folks who need to revise their skins to adapt to this new approach.

This requires that you get the latest 7.02 or later version of HWiNFO

https://www.hwinfo.com/download/

Just remember that it was version 7.0 that broke things, and it requires 7.02 or later to fix them.

Then carefully read and follow this guide

https://docs.rainmeter.net/tips/hwinfo/

Feel free to post in this thread with any questions!

[jsmorley]

One initial tip I would give on this is that you should probably encourage your end-users to "export" all the sensor elements from HWiNFO that they are ever likely to need in your skin, and other skins they may create or try later. The issue is that the "index" numbers that are created will change if they later add or remove sensor elements from what they "export", and that can cause all their skins to need changes to the index numbers they use.

I exported a lot of CPU stuff, like the core speeds and temperatures, some motherboard temperatures, various fan speeds, hard drives temperatures and S.M.A.R.T. stuff, and a bunch of GPU sensor elements for my graphics card. I think I ended up with 40 exported (out of the HUNDREDS in HWiNFO) although currently I only use about 8 of them.

So I ended up with:

reg query HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\VSB

Code: Select all

HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\VSB
    Sensor0    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label0    REG_SZ    CPU Core 0 Speed
    Value0    REG_SZ    4,298.9 MHz
    ValueRaw0    REG_SZ    4298.9
    Color0    REG_SZ    0080c0
    Sensor1    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label1    REG_SZ    CPU Core 1 Speed
    Value1    REG_SZ    2,865.9 MHz
    ValueRaw1    REG_SZ    2865.9
    Color1    REG_SZ    ff0000
    Sensor2    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label2    REG_SZ    CPU Core 2 Speed
    Value2    REG_SZ    2,865.9 MHz
    ValueRaw2    REG_SZ    2865.9
    Color2    REG_SZ    400040
    Sensor3    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label3    REG_SZ    CPU Core 3 Speed
    Value3    REG_SZ    4,298.9 MHz
    ValueRaw3    REG_SZ    4298.9
    Color3    REG_SZ    408080
    Sensor4    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label4    REG_SZ    CPU Core 4 Speed
    Value4    REG_SZ    2,865.9 MHz
    ValueRaw4    REG_SZ    2865.9
    Color4    REG_SZ    0080c0
    Sensor5    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label5    REG_SZ    CPU Core 5 Speed
    Value5    REG_SZ    2,865.9 MHz
    ValueRaw5    REG_SZ    2865.9
    Color5    REG_SZ    8080c0
    Sensor6    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label6    REG_SZ    CPU Core 6 Speed
    Value6    REG_SZ    2,865.9 MHz
    ValueRaw6    REG_SZ    2865.9
    Color6    REG_SZ    408080
    Sensor7    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label7    REG_SZ    CPU Core 7 Speed
    Value7    REG_SZ    4,298.9 MHz
    ValueRaw7    REG_SZ    4298.9
    Color7    REG_SZ    008080
    Sensor8    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X
    Label8    REG_SZ    Total CPU Usage
    Value8    REG_SZ    0.4 %
    ValueRaw8    REG_SZ    0.4
    Color8    REG_SZ    004080
    Sensor9    REG_SZ    Memory Timings
    Label9    REG_SZ    Memory Clock
    Value9    REG_SZ    1,066.4 MHz
    ValueRaw9    REG_SZ    1066.4
    Color9    REG_SZ    004080
    Sensor10    REG_SZ    CPU [#0]: AMD Ryzen 7 2700X: Enhanced
    Label10    REG_SZ    CPU Temperature
    Value10    REG_SZ    37.0 °C
    ValueRaw10    REG_SZ    37.0
    Color10    REG_SZ    ff0000
    Sensor11    REG_SZ    GIGABYTE X470 AORUS ULTRA GAMING-CF (ITE IT8686E)
    Label11    REG_SZ    System1
    Value11    REG_SZ    34 °C
    ValueRaw11    REG_SZ    34
    Color11    REG_SZ    8080c0
    Sensor12    REG_SZ    GIGABYTE X470 AORUS ULTRA GAMING-CF (ITE IT8686E)
    Label12    REG_SZ    Chipset
    Value12    REG_SZ    42 °C
    ValueRaw12    REG_SZ    42
    Color12    REG_SZ    0080c0
    Sensor13    REG_SZ    GIGABYTE X470 AORUS ULTRA GAMING-CF (ITE IT8686E)
    Label13    REG_SZ    CPU
    Value13    REG_SZ    32 °C
    ValueRaw13    REG_SZ    32
    Color13    REG_SZ    8080c0
    Sensor14    REG_SZ    GIGABYTE X470 AORUS ULTRA GAMING-CF (ITE IT8686E)
    Label14    REG_SZ    CPU Fan
    Value14    REG_SZ    961 RPM
    ValueRaw14    REG_SZ    961
    Color14    REG_SZ    008080
    Sensor15    REG_SZ    GIGABYTE X470 AORUS ULTRA GAMING-CF (ITE IT8792E)
    Label15    REG_SZ    System2
    Value15    REG_SZ    31 °C
    ValueRaw15    REG_SZ    31
    Color15    REG_SZ    800040
    Sensor16    REG_SZ    S.M.A.R.T.: Patriot Burst (F90B07960B0400296676)
    Label16    REG_SZ    Drive Temperature
    Value16    REG_SZ    33 °C
    ValueRaw16    REG_SZ    33
    Color16    REG_SZ    800000
    Sensor17    REG_SZ    S.M.A.R.T.: Patriot Burst (F90B07960B0400296676)
    Label17    REG_SZ    Drive Remaining Life
    Value17    REG_SZ    98.0 %
    ValueRaw17    REG_SZ    98.0
    Color17    REG_SZ    0080c0
    Sensor18    REG_SZ    S.M.A.R.T.: Patriot Burst (F90B07960B0400296676)
    Label18    REG_SZ    Drive Failure
    Value18    REG_SZ    No
    ValueRaw18    REG_SZ    No
    Color18    REG_SZ    0000ff
    Sensor19    REG_SZ    S.M.A.R.T.: Patriot Burst (F90B07960B0400296676)
    Label19    REG_SZ    Drive Warning
    Value19    REG_SZ    No
    ValueRaw19    REG_SZ    No
    Color19    REG_SZ    004000
    Sensor20    REG_SZ    S.M.A.R.T.: ST3000DM008-2DM166 (Z505HWZ0)
    Label20    REG_SZ    Drive Temperature
    Value20    REG_SZ    40 °C
    ValueRaw20    REG_SZ    40
    Color20    REG_SZ    808000
    Sensor21    REG_SZ    S.M.A.R.T.: ST3000DM008-2DM166 (Z505HWZ0)
    Label21    REG_SZ    Drive Failure
    Value21    REG_SZ    No
    ValueRaw21    REG_SZ    No
    Color21    REG_SZ    808080
    Sensor22    REG_SZ    S.M.A.R.T.: ST3000DM008-2DM166 (Z505HWZ0)
    Label22    REG_SZ    Drive Warning
    Value22    REG_SZ    No
    ValueRaw22    REG_SZ    No
    Color22    REG_SZ    000000
    Sensor23    REG_SZ    S.M.A.R.T.: WDC WD40NMZW-11GX6S1 (WD-WX41D19A045A)
    Label23    REG_SZ    Drive Temperature
    Value23    REG_SZ    39 °C
    ValueRaw23    REG_SZ    39
    Color23    REG_SZ    ff0080
    Sensor24    REG_SZ    S.M.A.R.T.: WDC WD40NMZW-11GX6S1 (WD-WX41D19A045A)
    Label24    REG_SZ    Drive Failure
    Value24    REG_SZ    No
    ValueRaw24    REG_SZ    No
    Color24    REG_SZ    804040
    Sensor25    REG_SZ    S.M.A.R.T.: WDC WD40NMZW-11GX6S1 (WD-WX41D19A045A)
    Label25    REG_SZ    Drive Warning
    Value25    REG_SZ    No
    ValueRaw25    REG_SZ    No
    Color25    REG_SZ    ff0000
    Sensor26    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label26    REG_SZ    GPU Temperature
    Value26    REG_SZ    39.3 °C
    ValueRaw26    REG_SZ    39.3
    Color26    REG_SZ    400040
    Sensor27    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label27    REG_SZ    GPU Fan
    Value27    REG_SZ    1,250 RPM
    ValueRaw27    REG_SZ    1250
    Color27    REG_SZ    ff0000
    Sensor28    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label28    REG_SZ    GPU Power
    Value28    REG_SZ    23.442 W
    ValueRaw28    REG_SZ    23.442
    Color28    REG_SZ    400040
    Sensor29    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label29    REG_SZ    GPU Clock
    Value29    REG_SZ    300.0 MHz
    ValueRaw29    REG_SZ    300.0
    Color29    REG_SZ    004080
    Sensor30    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label30    REG_SZ    GPU Memory Clock
    Value30    REG_SZ    101.3 MHz
    ValueRaw30    REG_SZ    101.3
    Color30    REG_SZ    408080
    Sensor31    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label31    REG_SZ    GPU Video Clock
    Value31    REG_SZ    540.0 MHz
    ValueRaw31    REG_SZ    540.0
    Color31    REG_SZ    0080c0
    Sensor32    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label32    REG_SZ    GPU Core Load
    Value32    REG_SZ    6.0 %
    ValueRaw32    REG_SZ    6.0
    Color32    REG_SZ    8080c0
    Sensor33    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label33    REG_SZ    GPU Memory Controller Load
    Value33    REG_SZ    2.0 %
    ValueRaw33    REG_SZ    2.0
    Color33    REG_SZ    008080
    Sensor34    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label34    REG_SZ    GPU Video Engine Load
    Value34    REG_SZ    0.0 %
    ValueRaw34    REG_SZ    0.0
    Color34    REG_SZ    004080
    Sensor35    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label35    REG_SZ    GPU Memory Usage
    Value35    REG_SZ    5.5 %
    ValueRaw35    REG_SZ    5.5
    Color35    REG_SZ    800040
    Sensor36    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label36    REG_SZ    GPU Fan Percentage
    Value36    REG_SZ    27 %
    ValueRaw36    REG_SZ    27
    Color36    REG_SZ    800000
    Sensor37    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label37    REG_SZ    GPU Memory Allocated
    Value37    REG_SZ    614 MB
    ValueRaw37    REG_SZ    614
    Color37    REG_SZ    0000ff
    Sensor38    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label38    REG_SZ    GPU D3D Memory Dedicated
    Value38    REG_SZ    404 MB
    ValueRaw38    REG_SZ    404
    Color38    REG_SZ    004000
    Sensor39    REG_SZ    GPU [#0]: NVIDIA GeForce RTX 2080 Ti: 
    Label39    REG_SZ    GPU D3D Memory Dynamic
    Value39    REG_SZ    32 MB
    ValueRaw39    REG_SZ    32
    Color39    REG_SZ    808000

Keep in mind that every computer this is used on will have different sensors that HWiNFO monitors. While there are very common sensors that pretty much any computer will have, even those may have completely different element "labels" depending on the hardware.

[jsmorley]

For authors of existing skins that use HWiNFO, I can often the following advice in order to move forward:

The goal should be to rewrite your skins to use the new approach, and get that out to your end-users as soon as possible. This might take some time however, and you will need to react to "whaaaa, it's broken!" comments that you get in the meantime.

1) An end user can just stay on any earlier 6.x version of HWiNFO, and the skins will just continue to work with the HWiNFO plugin for Rainmeter. That will buy them some time, but I caution that earlier versions of HWiNFO will quickly get out of date with the latest hardware. That should NOT be the recommended or suggested long term solution.

2) An end user can in fact use HWiNFO 7.x with existing skins and the HWiNFO plugin for Rainmeter, but unless they purchase a "Pro" version of the software, they will have to go into the HWiNFO "settings" and enable Shared Memory Support every 12 hours. This can't possibly be a popular or practical solution for the long term, but might tide them over while you revise your skins.

[SilverAzide]

This is a great solution that Martin has come up with, and it appears to work really well.

The only catch is that this new scheme is so different that it is almost like a whole new third-party monitoring utility; i.e., no existing HWiNFO code can be salvaged.

Not complaining, mind you, it's just that this is not gonna be a quick conversion. I'm hoping I won't need to create HWiNFO 7.x-specific skins, or worse yet AMD/Intel/nVidia-specific skins.

P.S.: And thanks for jumping on this so quickly and creating a tutorial, that is super-helpful.

[jsmorley]

This is a great solution that Martin has come up with, and it appears to work really well.

The only catch is that this new scheme is so different that it is almost like a whole new third-party monitoring utility; i.e., no existing HWiNFO code can be salvaged.

Not complaining, mind you, it's just that this is not gonna be a quick conversion. I'm hoping I won't need to create HWiNFO 7.x-specific skins, or worse yet AMD/Intel/nVidia-specific skins.

P.S.: And thanks for jumping on this so quickly and creating a tutorial, that is super-helpful.

Certainly no "measures" created that used the Rainmeter plugin can be salvaged.

A measure that used to look like this:

Code: Select all

[MeasureCPUTempCurrentValue]
Measure=Plugin
Plugin=HWiNFO
HWiNFOSensorId=0xf0000501
HWiNFOSensorInstance=0x0
HWiNFOEntryId=0x1000000
HWiNFOType=CurrentValue

Will need to look like this:

Code: Select all

[Variables]
CPUTempIndex=10

[MeasureCPUTempCurrentValue]
Measure=Registry
RegHKey=HKEY_CURRENT_USER
RegKey=SOFTWARE\HWiNFO64\VSB
RegValue=ValueRaw#CPUTempIndex#

I don't really see any issues with different hardware vendors that didn't already exist with the plugin. So for instance, Intel CPU's have a temperature value for each separate core, while AMD has only a single temperature value for the whole CPU.

[jsmorley]

This doesn't eliminate the "hassle" for end-users to configure things for your skin(s), but I would argue that while different, it's actually easier.

So instead of having to use the separate Shared Memory Viewer application to find and copy / paste the following values into a .inc or the skin:

Code: Select all

HWiNFOSensorId=0xf0000501
HWiNFOSensorInstance=0x0
HWiNFOEntryId=0x1000000
HWiNFOType=CurrentValue

They need to do some up-front "configuring" in HWiNFO, and then just get the single "index" number that can be found with:

reg query HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\VSB

Or you can give them this skin and activate it on demand...

Code: Select all

[Rainmeter]
Update=1000
DynamicWindowSize=1
AccurateText=1
OnRefreshAction=[!CommandMeasure MeasureReg "Run"]

[Variables]
ScrollY=-10

[MeasureReg]
Measure=Plugin
Plugin=RunCommand
Program=reg
Parameter=query HKEY_CURRENT_USER\SOFTWARE\HWiNFO64\VSB
State=Hide
OutputType=ANSI
RegExpsubstitute=1
Substitute="ø":"°","    Color.*\n":""

[MeterContainerBack]
Meter=Image
W=600
H=300
SolidColor=47,47,47,255
DynamicVariables=1
MouseScrollDownAction=[!SetVariable ScrollY "(Clamp(#ScrollY#-20, (-([MeterReg:H]-310)), -10))"][!Update]
MouseScrollUpAction=[!SetVariable ScrollY "(Clamp(#ScrollY#+20, -310, -10))"][!Update]

[MeterContainer]
Meter=Image
W=600
H=300
SolidColor=47,47,47,255

[MeterReg]
Meter=String
MeasureName=MeasureReg
X=5r
Y=#ScrollY#
FontFace=Segoe UI
FontSize=11
FontWeight=400
FontColor=255,255,255,255
AntiAlias=1
DynamicVariables=1
Container=MeterContainer

That will provide a scrollable list of all the sensor elements they "output" in HWiNFO, with the required "index" numbers.

I just can't stress enough that those "index" numbers need to be done as [Variables] in your skin, either directly or in a .inc file. As the end-user gets and runs more skins that use HWiNFO, they may need to add sensor elements to what they "output" in HWiNFO, and when they do, those index number can change. You need to make it as easy as possible for them to change the index number values.

[SilverAzide]

I don't really see any issues with different hardware vendors that didn't already exist with the plugin. So for instance, Intel CPU's have a temperature value for each separate core, while AMD has only a single temperature value for the whole CPU.

Yes, actually that's the bit I'm currently struggling with. With the plugin, if the end-user didn't have a sensor, the skin could use a default Entry ID of 0x0, which will enable the measure to still function and will always return zero (or use those -9xxx codes if preferred). This would then be ignored and/or otherwise dealt with as needed. In other words, skin author could create conditions that could react to a zero value to take some action to adjust skin logic.

But now how to handle a sensor that doesn't exist? Using your example, RegValue=ValueRaw#CPUTempIndex#, what if the user had no sensor for this? Do we default the CPUTempIndex variable to zero? That might return a non-zero result (i.e., the value of something else).

Any thoughts or suggestions?

[jsmorley]

Yes, actually that's the bit I'm currently struggling with. With the plugin, if the end-user didn't have a sensor, the skin could use a default Entry ID of 0x0, which will enable the measure to still function and will always return zero. This would then be ignored and/or otherwise dealt with as needed. In other words, skin author could create conditions that could react to a zero value to take some action to adjust skin logic.

But now how to handle a sensor that doesn't exist? Using your example, RegValue=ValueRaw#CPUTempIndex#, what if the user had no sensor for this? Do we default the CPUTempIndex variable to zero? That might return a non-zero result (i.e., the value of something else).

Any thoughts or suggestions?

If you use an Index value that does not exist, it will just happily return both number and string values of 0/"0". You can certainly react to that. If they use Index "10" to mean "temperature" and it actually means something else, like "fan speed", I don't see how you deal with that for them.

It's the Registry measure itself that gracefully deals with it when you ask for registry values that don't exist.

[SilverAzide]

If you use an Index value that does not exist, it will just return both number and string values of 0/"0". You can certainly react to that. If they use Index "10" to mean "temperature" and it actually means something else, like "fan speed", I don't see how you deal with that for them.

Oh yes yes yes.... I forgot that Registry measures return nothing for invalid keys. So you could use any index for "missing sensors", like -1 or "x" or whatever.

[jsmorley]

For the specific issue with the number of temperature elements that vary with Intel vs. AMD, I guess you might want to have two different .inc files. one that has indexes for all 8 or 16 or whatever core temperatures on Intel, and one that has the single index for AMD.