3 Replies Latest reply on Feb 13, 2013 8:51 PM by matthew.rivett

    Open Hardware Monitor


      Has anyone explored using the following code and writing the results to PI?  It collects computer hardware information including CPU temp, fan speeds, etc.




      The source code is freely available.  My initial thought was to import a library into ACE.  I haven't dug into the code that much but I think it will only retrieve information from the computer the code is running on.  That would limit it to my ACE server which is great but I'd want more.  My next idea would be to write a windows service to dump out a csv file and use UFL to load it into PI.


      They also expose the data through WMI if you leave their program running.  You could then use the WMI interface to load it into PI.  I'm not sure if I want to leave their program running all the time though.


      What would I do with this information?  I'm not sure.  It's just interesting to look at.  :)

        • Re: Open Hardware Monitor

          @Matt: I looked at their solution which is cool but I came to the conclusion that they are only leveraging the WMI classes to query the machine and they publish it back through their own WMI class in a simplified manner. Although, there is nothing they do you cannot do yourself by querying the different WMI instances of the local or remote computers.


          You have different options to collect the same information and push it to the PI System. You can use the PI WMI Interface that allows to query WMI sources, you cannot output anything as it is uni-directional. Three query methods are available: GetObject, ExecQuery and High Performance Refresh. The second option could be as you stated using PI ACE to programmatically access the WMI classes and write the values to the PI System. This requires a bit of management because you will need to map your output PI Points with the different items from the WMI queries. The third one is using a PowerShell script to extract information from given WMI sources and dump into *.csv file respecting a tag, time and value field structure, and  using the PI UFL interface to read the files. You can benefit from the auto-creation of point per this interface, leaving you free of managing them on the PI Data Archive. You simply need to generate unique tag name in your file to insure events go to the right location.


          IMHO, I prefer the third option because it leaves you a lot of flexibility on how to handle conversion of returned events from the WMI sources and/or cascading to query subsequent classes if one is missing for a given hardware. Furthermore, querying WMI sources from PowerShell is pretty straight-forward. I gave an example of script you could use here.


          You can obtain all the information regarding WMI classes with this link.

            • Re: Open Hardware Monitor

              Thanks Mathieu.  


              I'm letting the GUI run on my desktop and am collecting data via their WMI values.  I read up on it a little and there is some issue that prevents the code from collecting all the data (gpu data when running Windows 7) unless it's running as a logged in user.




              I don't have a good use case for this data.  I just saw time series data and wondered how to put it into PI.  We could monitor temps, fan speeds, voltage etc on the servers but I think that is a little excessive.  Especially since many of our servers are virtual and the information would probably be useless.  Being a geek having a display showing a motherboard with fans, voltages, temperatures, etc on it would be cool but not worth the effort.  :)