DEV Community: Petrichor

Build a "what to wear" dashboard in Python with a weather API

Petrichor — Thu, 10 Sep 2026 08:27:50 +0000

Turn an hourly forecast into three clothing recommendations a day

Every weather app tells you it will be 9 degrees. Almost none tell you what that means for your coat. This tutorial turns a weather API forecast into clothing advice, three times a day, in about a hundred lines of Python.

You get a recommendation for morning, midday and evening, based on a real hourly forecast for London. It runs on Python and Streamlit, and it fits comfortably inside the 10-day free trial of the Meteosource Standard plan.

One API call gets you the numbers. Fifty lines of opinion turn them into "wear a hood, not an umbrella."

What you'll need

Python 3.10 or later
A Meteosource account on the Standard plan. The 10-day trial is free and needs a card; cancel inside the ten days and you are not charged. It includes 20,000 calls a day, and this dashboard uses a couple of dozen.
Fifteen minutes

Create a virtual environment and install what we need:

python3 -m venv venv            # Windows: python -m venv venv
source venv/bin/activate        # Windows: venv\Scripts\activate
pip install streamlit "pymeteosource[pandas]"

We are using the official Python wrapper, pymeteosource, rather than calling the endpoint directly. It handles timezone conversion and exports straight to pandas, which saves us most of the plumbing.

Step 1: Pick the right variables

The obvious variable is temperature. It is also the wrong one.

What you feel standing at a bus stop is feels_like, which folds in wind and humidity. Ten degrees in still air and ten degrees in a 40 mph gust are different clothing problems, and only one of those two numbers knows it.

Three variables do most of the work. feels_like sets the base layer, wind.gusts decides whether a knit jumper is enough, and precipitation.total and probability.precipitation between them separate "it is raining" from "it might rain, take the small umbrella." We also use uv_index and humidity for two smaller rules later on.

Here is a trimmed single hour of the forecast, showing only the fields we use:

{
  "date": "2026-08-24T08:00:00",
  "feels_like": 15.8,
  "wind": { "speed": 2.9, "gusts": 3.7 },
  "uv_index": 0.4,
  "precipitation": { "total": 0 },
  "probability": { "precipitation": 0 },
  "humidity": 62
}

Two notes on what those numbers mean. precipitation.total is rain accumulated over that hour in millimetres, not an instantaneous rate. And we will request the uk unit system, which gives temperatures in Celsius and wind in mph. That is how a British reader thinks about wind, and getting the unit system wrong is the fastest way to build a dashboard that confidently gives terrible advice.

Step 2: Write down your opinions

Put the rules in their own file. This is the part you will actually tune, and it should not be tangled up with API calls or layout.

Create wardrobe.py:

"""Turn a weather slot into clothing advice.

Thresholds assume the `uk` unit system: Celsius, mph, mm."""

# feels_like (C) -> base layer. Upper bound of each band, exclusive.
LAYERS = [
    (-5, "Thermals, heavy winter coat, hat and gloves. Cover your face."),
    (2, "Winter coat, hat, gloves, scarf."),
    (8, "Warm coat and a scarf. Long sleeves underneath."),
    (14, "Light jacket or fleece over a long-sleeve top."),
    (19, "Long sleeves, or a t-shirt with something to put on later."),
    (25, "T-shirt weather."),
    (999, "Lightest, loosest thing you own."),
]

GUSTS_BREEZY = 20       # mph, noticeable
GUSTS_WINDPROOF = 30    # mph, a knit layer stops working
GUSTS_NO_UMBRELLA = 40  # mph, umbrellas turn inside out

RAIN_LIGHT = 0.2        # mm in the hour, drizzle
RAIN_HEAVY = 2.0        # mm in the hour, properly wet
PROB_UMBRELLA = 30      # %, worth carrying one just in case

UV_SUNGLASSES = 3       # UV index at which sun becomes a factor
MUGGY_HUMIDITY = 75     # %, combined with warmth


def base_layer(feels_like):
    for ceiling, advice in LAYERS:
        if feels_like < ceiling:
            return advice
    return LAYERS[-1][1]


