Motherboard sensors and parent "motherboard" in WMI

[GoogleCodeExporter]

What is the expected output? What do you see instead?
Since the exposed data indicates that the on-board sensor has the motherboard 
as "parent", I would expect to see it included in the beginning of the ID 
string as well. It's not.

What version of the product are you using? On what operating system?
0.3.0.5 beta on Windows XP and Windows 7 Enterprise

Please provide any additional information below.
I am building a plug-in, and I'm using the ID data to construct the data tree. 
I know it's just a simple thing programmatically, but I was just wondering. 
Like, so:

Name: ITE IT8721F
ID: /lpc/it8721f
Type: SuperIO
Parent: /mainboard

and then...

Name: Fan #1
ID: /lpc/it8721f/fan/0
Type: Fan
Parent: /lpc/it8721f
Value: 1956,522
Min: 1273,585
Max: 2136,076
Index: 0

whereas, all other sensors include the "Parent" string in the ID string. I was 
thinking, maybe add it or... second choice, I'll add it to everything, since 
everything resides on the motherboard.

Please attach a Report created with "File / Save Report...".
No need...

Original issue reported on code.google.com by ska...@yahoo.co.uk on 9 May 2011 at 8:06

[GoogleCodeExporter]

I think I will change that to get for example "/mainboard/lpc/it8721f" for the 
IT8721F super I/O chip. Originally the tree in the user interface has been 
different, and I didn't update the IDs when I changed the tree representation. 
But the change will be mainly to keep the ID generation a bit more systematic.

When using WMI you should NOT rely on the content of the IDs except for the 
fact that they are "unique" and can be used as an identifier for a hardware or 
sensor object. In the future we might replace them with something different in 
order to make sure that a new ID is generated when the user changes the for 
example the CPU.

For reconstructing the tree structure you can use the Parent field which just 
gives you the ID of the parent node (if there is any).

Original comment by moel.mich on 9 May 2011 at 11:01

• Changed state: Accepted

[GoogleCodeExporter]

Basically, I think you should either leave it alone, or add another string data 
item, with the full tree path. Since OHM does generate a tree internally, it 
should expose that tree structure to the WMI. I mean, why make plug-in 
programmers add more code, only to reconstruct what was already calculated 
internally in OHM?
Since every single plug-in will need that same tree structure, just provide it, 
either in ID or in a new data item.

By the way, I don't understand why changing a CPU should generate a different 
ID. It's still CPU 0 and it's got however many cores. The change of the CPU 
should (and will) appear as a different string in the CPU name. The enumeration 
should be the same. It's like, I don't know, like changing tyres in your car, 
and then counting the new tyres as #5, 6, 7 and 8, because the old tyres (which 
were thrown away) were #1, 2, 3 and 4!
Doesn't make sense...

Original comment by ska...@yahoo.co.uk on 9 May 2011 at 4:56

[GoogleCodeExporter]

Of course the Open Hardware Monitor should expose the tree, that's what we 
thought as well. As far as I know, the best way to represent a tree is by 
adding a reference to each node that points to the parent node. In the .NET 2.0 
WMI library it is not so easy to expose references to other instances as 
references. This is why we have just added the ID of the parent to each node. 
This also simplifies rebuilding the tree structure in a WMI client. 

Changing the ID when the hardware is changed would make sure that no settings 
or parameter associated with the old hardware is used (by mistake) with the new 
one. For example if you configured a temperature offset for an old CPU, this 
should be forgotten when you replace the CPU. Right now this is just kept, 
because both CPUs have the same ID in the Open Hardware Monitor. But more 
hardware specific IDs have also problems. The user would have to add the new 
CPU again to the desktop gadget, because the inclusion of the old CPU has no 
effect anymore.

Original comment by moel.mich on 9 May 2011 at 5:35

[GoogleCodeExporter]

I guess I will have to provisionally disagree. You see, the "parent" node is 
rather inconsistent. The "parent" node should contain *one* node; for example:

Name: GPU Fan
ID: /atigpu/0/control/0
Type: Control
Parent: /atigpu/0
Value: 15

that's rather wrong, since "parent" contains *two* nodes, namely "atigpu" and 
'0'. If we go "by the book", the GPU fan should have as parent "/0" and the 
"/0" node have as parent the "/atigpu" node. However, since there will be lots 
of "/0" nodes, as well as "/1" etc. it would be preferable to expose the entire 
path in the "parent" node or the "ID" node or somewhere, and get it over with 
in one step.

