PLEASE NOTE THE WEB INTERFACE IS NOT YET COMPLETE. IT WILL BE DONE SHORTLY. I DO NOT KNOW WHEN, BUT SOON. WHEN IT IS DONE, THAT WILL BE VERSION 1.0
ALSO NOTE THIS IS WRITTEN IN PYTHON 2.7. I AM AWARE THAT IT IS BEING PHASED OUT AND WILL BE CONVERTING TO PYTHON 3.X IN THE NEAR FUTURE.
- PyWebTelemetry - The AIO PC Remote Monitor
- PyWebTelemetry is a Web Based, Python Powered, PC Monitor using MSI Afterburner (AFB) and RivaTuner Stats Server (RTSS) to read live PC temps and usages which are shown on a remote webpage.
- This program was designed with the intention to allow wireless PC monitoring as simply as possible. This program is in it's earliest stages, so if (and when) you find a bug, please report it!
- I am aware there are other potentially more direct ways to accomplish what this code does, but since this program uses AFB or RTSS, there is a potential for cross platform compatability with some very small changes later on. For now this program will be Windows only. (Tested on Win10 and Win8.1)
Each folder is pretty self explanatory but to avoid confusion, I'll explain what each one is for here.
- Folder containing all Python Scripts that are finalized and released to the public. Since the program itself will be wrapped inside an EXE, all the source code that goes into the EXE file can be found in there.
- This is basically a working directory. Any code that needed to be written and tested before being added into a final script can be found here. A lot of that code is heavily commented and really REALLY messy.
- Empty for now. When a stable version of the program is ready, it will be compiled and uploaded in this folder and marked as a release. If there is a version of the code you wish to run as an EXE, everything in this repo can be compiled by yourself. For instructions on that, consult the allmighty Google search bar.
- Any bugs that I find, or any bugs that are reported will be written up and the issue will be documented.
- If a solution is found, the file linked to that bug will be updated to include it.
The following will explain how this program takes a .hml file generated by AFB or RTSS and converts that into easy to view data.
- Inform user of the requirements for this program including a warning about log files outside the home directory.
- AFB and/or RTSS must be running at all times for logging
- Show the default log location and check to see if the program is running as an admin.
- Ask if user wants debug logging (ON BY DEFAULT!!!! AND WILL DELETE ON RESTART OF PROGRAM)
- Get path of .hml file from the user and check if the file exists or not using the OS module
- If it's real check what's inside it for the user
- If not, then keep asking for new location
- TODO: See if there's a way to look for AFB or RTSS as a process and warn if it's not on or even start it.
- Read the HML log file as a CSV since it's kinda like one
- Ignore colls 1 and 2 for the log since they are useless.
- Read coll titles and save them. (REMOVE WHITESPACES. IT WILL CAUSE AN ISSUE!!!!)
- Save the coll titles, delete the .hml to CSV we made to read monitors
- NOTE: The converted file is deleted so we can avoid chewing up disk space. Doing this uses more disk resources, but it wont risk storing a massive amount of data. If this process is not done, we risk doubling disk use when logging to the web.
- Wait one second (literally) and read the log again from the last line it has and save it.
- NOTE: This used to cause an error sometimes when we tried to pull data faster than the log file could be rewritten. This was solved using a try/except statement when reading the monitored values.
- Zip (combine) the two lists (monitors and their values) into a group of tuples and save that info. (This was modified in version 0.1.1)
- We then look to get idle temperatures.
- This is done by using a dictionary to lookup what index has which value in our values list.
- We find that usage value, then compare it to a threshold value. Assuming we pass this check, we look back at the dictionary to locate the index of that components temperature and log that as an idle temperatrue.
- This feature is not yet done but progress up to this point can be seen in the Test Programs directory.
- The program reads the values and checks them against two lists which contain mins and maxes. If there are new mins and maxes, they are logged and shown.
- Delete the log from AFB or RTSS. Rinse and repeat.
- NOTE: The log file from AFB is auto created when deleted. That's the only reason we can save disk space.
- The saved lists are then sent over the web to some kind of GUI page with graphs.
- TODO: Django web server??? Not sure how to do that.
- The lists are indexed and graphs are made using the data supplied.
- NOTE: The program seems like it's going to have a pretty big delay (1-2 seconds) which isn't a huge deal but it may be kinda annoying.
- TODO: Precision of measurements, units of measure, avgs, idles, mins, maxes etc
- Graphs will have the current value for each monitor along with a history of the past 60 seconds of recording.
- TODO: This may be changed later on to allow the user to decide how far in the past the graphs will show.
- The Web interface hasn't even been started. So if anyone want's to try and get that working feel free.
Q1: When I run the program, I get an error saying that my log file does not exist but I konw it does. Why?
- The program looks for a log file in the default directory of MSI AFB which is in Program Files (x86). When it first runs, for some reason the program doesn't like to properly locate the log file and throws an error. In the event it does, just try to enter your path location again and it should be fine.
- If you continue to get an error, try running the program again as an admin. I am working on this right now and hope to include a feature later on that will elevate the program in the even the log is in a restricted location.
Q2: Why does monitoring stop randomly and claim that my log file no longer exists?
- This is an issue I'm really having a hard time with. Sometimes, AFB hangs up, and won't restart the logging process, thus no log file is made. I considered adding in an error exception for this case, but I didn't want to risk sending incorrect or invalid data to the webpage.
- UPDATE: I added the error exception to the code just for now. I'd like to figure out a real solution to this issue. Maybe some sort of timer that can check for the file over and over again. Not too sure yet, but the code works fine.
Q3: I really wish this program did feature 'X' and didn't do feature 'Y'. How can I help change that?
- Well this is GitHub and like all of my public repos, the code is protected by the MIT License. So feel free to fork away, pull, clone, whatever makes you happy. If there is a feature you would like added or removed but are not 100% sure how it would be done, ask! I'm not a very busy person so I'd gladly make some changes if people would like.
Q4: I found a bug, and I know (or dont know) how to fix it. Wat Do?
- If you find a bug (or so you think), open an issue and make sure to get my attention somehow. I'll look into it, and if the issue is truly a bug, the bug will be documented and added into the folder called Bug Documentation. If you find a solution for the bug, feel free to let me know. I'll fix as quickly as possible and provide credit for the solution.
This section will explain what's in store for this program and act as a log for development.
- Release Date: 6/27/2018
- EXE: Not built for this release (Too many potential changes in code)
- This is the most basic form of the program itself. Features logging and reading from the log files. Does not transmit data for wireless monitoring yet. Also contains the error exception for when data is requested too quickly.
- Release Date: 6/28/2018
- EXE: Not built for this release (No major features added, still WIP.)
- Version 0.1.1 adds in a feature which calculates the mins and maxes of the recorded values. It also cleans up the methods of reading the log and saving values. In V0.1, the values were saved in a list as a type String, but now I'm using floats so I can compare each pulled value.
- Release Date: TBA
- EXE: TBD (May or may not be built. Depends on how many changes are made)
- Version 0.2 will PROBABLY still be command line based, and will not have any GUI features. Wireless data transmission will be added along with a few small tweaks to the logged data for when the time comes to graph the data.