It is currently October 21st, 2019, 4:10 am

Plugin for HWiNFO

Plugins and Addons popular with the Community
User avatar
jsmorley
Developer
Posts: 19591
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » March 8th, 2016, 12:27 pm

Well, this sounds like a Rainmeter issue to me. Shouldn't Disabled not call anything, and Paused does not call Update? Right now they sound the same.
As we discussed before the change, I was going to log to Rainmeter only once at Reload and output the values in the skin at Update. Otherwise there is not a way for me to only write to the log once unless I start tracking that internally with the measure. This is why I asked if there are standard measure parameters that I should be honoring. If you are going to call the Reload function anyways, then maybe I need to store the disabled state and check it when Reload fires so I can abort. I matched the logging frequency to the function frequency.......seemed logical, no?
The way it works is that when the skin is loaded or refreshed, the plugin is sent the Reload() function. This is going to be the place where you do things you generally need to only happen once. Reading measure parameters is one good example. What else you do in this function will vary depending on the plugin, but it's certainly a good place to do CPU intensive things that only need to happen one time.

Note that while normally Reload() is only fired once when the skin is loaded or refreshed, setting DynamicVariables=1 on the measure in the skin will cause Reload() to be fired on every measure update, allowing a user to have dynamically changing parameters on the measure for instance.

Update() happens on every update of the measure in the skin. This is where you take whatever repetitive actions the plugin is designed for, like reading senor values and returning the values.

Disabled and Paused are in fact much the same. They both prevent the skin from updating the measure, and so no Update() call is made to the plugin. The difference between the two is that Disabled sets the measure value to "0" and Paused simply retains whatever the previous value was. However, neither prevents the Reload() function from being called when the skin is loaded or refreshed.

So it's not that the plugin needs to know or react to the "disabled" state of the measure, no need for that. The disabled or paused state of the measure simply determines if the Update() function is called in the plugin or not during the skin update cycle.

I'm not suggesting you change your plugin, I just don't think this minor issue warrants it, but in the case of HWiNFO, having it actually read and use the shared memory in Reload() and producing errors if it can't is absolutely guaranteed to generate errors on every system restart. There is no reasonable way to be certain that HWiNFO starts before Rainmeter, and even if you could / did, the time it takes for HWiNFO to scan for the sensors will mean that you would have to delay the start of Rainmeter for some unknown and variable number of seconds, somewhere between 5-30. Nobody is going to do that to support one skin.

Make no mistake though, in one sense the issue here really isn't Reload() vs. Update(), and I only explained those above mostly for information's sake. There will be multiple Update() calls made as the skin loops through the normal update cycle before HWiNFO can possibly finish scanning the hardware, so even if Reload() is designed not to produce errors, maybe not to interact with HWiNFO at all, errors are still going to be produced when the system is first started. However, the difference is that I have some control over Update() with Disabled or Paused, but no control at all over Reload(). That IS going to be fired.I could in theory introduce a "timer" in the skin that waits 20 seconds before enabling plugin measures when the system is first started.

All that aside, my thinking with the proposed new parameters concerning logging is that I might set up one plugin measure, who's only job it is is to get one single senor value, and test for "-9xxxx". If the value is not "-9xxxx" then I know all is well, and I can "enable" all the other "real" measures that are getting the senors values. If it is "-9xxxx", then I just leave them all disabled. I set the "no error logging" parameter on that first measure, so it doesn't get the error produced by the "timing" issue when the system is restarted.

I really don't want to stay on 3.0, as I don't want to be stuck depending on it's functionality as the plugin potentially moves forward over time to 3.2, 3.3 or whatever other changes you might make in the future based on some clever ideas you have, or due to changes in HWiNFO itself. However, due to this really unsolvable "timing" issue, I would ask that now and going forward thee is more control given over what "logging" is done. The fact that errors return values of "-9xxxx" is fine, and in fact vastly preferable as it allows for definitive testing for actual errors. It is just trivial to deal with any cosmetic issues caused by "-9xxxx". It's only the errors in the log that I can't be the master of today.
TGonZo
Posts: 58
Joined: April 25th, 2015, 8:19 pm
Location: Virginia

