Logging to txt file

[GoogleCodeExporter]

A useful option that would be welcome in OHM.

Original issue reported on code.google.com by furex.fu...@gmail.com on 24 Feb 2010 at 7:17

[GoogleCodeExporter]

Yes logging is very useful in general. I am not yet completely sure what the 
best way
is to log the data, and what needs to be configurable by the user. What is a 
good
file format? At which intervals should sensors be logged. Should all sensors be
logged, or only those selected by the user?

Original comment by moel.mich on 24 Feb 2010 at 7:45

• Changed state: Accepted
• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I wanted logging and started to add, before I thought to look at the issues 
list -
where I see there is already this request.

I have taken a simple approach logging, with some user options on menu, and some
options that have to be edited in the configuration file.

I intend to expand to log static information separately and to check/log if it 
does
ever change.

This is a great tool, especially providing motherboard, CPU, GPU information 
and fan
and voltage information. Most similar tools do not do all these or say they do, 
but
fail to retrieve all the data!

Testing on Windows XP & Win7 provides excellent results, and it is very 
pleasing to
see it works well on Win7. I notice that http://openlibsys.org/ say that 
WinRing0 is
now closed. Do you know anything about the future of this component, especially 
under
Win7?

I am also interested in temperature and fan alerts, as well as fan speed control
features. If you are willing I am keen to assist you develop these features, or
create them myself and contribute to your project.

I have attached my work-in-progress exe and would like to contribute to your 
project.
 I can be contacted at ourstuff888 at gmail . com

Original comment by ourstuff...@gmail.com on 15 Apr 2010 at 12:40

Attachments:

• OpenHardwareMonitor.exe

[GoogleCodeExporter]

It's nice to see someone actually using the source code. :)

To log data to a file, you should not run your own update timer. Some hardware 
(like
the T-Balancer) can't handle calls to Update more than once per second, while 
other
relies on the Update being made once per second (like harddisk SMART). This is 
not a
very well design atm, but it's not so easy to improve. The way it is right now, 
you
can assume all sensors to be well updated at all times.

As far as I understood from the Japanese WinRing0 page, the author has stopped
development on WinRing0, because now also single persons (and no longer 
employees of
companies only) can obtain a Code Signing License. So he does no longer see any 
need
for releasing new signed versions of WinRing0. I guess the development of the 
driver
has to continue as part of the Open Hardware Monitor project.

If you want to contribute to the project it is best to join me in the IRC 
channel
#hardware-monitor on irc.freenode.net. For larger contributions it might be 
best to
discuss the overall design first. 

Original comment by moel.mich on 19 Apr 2010 at 7:47

[GoogleCodeExporter]

Here is code for a first attempt at logging.  It is based on version 0.1.33, 
and it
is labeled as 0.1.33.1

Original comment by ourstuff...@gmail.com on 3 May 2010 at 12:43

Attachments:

