Document the HA-side webhook automation
All checks were successful
Deploy / deploy (push) Successful in 19s
All checks were successful
Deploy / deploy (push) Successful in 19s
The calendar-sync feature landed 2026-09-02 but only the app.py half — the HA automation to receive the webhook and create the calendar event was never built, so it silently did nothing. Built it now (automation.lunch_menu_family_calendar: local_only webhook trigger -> calendar.create_event on calendar.family) and documented where to look on each side when this breaks again. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01KsJqAZ82Veyf5oihBr71S5
This commit is contained in:
parent
9c1112f28e
commit
486d175d6a
1 changed files with 15 additions and 6 deletions
21
CLAUDE.md
21
CLAUDE.md
|
|
@ -20,12 +20,21 @@ Runs as one Docker container on the user's Unraid home server.
|
|||
first time, before a settings file exists.
|
||||
- Vacation ranges suppress sends without disabling the schedule — checked
|
||||
fresh on every run via `is_on_vacation()`.
|
||||
- **Home Assistant integration (2026-09-02):** if `HA_WEBHOOK_URL` is set,
|
||||
every successful menu fetch also POSTs `{"date": ..., "items": [...]}` to
|
||||
that webhook, independent of whether the SMS send itself succeeds. An HA
|
||||
automation (webhook trigger → `calendar.create_event`) turns this into an
|
||||
all-day calendar event with the menu. This makes the scrape here the
|
||||
single source of truth — HA doesn't poll or re-scrape anything.
|
||||
- **Home Assistant integration (2026-09-02, HA side built 2026-09-03):** if
|
||||
`HA_WEBHOOK_URL` is set, every successful menu fetch also POSTs
|
||||
`{"date": ..., "items": [...]}` to that webhook, independent of whether
|
||||
the SMS send itself succeeds. On the HA side (`automation.lunch_menu_family_calendar`,
|
||||
`http://192.168.86.207:8123`), a `local_only` webhook trigger runs
|
||||
`calendar.create_event` against `calendar.family`, producing an all-day
|
||||
event with the menu as the description (bulleted). This makes the
|
||||
scrape here the single source of truth — HA doesn't poll or re-scrape
|
||||
anything. The webhook id is a random token that lives only in the
|
||||
server's `.env` (`HA_WEBHOOK_URL`) and in the automation's trigger
|
||||
config — never committed here. If the calendar push stops working,
|
||||
check both ends: `GET /api/integrations` on this app reports whether
|
||||
`HA_WEBHOOK_URL` is set at all, and `ha_get_automation_traces` on
|
||||
`automation.lunch_menu_family_calendar` shows whether HA is even
|
||||
receiving the webhook.
|
||||
- **Manual actions (2026-09-03):** besides "Send Lunch Menu Now" (full job —
|
||||
scrape, HA push, text everyone), the UI has "Push to Calendar Only"
|
||||
(`POST /api/push-calendar` → `push_calendar_only()`, scrape + HA push, no
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue