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

Plugin for HWiNFO

Plugins and Addons popular with the Community
stangowner
Posts: 41
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » March 6th, 2016, 12:34 pm

stangowner wrote:Hi Jtmzac,

I responded to your suggestion in the HWiNFO forum here as it has a dedicated thread:
http://www.hwinfo.com/forum/Thread-Suggestion-to-Improve-Plugin

Thanks,
Nick
This has been implemented. You can get the updated plugin and implementation details here:

http://www.hwinfo.com/forum/Thread-Rainmeter-plug-in-for-HWiNFO-3-1?pid=11089#pid11089

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 » March 6th, 2016, 5:23 pm

I actually have some heartburn with this change.

While having the error codes available when you are debugging a skin is a good thing, in practice not being able to turn this off when you are done with the skin causes some real cosmetic ugliness, and some errors in the log that shouldn't be there.

Let me explain what I mean.

When you restart your computer, or sign-out / sign-in to to Windows, the following happens:

1) Windows starts
2) Rainmeter starts
3) Rainmeter loads the skin(s)
4) HWiNFO starts
5) HWiNFO scans the hardware sensors
6) The Rainmeter HWiNFO plugin sees the sensor values

The problem is that no matter what order 2-4 happens in, the certain thing is that 5) HWiNFO scans the hardware sensors, is going to take some time, some number of seconds. While HWiNFO is scanning the sensors, your skin is going to be sitting there with error values in the meters. The real problem cosmetically is that something like a hardware temperature, that was likely designed around 2 or at most 3 characters, is now 5 characters (-9000 for example) and doesn't fit, and at the same time, you are getting a ton of errors in the log that are not really errors, but just a question of timing. This is going to happen every time you start Windows.

I'd really like to see a way to turn off this error trapping. Perhaps a new option on the plugin measures. It would be nice to have while building and testing the skin, but I don't care for it as an ongoing factor.

What I did to work around this for now is:

Code: Select all

[MeasureHWiNFOAwake]
Measure=Plugin
Plugin=HWiNFO
HWiNFOSensorId=#HWiNFOSensorId1#
HWiNFOSensorInstance=#HWiNFOSensorInstance1#
HWiNFOEntryId=#HWiNFOEntryId1#
HWiNFOType=#HWiNFOType1#
UpdateDivider=5
IfAboveValue=0
IfAboveAction=[!EnableMeasureGroup Sensors]
IfBelowValue=0
IfBelowAction=[!DisableMeasureGroup Sensors]
So I have this first plugin measure, that I call [MeasureHWiNFOAwake], that simply tests one of the temperature sensors I'm also using later in the skin, but this measure isn't used in a meter itself. If it returns a value above zero then I know all is well, and I can enable the rest of the measures, they will return "0" while disabled, which is cosmetically more pleasing while the skin is "waiting" than "-9000" is. This also stops the bogus errors in the log.

I guess my point is that the time that the skin is waiting for HWiNFO to finish scanning your hardware is not an "error". It's a perfectly reasonable issue of timing, that there needs to be some graceful way to handle. I'm open to different approaches...

Edit: ARGH! It's even worse than that. For some reason the plugin is not obeying "Disabled=1" on the plugin measures, and so while the measures return "0" to the meters ok, the log is still full of "errors" that don't make sense at all.
User avatar
Jtmzac
Posts: 28
Joined: January 24th, 2016, 9:11 am
Location: Sydney, Australia

Re: Plugin for HWiNFO

Jtmzac » March 6th, 2016, 6:20 pm

Thanks for the update stangowner.

I've been procrastinating about getting back to writing my skin after I burnt myself out and this is a good reason to get going again. I'll make sure to put the update to good use.



RE: jsmorley

Sorry if its causing you strife. I feel partially responsible since I requested the change.

Is it possible to not output any hwinfo errors to the log for the first 10 seconds after rainmeter starts or something along those lines?

My only suggestion regarding the large numbers/strings from errors is while its extra text I think it's easy enough to fix on the skin side with clipstring or hiding the meter temporarily if it's causing problems. I have no idea if there are situations where you couldn't or don't want to do either of because of other factors so I don't know if this is really an adequate solution.

The reason I wanted an error output in the first place was to hide meters when there's no proper data coming from sensors so for me at least its exactly what I needed.
User avatar
jsmorley
Developer
Posts: 19591
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » March 6th, 2016, 9:31 pm

Jtmzac wrote:Thanks for the update stangowner.

I've been procrastinating about getting back to writing my skin after I burnt myself out and this is a good reason to get going again. I'll make sure to put the update to good use.



RE: jsmorley

Sorry if its causing you strife. I feel partially responsible since I requested the change.

Is it possible to not output any hwinfo errors to the log for the first 10 seconds after rainmeter starts or something along those lines?

My only suggestion regarding the large numbers/strings from errors is while its extra text I think it's easy enough to fix on the skin side with clipstring or hiding the meter temporarily if it's causing problems. I have no idea if there are situations where you couldn't or don't want to do either of because of other factors so I don't know if this is really an adequate solution.

The reason I wanted an error output in the first place was to hide meters when there's no proper data coming from sensors so for me at least its exactly what I needed.
While I shouldn't have to, fixing the cosmetic problems is not hard. There are all kinds of Substitute options that can make it look any way I want. The issue that is really impossible to solve at the skin level is the errors in the log.

Let's see what stangowner thinks. This is just particularly annoying for me, as I have this anal-retentive obsession about not having any errors in the log. I will work on a skin for days to stomp out the last vestige of any error messages, especially, especially ones that shouldn't be there in the first place. I run like 15 skins, and when I start Rainmeter or refresh all, I want 15 "Refreshing skin" messages and nothing else...

It's not a huge deal, just something that is more or less a burr under my saddle... ;-)

What I want...
1.png
To be clear, the net benefit of this is really good, particularly for a user struggling to configure a skin to use the plugin.
You do not have the required permissions to view the files attached to this post.
stangowner
Posts: 41
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » March 7th, 2016, 11:40 am

jsmorley wrote:While having the error codes available when you are debugging a skin is a good thing, in practice not being able to turn this off when you are done with the skin causes some real cosmetic ugliness, and some errors in the log that shouldn't be there.
It is true the 5 digit code or long error text will affect alignment during startup. But under normal operating condition this will never be the case. I noticed this when updating the plugin too, but don't see a way around this.

There is no way for me to determine that HWiNFO is starting and in the process of scanning the hardware. The plugin can either communicate with HWiNFO or it can't. I don't think ignoring these logs entries assuming it is a starting condition is a good idea. If you are concerned about having a clean log, then clearing the log and refreshing all skins will give you the results you want. Typically you should only look at the logging when creating the skin, or if there is an issue with the skin. In these cases, you want the entries there.
jsmorley wrote:I'd really like to see a way to turn off this error trapping. Perhaps a new option on the plugin measures. It would be nice to have while building and testing the skin, but I don't care for it as an ongoing factor.
I agree that changing the default behavior may not have been a good one size fits all approach. Typically in software development new features may be added, disabled by default, and enabled through a configuration option. However, the true benefit to these enhancements were not for skin developers who know enough about the underlying workings of the various pieces to get the skin going. It was intended to be a drastic help to end users of skins that need the help configuring the skin. Due to the interaction with HWiNFO and the fact that everyone's hardware is different, there is no way to create a skin that will work on another machine out of the box. It will require the end user, regardless of their skill levels with skins, to do the configuration for the skin. So having these codes present allows them to update the skin easier, and once the skin is updated the values are correct.

Perhaps I could do as you ask and create 2 new skin parameters. These could be set in the skin as a variable so you can globally enable and disable the behavior for all measures.
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.

This will accomodate your personal preference of having these features during setup and debug, and allow you to disable after your skin is done. However, I still think all other users should leave them enabled as there will never be an indication of an issues when they are disabled (short of 0.0 and "" as in 3.0).
jsmorley wrote:Edit: ARGH! It's even worse than that. For some reason the plugin is not obeying "Disabled=1" on the plugin measures, and so while the measures return "0" to the meters ok, the log is still full of "errors" that don't make sense at all.
If I am supposed to be honoring something in the plugin other than the exported functions, please point me in the direction of the documents. I did not know that all plugins are supposed to support a default set of parameters including Disabled.