Re: Plugin for HWiNFO

TGonZo » April 20th, 2016, 3:57 am

Hi all,

I don't believe this was mentioned, not exactly anyway.
When you are getting a CurrentValue, typically a number, and you stop HWiNFO and start it back up, the measures/meters just start back up. But if you pull the Units or a SensorName, Text data, when HWiNFO restarts, these measures/meters do not refresh. They are left with HWI_ERROR_NOT_CONNECTED. The only safe thing to do at that point is to refresh all meters.
I guess this would also happen on startup if Rainmeter starts before HWiNFO.

I don't believe this happened before the 3.x plugin. If I recall the actual SensorName data was resent as soon as HWiNFO restarted.

Is there a reasonable action I can take in the meter coding to get this refreshed?
Or is there another change in behavior coming from the HWiNFO plugin soon?

Doing a Refresh All after restarting the HWiNFO is not a big deal, but I did not have to do that before.

Just wondering how to deal with this. I would prefer all sensors be available on a restart of the HWiNFO process. So everything is working without the need for a manual refresh.

Thanks.
GemiWagner
Posts: 8
Joined: August 26th, 2015, 1:59 pm

Re: Plugin for HWiNFO

GemiWagner » April 20th, 2016, 5:06 pm

Hi !

Is there a rainmeter bang action or what in your plugin to call the Reset function of HWiNFO Sensor ?

Thanks.
User avatar
jsmorley
Developer
Posts: 19591
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » April 20th, 2016, 5:55 pm

Try adding DynamicVariables=1 to the plugin measures.

I don't know how stangowner has the plugin written, but if he is getting those sensor text values in the Reload() function instead of the Update() function, then they will only be re-evaluated on a skin refresh. However, if you have DynamicVariables=1 on the measure, then Reload() is called on every skin update.
TGonZo
Posts: 58
Joined: April 25th, 2015, 8:19 pm
Location: Virginia

Re: Plugin for HWiNFO

TGonZo » April 21st, 2016, 2:29 am

Thanks. I tried adding DynamicVariables=1 to the measure, no change in behavior.

I loaded the previous version I had, which was the 2.0 HWiNFO plugin. When I stop the HWiNFO program I see the SensorName change, and when the program is started, the SensorName comes back and is correct, automatically.

I'll try to setup a measure to monitor for the -9000 to positive transition and then refresh that one skin. The trick is to only refresh once.

Thanks.
TGonZo
Posts: 58
Joined: April 25th, 2015, 8:19 pm
Location: Virginia

Re: Plugin for HWiNFO

TGonZo » April 21st, 2016, 3:12 am

Okay, First let me say, this is not ideal, and I consider this only a workaround.

I made 2 measures to monitor a value from the HWiNFO plugin that I was using in my skin. I have those 2 measures toggle each other from enable to disable states with one of them performing the refresh. The 1st one starts off disabled, once enabled and it detects the -9000 to positive change, and calls a !Refresh on the skin and disables itself. The 2nd will watch for the transition back to negative and toggle the 2 measures once again.

Seems to work .... most of the time. In my short testing I have seen it refresh the skin and pick up all the Text values except one. And this only happened once so far. I can only guess it is just timing. The measure saw the change, it started the refresh, and the HWiNFO was not done scanning all the sensors. But mostly it works.

I know we all think HWiNFO is a great tool, and I think we would all like to see it behave a bit better......Please.
But for now, some may fine this method useful.

Code: Select all

