Thanks so much for your really kind and constructive message !
> Secondly, my opinions below are just that; my opinions. They aren't meant as criticism of your concepts.
Sorry but from your words, I feel that.
> I just wanted to express my ideas, and discuss them
Me too
Some months ago two different users from the world contacted me to add WMI support where they can get "human-readable" information quickly and easily to display in text reports / use with VBS scripts.
Then I added these and thought it is the beginning.
As developer, I always feel things can (and should be) improved and I was thinking about adding more and more functions, exactly to make things more useful and better. And especially as I tried to explain, the integration part was (and will be) one of the most important features.
This is why the first version released (and the above mentioned users were happy about it) and I wanted to collect other ideas, thoughts, suggestions (for example from users of monitoring solutions where Hard Disk Sentinel can be a great addition) about what could be done to make it even more useful. For example yes, by adding values which could (and should) be interpreted by these monitoring tools / solutions.
Just I did not want to make it which may be not the best for that solution - this is why I only added information asked by the above mentioned users and consider adding more information in "non-human readable" but "programmer-readable" format too.
So thanks for teaching me about how to make programs and functions and thanks for laughing - but you did not really make me happy.
> At least not as the primary way to present it. But perhaps have two properties; one with raw hours, and another with human-readable?
Yes, this is the idea and this will happen in the next version.
> As for the Report property... You should also consider breaking down the report status into several numerical properties
> as well (and not just a human-readable text string). I don't know how HD Sentinel generates its report string (I don't
> know the defined expressions and words you use), but maybe something like this...
The report property is designed exactly to show the current report in human readable format.
This is designed to represent the error counters, generally show WHY the health is 100% (no problems found), 90% or anything else.
This property can be ignored if the user is not interested in this explanation
> For example:
> 0 = UNKNOWN
> 1 = PERFECT
> 2 = BAD SECTORS (and have another separate property with the sector count)
> 3 = CRASHED
> 4 = UNAVAILABLE
> 5 = EXPLODED AND CURRENTLY IN FLAMES!
help[/code]
To be honest, I do not really feel this is useful... Many people worry about "bad sectors" even if they cause no problems, since they're already reallocated. There are numerous other problems which can degrade a hard disk, can cause data corruption/data loss and failure.
> Another example for SSD TRIM:
>
Code: Select all
0 = UNKNOWN (i.e. not an SSD)
> 1 = SUPPORTED AND ENABLED
> 2 = SUPPORTED BUT DISABLED
> 3 = NOT SUPPORTED
Yes, this may useful.
> This is a very common way to present status information numerically.
Thanks for the lesson
> Yeah, I didn't expect you to dump the entire SMART into WMI.
> But maybe access to some of the most critical attributes so monitoring software can keep an eye on what's going on.
I suspect limited SMART would be not a good choice.
We should have complete SMART data or nothing.
Currently it is not available because I did not yet find the best way to represent all information in the best way which can be most useful for possible other uses, can be easily loaded, parsed by scripts and/or other monitoring tools.
So here I'm really open for suggestions about how to represent, what would be the best way which allows the easiest integration.
> For example start/stop counts, power cycle count, and general error attributes such as reallocated block counters etc.
There are dozens of other attributes which are very important - and could be interesting in many cases.
Not only critical values, but statistical ones (maybe no need to mention the attributes you prefer to use in Write Amplification calculation
This is one part where I was sure that improvement required - to provide all S.M.A.R.T. data to allow users to get precise, clear representation of attributes, counters etc.
Not only the "vendor specific" raw data which would need to be interpreted.
> I do realize you have the Health property, but it would be practical to also know WHY it's showing 90%
> without having physical access to the computer to look in HD Sentinel UI (or read the xml file or data files).
This is exactly the purpose of the Report property
No need to check the UI and/or the XML report - as you'll immediately know the reason and the error counters.
> the local filesystem. It's not dependent on directory paths or other variables
You can get the XML report remotely if you enable the Configuration -> Integration -> Enable Webstatus and open
http://hostname:61230/xml
This method used widely by the add-ons to check the COMPLETE status remotely.
But yes, I completely agree that WMI is simpler and does not require enabling port on firewall and so.
This is why I planned to extend - and collecting ideas, suggestions about how.
> OpenHardwareMonitor creates it's own Namespace "Root/OpenHardwareMonitor".
Yes, and there are others using root namespace.
I see no reason in moving to cimv2, but if you feel it is better and can suggest why, I'm open for that.
> And because root/cimv2 is the default namespace, you don't have specify the namespace on each WMI query either.
Personally I was always thinking to use root namespace as cimv2 may be better to leave for Windows (OS-defined) objects.
But maybe I'm wrong - as "I'm on the beginning of development" in the WMI provider functionality.
> I would really love to create a guide specifically for HD Sentinel when the WMI portion is up and running
Thanks, that would be excellent - and this is generally I waited before adding MORE functions: to discuss how it is best to make things from the beginning, instead of changing, fixing some already-done functions.
So if you can help about what information would be nice to have and in which format / representation, I'd be really happy to hear and make things exactly to help integration.