def recommend(feels_like, gusts, rain_rate, rain_chance,
              uv_index, humidity):
    """Return (headline, notes) for one time slot.

    Wind and rain can only push the recommendation upward. Being
    slightly too warm is recoverable. Being cold and wet is not.
    """
    notes = []

    if gusts >= GUSTS_WINDPROOF:
        # feels_like already accounts for wind, but it uses mean wind
        # speed, so a gusty day is colder than it claims. We push it
        # down once more, deliberately.
        headline = base_layer(feels_like - 2)
        notes.append(f"Gusts to {gusts:.0f} mph. Windproof outer layer, "
                     "not a knit.")
    elif gusts >= GUSTS_BREEZY:
        headline = base_layer(feels_like)
        notes.append(f"Breezy, {gusts:.0f} mph gusts. Something that "
                     "closes at the front.")
    else:
        headline = base_layer(feels_like)

    if rain_rate >= RAIN_HEAVY:
        notes.append("Heavy rain. Waterproof, and shoes you don't mind "
                     "ruining.")
    elif rain_rate >= RAIN_LIGHT:
        notes.append("Drizzle. A shower-resistant layer is enough.")
    elif rain_chance >= PROB_UMBRELLA:
        notes.append(f"{rain_chance:.0f}% chance of rain. Take the small "
                     "umbrella.")

    if rain_rate >= RAIN_LIGHT and gusts >= GUSTS_NO_UMBRELLA:
        notes.append("Too windy for an umbrella. Wear a hood.")

    if uv_index >= UV_SUNGLASSES:
        notes.append(f"UV index {uv_index:.0f}. Sunglasses, and sunscreen if "
                     "you are out for more than half an hour.")

    if humidity >= MUGGY_HUMIDITY and feels_like >= 22:
        notes.append("Muggy. Natural fibres will be kinder than synthetics.")

    return headline, notes

Two decisions in there are worth spelling out, because they are the difference between advice and noise.

Wind and rain only ever push upward. The errors are not symmetric. Being slightly overdressed is an annoyance you can fix by taking something off. Being underdressed in cold rain is a ruined afternoon.

Rain plus real wind means a hood, not an umbrella. This is the rule that makes people trust the thing. Anyone who has fought an umbrella down a windy street already knows it, and seeing a dashboard know it too is what makes it feel like it was built by someone who goes outside.

Step 3: Split the day into three

Now the app. Create app.py:

import os
from datetime import datetime
from zoneinfo import ZoneInfo

import streamlit as st
from pymeteosource.api import Meteosource
from pymeteosource.types import tiers, sections, units

from wardrobe import recommend

API_KEY = os.environ.get("METEOSOURCE_API_KEY", "YOUR-API-KEY")
TIER = tiers.STANDARD
PLACE_ID = "london"
TIMEZONE = "Europe/London"

# Each slot is a window, not a single hour. It rains at 08:30 and not
# at 07:00, and you still get wet.
SLOTS = [
    ("Morning", range(7, 10)),
    ("Midday", range(12, 15)),
    ("Evening", range(18, 21)),
]


@st.cache_data(ttl=1800)
def load_forecast():
    """Fetch the hourly forecast once. Cached, so a refresh is free.

    We slice one response into three slots rather than making a
    request per slot.
    """
    ms = Meteosource(API_KEY, TIER)
    forecast = ms.get_point_forecast(
        place_id=PLACE_ID,
        sections=[sections.HOURLY],
        tz=TIMEZONE,      # the library defaults to UTC, so be explicit
        units=units.UK,   # Celsius, but wind in mph
    )
    return forecast.hourly.to_pandas()


def summarise(window):
    """Collapse a window of hours into one worst case.

    Coldest hour, strongest gust, wettest hour. Dressing for the
    average of a window is how you end up cold in it.
    """
    return dict(
        feels_like=window["feels_like"].min(),
        gusts=window["wind_gusts"].max(),
        rain_rate=window["precipitation_total"].max(),
        rain_chance=window["probability_precipitation"].max(),
        uv_index=window["uv_index"].max(),
        humidity=window["humidity"].max(),
    )


st.set_page_config(page_title="What to wear", layout="centered")
st.title("What to wear in London")