As for the problems of unique ID over common ID, I'd say you have to "fork" the 
items. For all the items that should be truly unique, like temperature offsets 
and/or dividers etc. you could generate something unique, for example: 
"/amdgpuphenomf43a4rbc3" (family and extended family, model, stepping, revision 
numbers), and that string doesn't have to be available to WMI. It will be just 
for internal "housekeeping", like you said. The ID or path or "parent path" or 
however you want to call it, should be common and "faceless". Even "/amdcpu" 
and "/intelcpu" is an overkill, since both are CPUs.

Offtopic: any chance of getting those CPU stepping, revision, family, model 
etc. data? Same for GPU, with shaders, ROPs etc? Also RAM latencies and speeds?

Original comment by ska...@yahoo.co.uk on 9 May 2011 at 6:35

[GoogleCodeExporter]

The parent field is not inconsistent. It contains always exactly the ID of 
another node. If you read "/atigpu/0" in the parent field of a node, then you 
know that somewhere there is a node with ID field equal to "/atigpu/0". And 
this node is your parent. You don't need to look into the content of the IDs to 
get the tree structure.

All the data (revision, family, ...) in the reports is only for debugging right 
now. We might add static hardware properties and information to the tool at 
some point, but currently this is not exposed by the library interface. First, 
a library interface has to be designed and a complete implementation has to be 
written where missing. After that we might also expose it to WMI.

Original comment by moel.mich on 9 May 2011 at 8:19

[GoogleCodeExporter]

So, how exactly should I construct the tree path of each "leaf" ?
Like : " parent + type + index " or something? But then, I'll have to be 
certain that the "parent" field contains the entire structure, up to a certain 
point. So far, it does, with only the exception of the motherboard sensor not 
showing the motherboard as parent.
What bothers me essentially, is the need for a recursive algorithm in order to 
construct the tree in the plug-in; I don't want to start searching in all the 
objects to find who is the parent of each child, and then who is the parent of 
that parent... if you know what I mean.

Original comment by ska...@yahoo.co.uk on 10 May 2011 at 7:06

[GoogleCodeExporter]

I assume you create an object in your code for each WMI sensor or hardware 
object. Then add all your objects into a Dictionary (or HashMap or similar) 
with the ID string as key and the object reference as value. Then iterate once 
over all your objects and get the reference to your parent object with a look 
up in the dictionary and store this reference in your object. When you have the 
reference of the parent object you can as well add your current object (child) 
into a list of children in the parent (if you want to keep such a list). The 
only slightly "expensive" operation is the look up "ID -> reference" in the 
Dictionary, but since the number of sensors and hardware is small, this should 
not be a problem (and if you use a hashmap it's good even for very large 
numbers).

Original comment by moel.mich on 10 May 2011 at 9:17

[GoogleCodeExporter]

Sir i am Malay Majhi from india,passed btech in computer science and engineer 
,i want to join your project now i am doing job as system emngineer in kolkata 
,my emailid malay.emailme@gmail.com .

Original comment by malay.em...@gmail.com on 10 May 2011 at 10:14

[GoogleCodeExporter]

Mate, you still don't get me. It's not that I don't *know* how to make the 
tree. What I want is a way to make the tree structure in a way that will 
consume as less memory as possible, and use as few CPU cycles as possible.
Essentially, you have already calculated the tree structure (in the background 
of OHM) and instead of passing that tree structure ready-made, you want my 
plug-in (and any other plug-in) to spend memory and CPU cycles, in order to 
RECONSTRUCT what has already been CONSTRUCTED inside OHM.
You're telling me to create either a dictionary or a hash table, iterate all 
objects, store the parent reference and reiterate to create the composite tree 
path of each object, and all that, for something that is already available 
inside OHM!

It would be much simpler to expose the full tree "path" as a string inside each 
sensor's or hardware object's WMI values and get it over with!
Saves memory, saves CPU time, allows smaller and more efficient plug-ins!

Original comment by ska...@yahoo.co.uk on 10 May 2011 at 2:30

[GoogleCodeExporter]

Hey mate. I've been looking into creating a solid tree structure *without* 
using the "identifier" string, which you proposed earlier.
However, if I am to create a tree structure based on "id"/"parent" relationship 
and using "hardwaretype" or "softwaretype" and "index", I think you need to 
include an "index" field for the "hardware" class as well.
I'm sure you can see the reason behind this; I can't recreate something like 
"/hdd/2" if I don't have the enumeration of all the "hdd" objects, unless I do 
the enumeration myself, in which case there's no guarantee that it will be the 
same as OHM.
So, all in all, yeah, I guess I need an index for hardware objects. Or the full 
path in a string.
Cheers.

Original comment by ska...@yahoo.co.uk on 26 Aug 2011 at 7:31