Houston Weather Monitor

Weather App

The Houston Weather Monitor is a Python web application that automatically monitors the current temperature in Houston, Texas. The application retrieves weather data from the Open-Meteo API every 15 minutes, compares the current temperature to the previous reading, and displays the results through a Flask web interface. The application was designed to identify significant temperature swings of 3°F or more while also recording each scheduled temperature check.

Used Technologies

• Python
• Flask
• Requests
• HTML
• APScheduler
• Open-Meteo Weather API

How It Works

When the application starts, it records the initial Houston temperature as the baseline reading. APScheduler automatically executes the temperature check every 15 minutes. During each execution, the application sends a request to the Open-Meteo API to retrieve the current temperature. The current reading is compared with the previous temperature to determine whether a significant change has occurred.

If the temperature changes by 3°F or more, the application records the event as either a temperature climb or a temperature drop. If the temperature changes by less than 3°F, the application records that there was no major change. The updated log is displayed through the Flask web application and viewed in a browser at localhost:5000.

Features

• Automatically checks Houston weather every 15 minutes.
• Retrieves live weather data using the Open-Meteo API.
• Compares each reading with the previous temperature.
• Detects temperature swings of 3°F or greater.
• Displays all temperature checks and events in a browser-based user interface.
• Performs input and processing automatically without user interaction.

Future Improvements

The next version of the application will replace the Python scheduler with a Linux scheduling service such as cron or a systemd timer. Additionally, the in-memory weather log will be replaced with a SQLite database so that temperature history is preserved even after the application is restarted. These improvements will make the application more reliable and better suited for long-running deployment.

Trade-offs

APScheduler vs. cron/systemd: APScheduler is simple to implement because it runs directly inside the Python application. However, it stops if the application or SSH session ends. A Linux scheduler such as cron or a systemd timer is more reliable for long-running applications because it continues running independently of the Python process.

In-memory storage vs. SQLite: Storing temperature logs in memory is fast and easy to implement, but all data is lost when the application stops or restarts. SQLite stores the data on disk, allowing the application to preserve temperature history between restarts.

Polling interval: Checking the weather every 15 minutes reduces API requests and system resource usage, but rapid temperature changes that occur between checks may not be detected immediately. A shorter polling interval would provide more frequent updates but would increase API usage and processing.

Alternatives

SQLite Database: Instead of storing logs in memory, SQLite can permanently store all weather readings and temperature swing events.

cron or systemd Timer: Instead of APScheduler, Linux scheduling services can execute the weather polling script every 15 minutes, making the application independent of the Flask process.

Other Weather APIs: Although Open-Meteo was selected because it is free and does not require an API key, services such as OpenWeatherMap or WeatherAPI could also be used to retrieve weather data.

PostgreSQL: For larger applications with multiple users, PostgreSQL could replace SQLite to provide a more scalable database solution.

Changing Time to CST

Initially, the application displayed timestamps using the server’s default time settings, which did not match the desired Central Standard Time (CST) format. To ensure all weather logs were recorded in a consistent timezone, the application was updated to explicitly generate timestamps in CST before storing them in the SQLite database.

The timestamp is generated inside the check_temperature() function in weather_monitor.py. Instead of using the system’s default clock, the application explicitly creates a timezone object representing CST (UTC−6) and formats the date and time before storing the weather reading.

This change ensures that every database record is stored in the same format, regardless of the operating system’s local timezone or the server’s configuration. As a result, the web application always displays timestamps in a consistent and predictable format, making the weather log easier to interpret and compare over time.

Blocker

The first blocker I encountered was that some logs were not appearing in CST. After troubleshooting, I discovered that previous processes were still running on the same ports, which were overriding my original browser session. To resolve the issue, I reset the logs in the database file and restarted the application using pkill –f app.py

The second issue was my own impatience. Instead of allowing the application enough time to run, I kept modifying the methods to try to meet the 15-minute duration requirement. I also attempted to force my own start time, which caused the timestamps to become inconsistent (11-minute instead of the 15-minute logic). Once I stopped making unnecessary changes and allowed the application to run as intended, the results became consistent.

Trade-offs

Timestamps automatically reflect daylight saving time. While that approach is more accurate for real-world deployments, the fixed CST implementation better satisfies the project’s requirement for standardized timestamp formatting.

Baseline Swing

Previously, the application compared each new temperature reading to the previous reading. While this approach detected changes between consecutive measurements, it did not effectively identify meaningful temperature swings because small incremental changes were logged even when the overall temperature had not changed significantly.

To improve the monitoring process, the application was redesigned to use a moving baseline. The baseline is established using the first temperature reading and remains unchanged until the temperature changes by 3°F or more. Each new reading is compared to the baseline rather than the immediately preceding reading. If the difference is less than 3°F, the reading is stored in the database, but no swing is recorded, and the baseline remains the same. Once the temperature changes by 3°F or more, the application records a temperature swing, updates the baseline to the new temperature, and begins monitoring from that new reference point.

Alternatives

Previous Reading Comparison:

Compare each new reading to the immediately preceding reading.

Advantage – Simple to implement and continuously track changes between consecutive readings.

Disadvantage – Small fluctuations are repeatedly evaluated and may not represent meaningful changes in overall temperature trends.

Fixed Baseline:

Compare every reading to the original starting temperature.

Advantages – Simple reference point throughout execution.

Disadvantage – After a significant temperature change, all future readings continue to be compared against an outdated baseline, reducing the usefulness of later comparisons.

Trade-offs

Another design decision involved database storage. Every temperature reading is stored in SQLite, allowing a complete historical record to be preserved even though only significant swings are displayed in the user interface. This approach supports future analysis and debugging without overwhelming the user with minor temperature fluctuations.

Architecture Diagrams

AD

AD Chart