# Today according to the forecast location, not according to your laptop.
today_local = datetime.now(ZoneInfo(TIMEZONE)).date()
st.caption(f"{today_local:%A %d %B}")

try:
    df = load_forecast()
except Exception as exc:
    st.error(f"Could not load the forecast: {exc}")
    st.stop()

today = df[df.index.date == today_local]

if today.empty:
    st.warning("No hours left for today. Come back tomorrow morning.")
    st.stop()

for label, hours in SLOTS:
    window = today[today.index.hour.isin(hours)]

    if window.empty:
        continue

    conditions = summarise(window)
    headline, notes = recommend(**conditions)

    st.subheader(label)
    st.markdown(f"**{headline}**")
    for note in notes:
        st.markdown(f"- {note}")
    st.caption(
        f"Feels like {conditions['feels_like']:.0f}°C, "
        f"gusts {conditions['gusts']:.0f} mph, "
        f"{conditions['rain_chance']:.0f}% chance of rain"
    )

with st.expander("The whole day, hour by hour"):
    st.line_chart(today[["temperature", "feels_like"]])
    st.dataframe(today[["feels_like", "wind_gusts", "precipitation_total",
                        "probability_precipitation", "uv_index"]])

One thing to watch: pymeteosource returns UTC by default, so set tz to your own timezone or the slots drift by an hour or more. Work out "today" in that same timezone and it stays right wherever you run it.

Step 4: Run it

export METEOSOURCE_API_KEY='your-actual-key'
streamlit run app.py

On a typical London day you get something like this:

Morning — Warm coat and a scarf. Long sleeves underneath.

Drizzle. A shower-resistant layer is enough.
Feels like 6°C, gusts 18 mph, 75% chance of rain

Midday — Light jacket or fleece over a long-sleeve top.

Breezy, 24 mph gusts. Something that closes at the front.
Feels like 12°C, gusts 24 mph, 20% chance of rain

Evening — Warm coat and a scarf. Long sleeves underneath.

Gusts to 41 mph. Windproof outer layer, not a knit.
Heavy rain. Waterproof, and shoes you don't mind ruining.
Too windy for an umbrella. Wear a hood.
Feels like 8°C, gusts 41 mph, 95% chance of rain

Three genuinely different answers for one day, which is the entire point. A dashboard that says "wear a jacket" no matter what you feed it is not worth opening.

A word on thresholds

There is no correct answer here. Some people are cold at 15 degrees and some are fine in a t-shirt. Every number in wardrobe.py is a guess, which is exactly why they are all constants at the top of the file rather than scattered through the logic.

Wear it wrong twice, adjust the number, and it becomes genuinely yours. That is a better outcome than a polished app that is confidently wrong about your particular metabolism.

Where to go from here

Change the city. place_id accepts names, or swap in lat and lon for anywhere in the world. Change TIMEZONE to match, or the slots will drift.

Add tomorrow. The Standard plan returns seven days of hourly data, so a second tab costs no extra API call.

Send it somewhere. The logic has no dependency on Streamlit. Wrap recommend() in a scheduled script and push the morning slot to your phone at 07:00, which is the point at which you actually make the decision.

Doing this on the free plan

The free plan's hourly forecast covers 24 hours and gives you temperature, wind.speed, cloud_cover.total and precipitation.total — but not feels_like, wind.gusts or probability.precipitation. The rules still work with a bit of rewiring: calculate wind chill yourself, key the wind advice off sustained speed with lower thresholds, and drop the umbrella-just-in-case line. You do get precipitation.type, which tells you when it is snow or freezing rain — worth a boots rule of its own. The Meteosource weather API is great for this project because it is very accurate.

Get real weather data into Python in 12 lines

Petrichor — Mon, 31 Aug 2026 12:17:34 +0000

Most "weather in Python" tutorials end at printing a temperature. That's rarely what you actually need. Usually you want a time series you can join to your own data: sales, sensor readings, energy output, whatever.

Here's the shortest path I know to get there.

Install

pip install 'pymeteosource[pandas]'

The [pandas] extra is optional. Without it the library only needs requests and pytz. The quotes matter on macOS, where zsh treats bare square brackets as a filename pattern and refuses the command.

You'll need an API key. Meteosource has a free tier that's enough for this, and it's the API I work with, so that's what the examples use.

The 12 lines

from pymeteosource.api import Meteosource
from pymeteosource.types import tiers, sections, units

meteosource = Meteosource('YOUR_API_KEY', tiers.FREE)

forecast = meteosource.get_point_forecast(
    lat=50.088,
    lon=14.420,
    sections=[sections.CURRENT, sections.HOURLY],
    tz='Europe/Prague',
    units=units.METRIC,
)

df = forecast.hourly.to_pandas()
print(df.head())

That's Prague. Swap the coordinates for wherever you care about.

What you get

to_pandas() gives you a flat DataFrame indexed by datetime. Nested fields get flattened with underscores, so wind.angle becomes a wind_angle column. That means you can resample or merge immediately:

df['temperature'].resample('3h').mean()

If you'd rather work with the objects directly, attributes take either dot or bracket access:

forecast.hourly[0]['temperature']
forecast.hourly[0].wind.speed

Handy when you're building keys dynamically.

What the free tier actually gives you

Worth knowing before you plan around it: 400 calls per day, capped at 10 per minute, and the hourly forecast runs one day ahead (the daily section goes out seven). So the code above returns roughly 24 rows, not a week. Enough to build and test against, but daily aggregates need a paid tier.

Three things that will bite you

Timezones. The library defaults to UTC regardless of where your point is, and note that this is the opposite of the raw API, which defaults to the point's local time. So if you're porting working code from curl or requests, your timestamps silently shift. The library does this deliberately, to dodge ambiguous datetimes around DST. Just set tz explicitly and stop thinking about it.

Units. The units parameter defaults to auto, which picks based on location. Fine for a UI, bad for a dataset: loop over a list of cities and you'll get metric for Prague and imperial for Denver in the same DataFrame, with nothing in the column names to tell you which is which. Pin it to units.METRIC or units.US and be done.

Section names. Ask for only the sections you need (current, minutely, hourly, daily, alerts). Requesting minutely when you're building daily aggregates just makes the response bigger and slower to parse. On the free tier the minute-by-minute data isn't included anyway.

That's it

Twelve lines to a DataFrame. From here the interesting part is what you join it to.

Library and full docs: github.com/Meteosource/pymeteosource

If you've built something with weather data, I'd like to hear what. I collect these.

Comparing weather across cities in Python: the timezone trap

Petrichor — Wed, 26 Aug 2026 08:32:59 +0000

Charting one city's forecast is a five-minute job. Charting four on the same axis raises a question single-city tutorials never ask: what does "the same time" mean across timezones?

This is a ~50-line Streamlit dashboard built on Meteosource's weather API, using its /point endpoint. Free tier, 400 calls a day, no card.

pip install streamlit pandas requests

The trap

Pull hourly forecasts for Prague and Reykjavík in local time, line them up in pandas, and Prague's 14:00 sits directly above Reykjavík's 14:00. Two moments two hours apart, drawn as though simultaneous. Every comparison you make from that chart is wrong.

Two defensible answers, and you have to pick one on purpose:

Absolute time. Request everything in UTC. "Right now, Barcelona is 17° warmer than Reykjavík." Correct for anything synchronised: flights, grid load, a live ops dashboard.
Local time. Request each city in its own zone, index by hour-of-day. "Barcelona's afternoon peak is 17° above Reykjavík's." Correct for comparing daily rhythms.

This one uses UTC, and you have to ask for it. Leave timezone out and the API gives you each point's own local time, which means the default is the trap. That's also why Meteosource's own Python wrapper, pymeteosource, always requests UTC internally and converts afterwards: same problem, same conclusion.

The app

import streamlit as st
import pandas as pd
import requests

API_KEY = st.secrets["METEOSOURCE_KEY"]
BASE_URL = "https://www.meteosource.com/api/v1/free/point"

CITIES = {
    "Prague": (50.0755, 14.4378),
    "Barcelona": (41.3874, 2.1686),
    "Reykjavík": (64.1466, -21.9426),
    "Athens": (37.9838, 23.7275),
}

