WindowWise

No AC? WindowWise tells you exactly when to open or close your windows, using live weather and air quality to cool your room for free and keep polluted air out.

Comment

Inspiration

As a student living in a hostel without air conditioning in my room, my window is my only cooling system. But I never knew when to open it. Open it in the afternoon and hot air pours in. Open it on a smoggy evening and the room fills with PM2.5. Open it before a storm and my desk gets soaked.

Weather apps didn't help. Temperature is on one screen, AQI on another, rain chance on a third, and none of them answer the question I actually have: should my window be open right now, and when should I change it? Millions of students in hostels, PGs and shared flats across India face the same choice every day, so I built the app I wanted.

What it does

WindowWise turns live weather and air-quality data into one clear answer.

  • Search your city or use your location, and you get a big verdict: "Open your window" or "Keep your window closed", with the reason and when to change it (e.g. "Close it at 08:00: outside is hotter").
  • A 24-hour plan as a colour strip and plain-language blocks, each with its reason: cooler outside, hotter outside, rain, poor air, or too cold.
  • A chart of the benefit, comparing my room temperature if I follow the plan with keeping the window shut, e.g. "your room should peak around 26°C instead of 29°C, with no AC."
  • Bad-air day mode: when pollution keeps the window shut all day, it finds the least-polluted hour to air the room out for 10–15 minutes, because rooms still need fresh air.
  • Personal settings: current room temperature, comfort range, and a stricter air limit (AQI 50 instead of 100) for people with asthma or allergies.

No sign-up, no API keys, and it works on any phone browser.

How I built it

WindowWise is a plain JavaScript, HTML and CSS app built with Vite, with no frameworks, so it loads fast on slow hostel Wi-Fi.

Data. I used three free Open-Meteo APIs: Geocoding (city search), Forecast (temperature, feels-like, humidity, rain chance, wind) and Air Quality (US AQI and PM2.5). I merge them into one record per hour, starting at the current hour in the place's timezone rather than the browser's.

Decision engine. Each hour goes through a fixed order of checks: rain → air quality → too cold → cooler outside (open) → hotter outside (closed) → about equal (open for fresh air). The order matters because the rules conflict. Cool but polluted air should still mean "closed".

Room model. To compare outside with the room, I needed an indoor temperature, so I simulate one hour by hour:

$$ T_{\text{room}}^{(t+1)} = T_{\text{room}}^{(t)} + k\,\big(T_{\text{out}}^{(t)} - T_{\text{room}}^{(t)}\big) + S^{(t)} $$

where $k = 0.5$ when the window is open (the room quickly follows outside air), $k = 0.08$ when it is closed (slow leakage), and $S = 0.35\,^\circ\text{C}$ per hour of solar gain for a closed room during the day. I run the same model twice, once following the plan and once with the window always shut, and the gap between the two peaks is the "degrees saved" headline.

Interface. I drew the chart as inline SVG, added light and dark mode, keyboard focus styles and screen-reader labels for every hour, and saved settings in local storage.

Quality and deployment. I wrote 19 Vitest unit tests for the decision rules, room model, data merging and least-polluted-hour logic. GitHub Actions runs the tests, builds the app and deploys it to GitHub Pages on every push.

Challenges I ran into

  • Conflicting signals. Combining the data into one decision was much harder than displaying it side by side. Early versions opened the window on cool but smoggy nights. Setting a strict priority order fixed that.
  • AQI barely changes hour to hour. My first bad-air tip always picked the current hour as "least polluted". It turned out US AQI is a 24-hour rolling average, so it can't identify the best hour. I switched to ranking by hourly PM2.5, which varies through the day.
  • Timezones. Forecast times are local to the city, but JavaScript's Date uses the browser's timezone, which skewed the daytime solar-gain logic. I now read the hour directly from the timestamp.
  • Making the model believable. A real thermal simulation would need room size, insulation and orientation that users don't know. I chose a simple model I can explain in one equation, and I state its limits.
  • Small UI bugs found in testing, like the search results list not hiding (a CSS display rule overrode the hidden attribute).

Accomplishments that I'm proud of

  • It gives one clear, useful answer instead of another dashboard of numbers.
  • The plan vs. window-shut comparison makes the benefit visible in degrees, not just advice.
  • Bad-air day mode handles a situation most weather apps ignore, and it matters a lot in Indian cities in winter.
  • It works with live data for any city in the world with zero API keys or accounts, is fully tested, and deploys automatically.

What I learned

  • How air-quality indices work: US AQI is an average built for health guidance, while PM2.5 shows what's happening right now.
  • That the order of decision rules is a design decision, not just a technical one.
  • How to model a physical process simply enough to explain, and how to be honest about its limits.
  • Setting up a full test-and-deploy pipeline with GitHub Actions and Pages.
  • I used Claude (Anthropic's AI assistant) via Claude Code as a coding partner while building this. It helped me move faster on code, tests and documentation, while I focused on the decision logic and testing it against real cities.

What's next for WindowWise

  • Notifications: a push reminder like "Open your window now. It's 4°C cooler outside."
  • Room calibration: learn my room's real behaviour from a few temperature readings, or from a cheap Bluetooth sensor.
  • Room orientation and fans: account for a sun-facing window and whether a fan is running.
  • Pollen and local sensors: add pollen where available, and use nearby ground sensors (e.g. CPCB stations) for more accurate air data.
  • Hostel mode: one shared plan for a whole floor or building, sent by the warden or a student council.
  • Languages: Hindi and other regional languages so more people can use it.

Built With

Share this project:

Updates

Submission history