Per-location alert feed (RSS / JSON / iCal) #75

New issue

Closed

opened 2026-07-18 05:31:37 +00:00 by claude-bot · 1 comment

claude-bot commented

2026-07-18 05:31:37 +00:00

Contributor

Public pages exist; a /p/{token}.json or RSS variant makes locations consumable by other homelab automations (Home Assistant!). Effort S, value M for the integration-minded.

Filed from the 2026-07-17 codebase audit (docs/.internal/report-2026-07-17.md), finding I-05.

Public pages exist; a `/p/{token}.json` or RSS variant makes locations consumable by other homelab automations (Home Assistant!). Effort S, value M for the integration-minded. --- _Filed from the 2026-07-17 codebase audit (`docs/.internal/report-2026-07-17.md`), finding I-05._

claude-bot added this to the v1.5.0 - Feature enhancements milestone

2026-07-18 05:31:37 +00:00

claude-bot added the

area:public-pages

type:feature

labels

2026-07-18 05:31:37 +00:00

rbrooks referenced this issue from a commit

2026-07-19 14:46:03 +00:00

Add per-location alert feeds: JSON, RSS, iCal (#75)

claude-bot referenced this issue

2026-07-19 14:46:17 +00:00

v1.5.0 Phase 2a: ntfy channel (#72) + per-location alert feeds (#75) #112

claude-bot referenced this issue from a commit

2026-07-19 14:53:29 +00:00

Merge pull request 'v1.5.0 Phase 2a: ntfy channel (#72) + per-location alert feeds (#75)' (#112) from feat/v1.5.0-phase2 into main

claude-bot commented

2026-07-19 14:53:40 +00:00

Author

Contributor

Done in #112 (merged). GET /p/{location_id}.json|.rss|.ics — JSON, RSS 2.0, and iCal feeds of a location's active alerts, gated by Location.public_enabled + the public rate limiter, exposing the same alert set as the public HTML page. Stdlib-only builders in services/feeds.py (proper XML escaping; RFC-5545 iCal escaping + line folding), no new deps. Routes are defined before the /p/{token} catch-all and the PublicToken alphabet has no dots, so there's no collision.

Implementation note: I used the location's own id as the feed token (mirroring the existing /api/locations/{id}/public page) rather than minting single-alert PublicTokens, since those map to one alert lifecycle each, not a whole-location feed.

Follow-up (not blocking): SentAlert has no onset/area_desc columns (they live on NWSAlertSnapshot), so the JSON exposes them as null and iCal DTSTART falls back to sent_at. A snapshot-join backfill would enrich the feeds (and pairs naturally with #84's lead-time work).

Done in #112 (merged). `GET /p/{location_id}.json|.rss|.ics` — JSON, RSS 2.0, and iCal feeds of a location's active alerts, gated by `Location.public_enabled` + the public rate limiter, exposing the same alert set as the public HTML page. Stdlib-only builders in `services/feeds.py` (proper XML escaping; RFC-5545 iCal escaping + line folding), no new deps. Routes are defined before the `/p/{token}` catch-all and the PublicToken alphabet has no dots, so there's no collision. Implementation note: I used the location's own `id` as the feed token (mirroring the existing `/api/locations/{id}/public` page) rather than minting single-alert `PublicToken`s, since those map to one alert lifecycle each, not a whole-location feed. Follow-up (not blocking): `SentAlert` has no `onset`/`area_desc` columns (they live on `NWSAlertSnapshot`), so the JSON exposes them as null and iCal `DTSTART` falls back to `sent_at`. A snapshot-join backfill would enrich the feeds (and pairs naturally with #84's lead-time work).

claude-bot closed this issue

2026-07-19 14:53:43 +00:00

claude-bot referenced this issue

2026-07-19 15:11:10 +00:00

v1.5.0 Phase 2b: lead-time / time-to-impact display (#84) #113

claude-bot referenced this issue

2026-07-19 15:18:45 +00:00

Lead-time / time-to-impact display #84

claude-bot referenced this issue

2026-07-19 16:39:52 +00:00

Add v1.5.0 changelog #117