st.title("🌍 City temperature comparison")

chosen = st.multiselect("Cities", list(CITIES),
                        default=["Prague", "Barcelona", "Reykjavík"])


@st.cache_data(ttl=1800)
def fetch(city):
    lat, lon = CITIES[city]
    # timezone=UTC is not the default, so it has to be explicit
    params = {"lat": lat, "lon": lon, "sections": "hourly",
              "timezone": "UTC", "units": "metric", "key": API_KEY}
    response = requests.get(BASE_URL, params=params, timeout=10)
    response.raise_for_status()
    rows = response.json().get("hourly", {}).get("data", [])
    if not rows:
        return None
    df = pd.DataFrame(rows)[["date", "temperature"]]
    df["date"] = pd.to_datetime(df["date"])
    df = df.set_index("date")
    return df.rename(columns={"temperature": city})


if chosen and st.button("Compare"):
    frames = []
    for city in chosen:
        try:
            frame = fetch(city)
        except requests.exceptions.RequestException as exc:
            st.error(f"{city}: {exc}")
            continue
        if frame is None:
            st.warning(f"{city}: no hourly data returned")
            continue
        frames.append(frame)

    if not frames:
        st.stop()

    wide = pd.concat(frames, axis=1)

    cols = st.columns(len(wide.columns))
    for col, city in zip(cols, wide.columns):
        col.metric(city, f"{wide[city].max():.0f} °C",
                   f"{wide[city].min():.0f} °C low", delta_color="off")

    st.line_chart(wide)
    st.caption("Hourly temperature in °C. All timestamps UTC.")

Put your key in .streamlit/secrets.toml as METEOSOURCE_KEY = "...", then streamlit run app.py.

Layout illustration with sample values. The free tier returns one day of hourly forecast, so your own chart will be shorter.

Two things worth noting

The endpoint takes one point at a time, so fetch() returns a one-column frame named after the city and pd.concat(frames, axis=1) joins them on the shared UTC index. Add a tenth city and nothing else changes.

@st.cache_data(ttl=1800) matters more than it looks. Streamlit reruns the whole script on every widget interaction, so without it, ticking a checkbox costs one request per selected city and a few minutes of fiddling eats the daily quota.

Where to go next

Precipitation lives at precipitation.total, nested, so it needs pd.json_normalize.
Local-time alignment: pass each city its own timezone and index on hour-of-day. Watch out for the day DST ends, when local time repeats an hour and you get two records with the same timestamp. Drop the duplicate with df[~df.index.duplicated(keep="first")] or pd.concat will fail.
place_id instead of coordinates: resolve names via /find_places_prefix. For mountains it gets you the peak's real elevation, where raw coordinates can land you lower down.
Don't index by position. The docs are explicit that sections and variables can grow over time.

If your cities seem to disagree about when the sun comes up, it's the timezone. It's always the timezone.

What a weather API comparison table leaves out

Petrichor — Mon, 17 Aug 2026 13:36:14 +0000

A comparison table gets a provider onto your shortlist. Something else gets it picked.

I answer the support inbox at Meteosource, a weather API, so I read most messages from people in the middle of an evaluation. Price comes up early in almost all of them. It is the easiest thing to compare, so it gets compared first.

It is rarely what settles it. Four other questions show up more often, and none of them are answered on a pricing page.

Can I test this in the next five minutes

Not features. Not accuracy. Whether a response can be on screen while the idea is still interesting.

A card form on a free tier loses at this step. So does a sales call before an API key. So does a signup flow asking for company size and use case before it gives you anything.

The message underneath all of it is the same one that kept landing in our inbox: I just want to see the JSON. That is why our free tier is 400 calls a day with no card, and it is the single change that moved trial signups the most.

What does the license actually allow

Plenty of free and cheap weather tiers are non commercial. Fine for a dashboard on your own wall. Not fine the moment your app has a paying user.

Anyone caught by this once now reads the terms before the docs. It takes two minutes and it saves a migration later. Worth checking on any provider you shortlist, including us.

What happens when I hit the limit

Three common answers, and they are not equally pleasant.