Please let me know your thoughts.

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 » March 7th, 2016, 12:33 pm

stangowner wrote:If I am supposed to be honoring something in the plugin other than the exported functions, please point me in the direction of the documents. I did not know that all plugins are supposed to support a default set of parameters including Disabled.
I suspect you are actually doing queries to the HWiNFO shared memory in the Reload(() function of the plugin, and any errors that happen at that time are logged.

The way "Disabled" or "Paused" work, is that Rainmeter won't update the measure, and so no call to the Update() function of the plugin will be made. However, since Reload() is always fired when the skin is loaded or refreshed, if you are writing to the log in that function, those errors can never be avoided by disabling or pausing the measure.

HWiNFO is not the only plugin that has this issue. WebParser does the same thing. If you have Disabled=1 on the measure it will sill attempt to connect to the resource in Reload() and you will get at least an initial error(s) in the log.

I would think that this entire minor annoyance (for me anyway) could be solved by never having any error messages that are related to receiving data from HWiNFO be produced by the Reload() function. Errors should only be produced when the plugin is updated, and that way I have full control by using Disabled or Paused.

Errors in the Reload() function are generally going to be "invalid parameter" type errors, which you really can't have with your plugin. There are no user-created parameters that have some possible set of "valid" values associate with them.

As I said before, I'm just kinda anal-retentive about errors in the log. My feeling on it is that if bogus errors are produced, that tends to "train" users to ignore errors. I want any error in the log to have the user stopping everything to figure out what they are doing wrong. The fact that HWiNFO is not yet "ready" for the plugin is not an error. I do understand however, that you can't know the difference in the plugin.

Still, I don't think this warrants upsetting the applecart or making major changes to your code. As to the cosmetics, I can simply use RegExpSubstitute to change "-90NN" to "0" or "--" or "☹" or whatever works best with my design. I simply will not allow a situation where every time I start my computer, I have a skin that is flooded with -9000" errors for 10-20 seconds. I can't live with that behavior. As to the errors in the log, under normal circumstances, you will only get those one time, and only when HWiNFO is first started, presumably only at a reboot of the system.

On reflection, I don't think measure options to turn off and on error reporting is wise. It is of no value to a user trying to configure a skin they just downloaded, and that would be the primary target of the errors anyway. There are really only two kinds of errors that are generally going to be produced. A user doesn't "get it" that they have to have HWiNFO.exe running to use the plugin, or they get the sensor values from SharedMemoryViewer.exe wrong. Both of those cases simply must produce an error that tells the user something is wrong.
User avatar
jsmorley
Developer
Posts: 19591
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » March 7th, 2016, 1:29 pm

I think I can live with this:

Code: Select all

[MeasureHWiNFO1]
Measure=Plugin
Plugin=HWiNFO
Group=Sensors
HWiNFOSensorId=#HWiNFOSensorId1#
HWiNFOSensorInstance=#HWiNFOSensorInstance1#
HWiNFOEntryId=#HWiNFOEntryId1#
HWiNFOType=#HWiNFOType1#
MinValue=#HWiNFOMin1#
MaxValue=#HWiNFOMax1#
UpdateDivider=5
RegExpSubstitute=1
Substitute="^-9\d\d\d":"0"
I have that Substitute on all my HWiNFO measures of course, and so while HWiNFO is "standing up" at the start, the values are all just "0", which is not only cosmetically more pleasing than "-9000", but is all the "error" indication I need. Obviously my CPU temperature is never going to actually be "0".

I do get one single set of errors in the log:
1.png
But that is just not the end of the world. It's only one time, and only when I first reboot my system. The perfectionist jerk who lives in my head hates it, but he just needs to get a life. He also tells me the cat is talking about me, so he is not be trusted.
You do not have the required permissions to view the files attached to this post.
User avatar
SilverAzide
Posts: 592
Joined: March 23rd, 2015, 5:26 pm

Re: Plugin for HWiNFO

SilverAzide » March 7th, 2016, 4:47 pm

Well, I'm with you, Mr. Morley... I have an OCD streak in me too in keeping the logs clean. Some of my skins support optional use of HWiNFO, and even with all the HWiNFO sensor measures disabled, I get one line in the log for every measure if HWiNFO is not running. It's the only plugin I've seen do this, though admittedly I don't have a lot of experience with 3rd party plugins.
DeviantArt Gadgets More...
User avatar
jsmorley
Developer
Posts: 19591
Joined: April 19th, 2009, 11:02 pm
Location: Fort Hunt, Virginia, USA

Re: Plugin for HWiNFO

jsmorley » March 7th, 2016, 4:53 pm

SilverAzide wrote:Well, I'm with you, Mr. Morley... I have an OCD streak in me too in keeping the logs clean. Some of my skins support optional use of HWiNFO, and even with all the HWiNFO sensor measures disabled, I get one line in the log for every measure if HWiNFO is not running. It's the only plugin I've seen do this, though admittedly I don't have a lot of experience with 3rd party plugins.
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.
stangowner
Posts: 41
Joined: October 6th, 2012, 12:27 pm

Re: Plugin for HWiNFO

stangowner » March 8th, 2016, 11:31 am

jsmorley wrote:I suspect you are actually doing queries to the HWiNFO shared memory in the Reload(() function of the plugin, and any errors that happen at that time are logged.
This is true. I added deeper checks in the Reload function so I could write more detailed info to the log to help direct the user to the root problem so it can be corrected.
jsmorley wrote:The way "Disabled" or "Paused" work, is that Rainmeter won't update the measure, and so no call to the Update() function of the plugin will be made. However, since Reload() is always fired when the skin is loaded or refreshed, if you are writing to the log in that function, those errors can never be avoided by disabling or pausing the measure.

HWiNFO is not the only plugin that has this issue. WebParser does the same thing. If you have Disabled=1 on the measure it will sill attempt to connect to the resource in Reload() and you will get at least an initial error(s) in the log.

I would think that this entire minor annoyance (for me anyway) could be solved by never having any error messages that are related to receiving data from HWiNFO be produced by the Reload() function. Errors should only be produced when the plugin is updated, and that way I have full control by using Disabled or Paused.
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?
jsmorley wrote:As I said before, I'm just kinda anal-retentive about errors in the log. My feeling on it is that if bogus errors are produced, that tends to "train" users to ignore errors. I want any error in the log to have the user stopping everything to figure out what they are doing wrong. The fact that HWiNFO is not yet "ready" for the plugin is not an error. I do understand however, that you can't know the difference in the plugin.
I could ask Martin the HWiNFO author to stand up the shared memory immediately with an 'INIT' status so I could check this in the plugin. But this will only cover the 10-20 second period during the scan. It won't help if HWiNFO is not running. Therefore, there is little value to this change.
jsmorley wrote:Still, I don't think this warrants upsetting the applecart or making major changes to your code. As to the cosmetics, I can simply use RegExpSubstitute to change "-90NN" to "0" or "--" or "☹" or whatever works best with my design. I simply will not allow a situation where every time I start my computer, I have a skin that is flooded with -9000" errors for 10-20 seconds. I can't live with that behavior. As to the errors in the log, under normal circumstances, you will only get those one time, and only when HWiNFO is first started, presumably only at a reboot of the system.
Correct. The new parameter to prevent logging to the skin will fix the first issue. As for the second issue, I'd recommend you just ensure Rainmeter starts after HWiNFO finishes scanning, or you clear the log and refresh the skins. I don't agree with disabling logging to the Rainmeter log as previously mentioned, but I'll add the parameter for anal-retentive users ;-)
jsmorley wrote:On reflection, I don't think measure options to turn off and on error reporting is wise. It is of no value to a user trying to configure a skin they just downloaded, and that would be the primary target of the errors anyway. There are really only two kinds of errors that are generally going to be produced. A user doesn't "get it" that they have to have HWiNFO.exe running to use the plugin, or they get the sensor values from SharedMemoryViewer.exe wrong. Both of those cases simply must produce an error that tells the user something is wrong.
That was the idea.

For now, please feel free to continue using v 3.0. There are no functional differences in the plugin except for the logging.