It's been a while since I updated this blog, but I have some very exciting updates!!
After trying a few different testing methods and following some rooms through the process, I realized that I had been going off of an old version of my program when examining the output. In the newer version of my code, the low_co2 spreadsheet (which has now been renamed sensor_issues in order to avoid another misunderstanding of this nature) designates rooms with possible sensor issues in temperature and/or CO2, not just CO2. In addition, it is filtered such that if a room has a potential temperature sensor issue, it won't appear in the warm or cold spreadsheets due to the data being unreliable, but it may still appear in the CO2 spreadsheet assuming there's no issue with the CO2 sensor, and vice versa. This means that rooms in the low_co2 spreadsheet that are there because of a temperature sensor issue may still appear in the high_co2 spreadsheet, but those that are there because of a CO2 sensor issue will not. This explains the issue from the earlier post and provides a lesson on the importance of both maintaining and frequently referencing quality documentation. After confirming the validity of the spreadsheet data, I was then able to connect it to the visualization aspect, which involved debugging several data type errors and other issues of that level. The report now runs successfully from start to finish (apart from a minor issue with an extra line appearing on some of the graphs - EDIT: this was fixed by adding in an additional sort!). This stage of the project has been a great learning process, both in terms of the difficulties of integrating different systems and the importance of keeping up with good practice as a software developer. Comments are closed.
|
AuthorI'm a high school senior and programming enthusiast. Archives
March 2022
Categories |