A hard 429 tells you immediately. Silent throttling gives you degraded data and no signal, which is the worst version because your users find out before you do. Overage billing gives you a surprise invoice after a retry loop runs over a weekend.

Predictable beats generous. A smaller cap you understand is easier to build on than a large one with fuzzy rules.

Will this pricing still work in a year

The pattern people are checking for is the cliff. A cheap starter plan, then nothing until an enterprise contract with a sales process attached.

If usage doubles, does the bill roughly double, or does it jump by a factor of ten. Anyone who has migrated off a provider mid project looks for that gap before writing a line of code.

We tried to avoid it by splitting features and call volume into separate choices, and by metering historical data per day per location instead of gating it behind a tier. It is not perfect. Our per location Renewables pricing genuinely does not suit anyone who wants to query a hundred scattered points occasionally, and a call based provider will be cheaper for that shape of usage. Different models fit different problems and pretending otherwise wastes everyone's time.

Why none of this shows up in a comparison table

Because none of it is comparable. Signup friction, license scope, limit behaviour and pricing shape are all specific to how you plan to use the thing. There is no column for them.

So they get left out, the table fills up with price and call counts, and the four questions that decide it end up as your own ten minutes of digging through docs and terms.

That cuts both ways. As a provider you cannot write your way out of any of it. They are product and terms of service decisions, sitting in public, and the only way to look better on them is to be better on them.

For anyone who has integrated a data API recently: what made you close the tab? Not the thing you complained about six months in, the thing that ruled a provider out on day one.

Finding the right price for a weather API

Petrichor — Wed, 05 Aug 2026 12:23:04 +0000

Why pricing a digital product is harder than it looks

Pricing a digital product is a strange kind of problem. There's no shelf to stock, and the cost of serving each customer isn't fixed. It grows with how much they use it. Usage is unpredictable, value is hard to see upfront, and a weather forecast can feel like a commodity, something buyers assume is all the same and shop for on price alone, even when the accuracy behind it isn't (in our case, 40 models blended with machine learning).

Price it too high, and it's out of reach for a hobby developer building something small. Price it too low, and it can't support what a business running thousands of locations actually needs. We ran into this from three different angles at Meteosource, and changed our pricing to deal with each one.

Challenge 1: usage is all over the place

A subscription API was always our way of letting a solo developer and a global operations team build on the same forecasts. But a fixed call limit doesn't work for both. One project makes 5,000 calls a day, another makes 500,000. Same plan, wildly different needs.

So to solve this, we split the offer into subscription levels, from Startup to Standard, and gave each level its own tier of call volumes. It works a bit like a table: pick your subscription for the features you need, then pick the call volume that matches how much you actually use, and find where you sit best. The details are on our pricing page, but the short version is: a side project and a scaling product don't have to fit in the same box anymore, and moving up as you grow is a lot more incremental.

Challenge 2: historical data doesn't fit neatly into a tier

Twenty years of historical weather data is one of the most valuable things we offer, and one of the hardest to price fairly. Bundle it into a plan, and people download the archive once and leave. Put it behind its own tier, and the price climbs until only the biggest customers can justify it. Neither worked.

We made it a metered add-on instead: $0.005 per day, per location, covering 20 years back, on any plan. You pay for exactly what you pull. A small project can dip into the archive without upgrading to an expensive tier, and the cost scales with actual usage instead of a flat guess.

Challenge 3: no tier existed for renewables forecasting

We kept hearing from people forecasting energy production (solar and wind) who needed something none of our existing plans covered: power-production forecasts per location, at hourly or 15-minute resolution.

So we built a Renewables tier from $19/location, covering PV systems and wind farms. It works whether you're modeling a few rooftop panels or a full farm. Past 20 sites, we set up custom pricing directly.

What stayed the same

Free is still 400 calls/day, no credit card, just an email. Enterprise is still fully custom, with parameters, data volume, SLAs, and applied-AI models built around the use case. Existing subscribers keep their current plan. We kept what was working, and moved around what needed a change.

We'll keep adjusting further if the need appears, and of course keep adding features to cover more of what people actually need. That's really the goal behind all of it.

But we're happy we cracked the logic of it, and it seems to be working well. What do you think about this change? What's your experience with the prices? Share it with us.