Weather integrations give you a forecast. What you usually want is narrower and more urgent: is something about to happen here, in the next twenty minutes, that I should act on? That question needs different sources and a different shape. A forecast tells you what the sky is considering; what you want is a tap on the shoulder.
A forecast is an opinion about tomorrow. A nowcast is a fact about the next twenty minutes, which is the only window in which a house can actually do anything: shut a window, pull a blind, decide the towels can stay out. Everything here is about the short version of the future.
Layer the sources by time horizon
| Horizon | Source | What it answers |
|---|---|---|
| Days | Severe-weather outlooks | Should I plan around this? |
| Hours | Official warnings for your area | Is an authority worried? |
| ~1 hour | Pressure tendency, storm outlooks | Is the situation deteriorating? |
| Minutes | Lightning detection, precipitation nowcast | Close the window now |
The bottom row is the one people skip, and it is the only one that reliably changes behaviour. A forecast of "thunderstorms this afternoon" is not actionable. "Nearest strike is 9 km away and closing, and a window is open" is.
Approaching, not just near
A lightning alert based purely on distance has two embarrassing failure modes. While a storm is moving away it keeps firing, because the strikes are still inside the ring: the danger is over and the phone is still being dramatic about it. And it fires for storms that were never coming at all. We once watched a cell over Austria close from 84 to 38 km, radially "approaching" the entire time, while a west wind carried it neatly past, parallel to the border, on its way to bother somebody else.
So the alert grew up in two steps. First, compute whether the nearest strike distance is decreasing, and alert on approach rather than proximity. Second, the sailors' correction, because falling range alone cannot tell an arrival from a flyby: the strikes must also sit upwind, within about sixty degrees of where the wind is coming from.
Mariners call the collision rule "constant bearing, decreasing range"; it works just as well when the other vessel is a thunderstorm. Add a bypass for days when the wind is too weak to steer anything, and a "closer than 15 km always alerts" safety net for days when the surface wind lies about the steering flow. Same data, far fewer messages, and each one means something.
Rebuild feeds you cannot trust
Official warning integrations are often fragile: a slow boot or a timeout can leave a permanently missing entity behind, and now your severe-weather gate silently answers "no". Where a source is important, consider fetching the raw feed yourself on a schedule and building the entity locally. More work, but you control the failure mode and can make it visible. The scraper is not elegant. Neither is being woken by a storm the integration decided not to mention.
Two locations, one system
If you look after more than one place, every weather automation needs a proximity gate: alerts for a location should only reach you when you are at that location. Otherwise you learn to ignore all of them, including the ones about where you are standing. Duplicate entities per location are not clutter, they are the price of relevance.
Indoor air deserves better than a threshold
The usual setup is "alert if CO₂ above X". That is fine as a floor, but the interesting questions are comparative.
Is the problem inside or outside?
Compare indoor particulates with outdoor. If indoor is far above outdoor, something in the room is producing them and ventilating will help. If both are high, the air outside is the source and opening up makes things worse. Same measurement, opposite advice, and you cannot tell which without the second sensor.
Requiring both conditions also protects against a real outdoor smog episode being misread as an indoor problem, which is when the naive rule gives exactly the wrong instruction.
Would ventilating actually help?
This deserves its own page, see measure the thing that matters, but the short version: relative humidity cannot answer it, dew point can, and projecting the resulting indoor humidity lets you express the rule the way a person thinks ("fine as long as we stay under 60%").
Build the verdict from vetoes (particulates, moisture, heat) with CO₂ as the one override, itself capped by an outdoor-air ceiling (see when to open a window): stale air beats a little humidity, and loses to smoke. And take CO₂ from whichever room is worst, not from whichever room happens to have the sensor.
Confirm that ventilating happened
A prompt to open windows is only half a loop. Detecting the resulting airflow (two contacts on opposite sides of the home, both open) lets the system confirm the advice was taken, and gives you a positive message instead of another nag. Closing that loop is what stops a helpful prompt from becoming background noise.
Tiered air alerts, with an off-switch for known causes
Air alerts work best in tiers: a gentle nudge, a visible ambient warning, and a genuine safety alert for smoke-like readings at the sensor closest to the source. Then suppress the loud tiers when a known activity explains the reading, see automations that do not fight each other, while keeping the quiet nudge. You already know why the air is bad; what you want is the reminder to do something about it.
We still read the forecast. We just no longer let it touch the windows.