[HWiNFOGPU0NameRefresh]
Measure=Plugin
Plugin=HWiNFO.dll
HWiNFOSensorId=#HWiNFO-GPU0-Usage-SensorId#
HWiNFOSensorInstance=#HWiNFO-GPU0-Usage-SensorInstance#
HWiNFOEntryId=#HWiNFO-GPU0-Usage#
HWiNFOType=CurrentValue
Disabled=1
IfAboveValue=-1
IfAboveAction=[!Refresh #CURRENTCONFIG#][!EnableMeasure HWiNFOGPU0NameRefreshOff][!DisableMeasure HWiNFOGPU0NameRefresh]

[HWiNFOGPU0NameRefreshOff]
Measure=Plugin
Plugin=HWiNFO.dll
HWiNFOSensorId=#HWiNFO-GPU0-Usage-SensorId#
HWiNFOSensorInstance=#HWiNFO-GPU0-Usage-SensorInstance#
HWiNFOEntryId=#HWiNFO-GPU0-Usage#
HWiNFOType=CurrentValue
IfBelowValue=0
IfBelowAction=[!EnableMeasure HWiNFOGPU0NameRefresh][!DisableMeasure HWiNFOGPU0NameRefreshOff]
stangowner
Posts: 41
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » May 16th, 2016, 12:43 am

TGonZo wrote:When you are getting a CurrentValue, typically a number, and you stop HWiNFO and start it back up, the measures/meters just start back up. But if you pull the Units or a SensorName, Text data, when HWiNFO restarts, these measures/meters do not refresh. They are left with HWI_ERROR_NOT_CONNECTED. The only safe thing to do at that point is to refresh all meters.
Hi,

I can confirm this behavior. I coded the fix this morning so it will be in the next build which is in the works.
stangowner
Posts: 41
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » May 16th, 2016, 1:02 am

jsmorley wrote:Maybe these new options:

HWiNFOLogToSkin - If this is enabled, then the changes in 3.1 will be reflected in the skin, otherwise 3.0 behavior of returning 0.0 and "" will be used.
HWiNFOLogToRainmeter - If this is enabled, the events will be logged in the Rainmeter log, otherwise nothing will be logged.

Are the only good way to give full control of this to the skin author.
Hi jsmorley. Sorry for the delayed reply on this. I've had some personal things that have limited my time recently. Now I'm behind on several projects :(

I know we've further discussed this, but I'm thinking this is the best option. Here is what I've done. Please tell me if you agree before I release an update.

I added a parameter called HWiNFOLogHandler which is an enum flag. This allows me to cover both skin & RM log with one parameter, plus if I ever add something else it can cover that too.

Missing: no logging in skin or RM log
0: same as missing (no logging)
1: log to RM
2: log to skin
3: due to being a flag, logs to both skin & RM log (1+2)

1 only fires during reload. 2 fires every update

I know you're not crazy about checking for HWiNFO errors during reload, but honestly there is no better RM funtion to do them. Doing during update would require I carry an extra flag on the measure to see if it was written yet, reset it when needed, and check it every update wasting a few clock cycles.

So in a sense, this reverts default behavior to before the previous update, adds the additional logging in both areas via opt-in, and gives full control the to the skin author.

Do you agree?

Thanks,
Nick
User avatar
jsmorley
Developer
Posts: 19591
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » May 16th, 2016, 1:05 am

stangowner wrote:Hi jsmorley. Sorry for the delayed reply on this. I've had some personal things that have limited my time recently. Now I'm behind on several projects :(

I know we've further discussed this, but I'm thinking this is the best option. Here is what I've done. Please tell me if you agree before I release an update.

I added a parameter called HWiNFOLogHandler which is an enum flag. This allows me to cover both skin & RM log with one parameter, plus if I ever add something else it can cover that too.

Missing: no logging in skin or RM log
0: same as missing (no logging)
1: log to RM
2: log to skin
3: due to being a flag, logs to both skin & RM log (1+2)

1 only fires during reload. 2 fires every update

I know you're not crazy about checking for HWiNFO errors during reload, but honestly there is no better RM funtion to do them. Doing during update would require I carry an extra flag on the measure to see if it was written yet, reset it when needed, and check it every update wasting a few clock cycles.

So in a sense, this reverts default behavior to before the previous update, adds the additional logging in both areas via opt-in, and gives full control the to the skin author.

Do you agree?

Thanks,
Nick
Sounds reasonable Nick.
stangowner
Posts: 41
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » May 16th, 2016, 1:18 am

Thanks for the quick reply. I need to make a change to the shared memory viewer app, and then I'll package an update. I leave on a trip tomorrow, so it might be a few.