• [open-hardware-monitor -V0.1.33.1 logging.7z](https://storage.googleapis.com/google-code-attachments/open-hardware-monitor/issue-7/comment-5/open-hardware-monitor -V0.1.33.1 logging.7z)

[GoogleCodeExporter]

Thank you very much.

I have reviewed your code, and there are a few problems which prevent me from 
just
checking it into the svn:

- The logic (timer_Tick, logDataMenuItem_CheckedChanged) and state (skipFirst,
logIntervalDefault, logInterval DefaultDate, ....) used for logging currently 
in the
MainForm class has to be moved into its own class. 

-  Everything in the OpenHardwareMonitor.Hardware namespace (and below) should 
only
be code directly used to read sensors and represent the current sensor and 
hardware
configuration. Code that just operates on the hardware/sensor/parameter tree by
everything accessible from the IComputer interface should not be in the
OpenHardwareMonitor.Hardware namspace. This means that any data logging code
shouldn't be in the Computer class either. This applies to the methods
ReportHardwareTree, ReportHardware and GetReport of the Computer class as well. 
The
reports code is a bit a special case, because sensors needs to have a hardware
specific GetReport method. But when I now look at it, everything about Reports 
in the
Computer class shouldn't be there either. Maybe the visitor pattern could be 
used to
implement general operations on the tree.

- The data logging strategy does not really handle changes in the sensor
configuration very well. Right now it uses workarounds for cases when sensors 
appear
for the first time only after some time. The data logging should handle 
appearing and
disappearing sensors. Possible solutions: Let the user choose which sensors are
logged to a file. If a sensor is not pressent, just an empty string or "-" is 
logged
for that sensor. Sensors can be identified with ISensor.Identifier. Or data 
logging
uses a header file with just one header of ISensor.Identifiers. Every new 
sensor (one
that does not appear in the current header) just allocates a new column in the 
data
logging file at the end of the current configuration (and adds itself to the 
header).
Disapearing sensors will be logged just as empty (as above). The data csv would 
not
contain any header (or it will have to be updated after every change).

- The InternalConfig is not needed. The application version can just be 
accessed from
anywhere in the code already, and the rest is logging specific code (and should 
be
moved to corresponding classes). Some of the functions could be properties as 
well.

Original comment by moel.mich on 3 May 2010 at 5:11

[GoogleCodeExporter]

Is there any progress on implementing logging to a text file to the OHM? I 
would be very nice feature. Right now as I know only 2 simmilar applications 
has this functionality. First is HWMonitor Pro and second is HWiNFO32. First 
one is very buggy (not all sensors are visible, not all are working). In 
HWiNFO32 it is really nice implemented. All data is logged to simple CSV file. 
Just import that to Excel and create pivot table and you have got all you need 
to analyze temperatures, voltages and fan speeds. I'm missing same 
functionality in OHM.
Eventually you can grab data from plot. It has historical data so probably 
values are already stored somewhere - just dump them (or I'm wrong - sorry I'm 
not a programmer). However, only temperatures are logged on plot...

Original comment by winiarsk...@gmail.com on 29 Dec 2010 at 12:38

[GoogleCodeExporter]

idea... implement shared memory... all modern software these days use it...
make 
an array for names of the objects
an array for the values
and an array for the current number of objects...
its really easy... logging to file causes lots of problems especially for the 
program using it... windows vista and 7 have a limit on how fast you can access 
a file and it will error out in some cases...

Original comment by thor200...@gmail.com on 4 Mar 2011 at 12:29

[GoogleCodeExporter]

The logging to text file is not intended to be used as interface for realtime 
access to the sensor data. The main applications for a logging implementation 
are storing and archiving sensor data, or post processing recorded data. It can 
be used also as a persistent record of sensor data when the PC freezes for 
example. 

For realtime sensor data access there is Issue 62. Currently the data gets 
exported to WMI and can be read from other processes. Documentation of the WMI 
interface: http://ohm.werelds.net/OpenHardwareMonitor-WMI.pdf

Original comment by moel.mich on 4 Mar 2011 at 12:44

[GoogleCodeExporter]

For any log, i use Log4Net : http://logging.apache.org/log4net/
All parameters are in the app.config.
You can choose what level (debug, warning, error, ... ) you log, where you log 
(txt, mail, BDD, ...)
You have a lot of options.
In the code you just add a private variable 'Log' and use it everywhere in the 
project.
like this : 
Log.DebugFormat("My var sample has {0} value",sample);
Log.Error("Error in the module ...", Exception);

I've just discovers your project, so i can't modify it right now, i've to 
understand the code first.

Original comment by zergman....@gmail.com on 8 Jul 2012 at 8:12

[GoogleCodeExporter]

to resume my previous post : 
http://logging.apache.org/log4net/release/features.html

Original comment by zergman....@gmail.com on 8 Jul 2012 at 8:13

[GoogleCodeExporter]

Open-hardware-monitor was very useful for me especially as I monitor the 
temperatures of a remote pc which makes some measurements in a hot environment 
(I optimized the cpu power so that the cpu fun can hold the temperature under 
limit values. However, I realized that a maximum of 24h history plot is 
restrictive. A logging option would be perfect.).

Actually, it should be very simple. the data which is used for plotting 
diagrams should be processed and written to some log-files. The only needed 
parameter is the time interval. In my opinion the log-file should contain all 
the data which is used for plotting, a header line which describes each column 
(i.e. Date-Time; T_cpu_core1; T_cpu_core2, etc). To avoid very large log files 
the number of lines in the log file can be limited (N=10000, or some large 
number) and  if limit reached starts a new log file. Log file name can contain 
a date/time (i.e. 2012_12_31_24h_59m.log).

Regards,
Dr. Kaymak

Original comment by yalcin.k...@gmail.com on 2 Oct 2012 at 7:19

[GoogleCodeExporter]

Just a thought, since this is in .net, using nlog would make it very easy to 
log, probably by just one liner at the UI update thread. And then a custom 
logger can be written so that "what to log" can be configured from nlog.config 
itself, that will remove all the burden on the main program.

Original comment by faulty....@gmail.com on 28 Feb 2013 at 3:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I concur with Zergman, log4net (similar to log4j) is a powerful, versatile and 
user configurable tool for text logging. Taks care of everything: log levels, 
file size, rotations, etc, etc... 
Yet, nlog looks great too. Just don't reinvent the wheel!

Original comment by eric.voi...@gmail.com on 10 Mar 2013 at 4:48

[GoogleCodeExporter]

Logging to txt files would be very useful in case of BSODs. So you can see the 
temps before the shit happened.

Original comment by usa.alan...@gmail.com on 17 Mar 2013 at 3:30

[GoogleCodeExporter]

I think a good way would be to log it to a database (SQLite or something 
similar), each record can just have a column for each piece of hardware 
(selectable by the user?)

That way, each row can be a point in time (1/5/x second intervals) with a unix 
timestamp as the first column. Then you could output that to a graph program 
etc or read the last record to see where the system failed.

Which is what I need, my system shuts off when playing high graphic games and 
I'm trying to figure out exactly what is going on, if it's overheating I want 
to find out which part is, so I need the monitor program to log the data, then 
I can just switch it back on, look at the last log entry and see which part is 
over it's recommended heat.

Original comment by jaz636 on 17 Jun 2013 at 6:46

[GoogleCodeExporter]

I have created a first alpha version with logging support:

http://openhardwaremonitor.org/files/openhardwaremonitor-v0.6.0.8-alpha.zip

For every day a new logging file is started. All sensors are logged that are 
present when the log file is started. If a sensor disappears it will not be 
logged until the Open Hardware Monitor is restarted or a new day starts (as 
each day starts with a new sensor enumeration).

The log file is a simple comma separated table. The first line contains the 
sensor ids, the second line the sensor names and all following lines the sensor 
values. The first column contains the time.

Original comment by moel.mich on 11 Aug 2013 at 9:23

• Changed state: Started

[GoogleCodeExporter]

The logging feature is great and I'm using it.  However, would it be possible 
to set the logging interval in the config file?  The current interval of one 
second makes the log file grow in size rather quickly.  Thanks, and keep up the 
good work!

Original comment by orionus...@gmail.com on 15 Aug 2013 at 8:20

[GoogleCodeExporter]

Issue 497 has been merged into this issue.

Original comment by moel.mich on 18 Aug 2013 at 9:38

[GoogleCodeExporter]

Issue 496 has been merged into this issue.

Original comment by moel.mich on 18 Aug 2013 at 9:39

[GoogleCodeExporter]

A new version that should fix the exceptions.

http://openhardwaremonitor.org/files/openhardwaremonitor-v0.6.0.9-alpha.zip

Changed the way reappearing sensors are handled. If they have been available 
when the log file was created, then they are written to the log file as well.

Original comment by moel.mich on 18 Aug 2013 at 9:46

[GoogleCodeExporter]

Issue 449 has been merged into this issue.

Original comment by moel.mich on 25 Aug 2013 at 6:57

[GoogleCodeExporter]

A new alpha version that allows the logging interval to be configured (Options 
-> Logging Interval).

http://openhardwaremonitor.org/files/openhardwaremonitor-v0.6.0.10-alpha.zip

Original comment by moel.mich on 25 Aug 2013 at 7:11

[GoogleCodeExporter]

how are the logged values computed within the interval time, is it 
instantaneous values or mean values?

Original comment by aktaru...@caramail.com on 26 Aug 2013 at 11:37

[GoogleCodeExporter]

At the moment instantaneous values are logged (as this is simpler to implement).

Original comment by moel.mich on 26 Aug 2013 at 12:28

[GoogleCodeExporter]

Could we allow this to load the saved data in the graph between restarts?

Original comment by entityreborn on 31 Aug 2013 at 9:33

[GoogleCodeExporter]

Hi,

Any idea when the logging feature will make it into the 'current' version?

For some reason, if I try any version after v0.6.0-beta, the app just will not 
start.

Double clicking on the exe just starts the app (I dont see any GUI part of the 
app, I just briefly see the .exe in my process list), and then it exists 
immediately.

I´ve tried all newer versions up to v0.6.0.11 with the same effect.

Thanks,

Rob.

Original comment by robertdo...@gmail.com on 10 Nov 2013 at 8:08

[GoogleCodeExporter]

I am NOT able to see the created log file. Which location the log file is 
generally created ? I am using v-0.6.0.10-alpha. I am able to see the GUI but I 
am not finding the log file. How to check whether log file is created or NOT ?

Original comment by rambling...@gmail.com on 8 Apr 2014 at 11:38

[GoogleCodeExporter]

The logfile is in the program directory and is called 
OpenHardwareMonitorLog-*date*, works fine here.

Original comment by sebfield...@gmail.com on 1 Jul 2014 at 11:10

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Any chance this will make it into the next release soon?

If you stop and start logging on the same day as part of a series of tests, it 
would be nice to have the files named differently to not confuse test results.

It would also be nice to set the logging directory.

Thanks,
--H

Original comment by hzselt...@gmail.com on 1 Dec 2014 at 11:57