ninja_hippo/lunch-notifier
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Document calendar target switch to calendar.family_2
All checks were successful
Deploy / deploy (push) Successful in 33s
Details

Browse source 
Two HA entities are both named "Family" (calendar.family and
calendar.family_2); the automation now targets _2 per user preference.
Note it only supports create_event, not delete, so a bad push has to be
cleaned up manually in Google Calendar rather than via the HA API.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KsJqAZ82Veyf5oihBr71S5
This commit is contained in:
Barely Removable 2026-09-03 08:56:05 -07:00
parent 486d175d6a
commit d3498849d3
1 changed files with 16 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

26
CLAUDE.md
View file

@ -25,16 +25,22 @@ Runs as one Docker container on the user's Unraid home server.
`{"date": ..., "items": [...]}` to that webhook, independent of whether `{"date": ..., "items": [...]}` to that webhook, independent of whether
the SMS send itself succeeds. On the HA side (`automation.lunch_menu_family_calendar`, 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 `http://192.168.86.207:8123`), a `local_only` webhook trigger runs
`calendar.create_event` against `calendar.family`, producing an all-day `calendar.create_event` against `calendar.family_2` (the "Family" Google
event with the menu as the description (bulleted). This makes the Calendar entity — there are two entities both named "Family" in this HA
scrape here the single source of truth — HA doesn't poll or re-scrape instance, `calendar.family` and `calendar.family_2`; this integration
anything. The webhook id is a random token that lives only in the deliberately targets `_2`), producing an all-day event with the menu as
server's `.env` (`HA_WEBHOOK_URL`) and in the automation's trigger the description (bulleted). This makes the scrape here the single
config — never committed here. If the calendar push stops working, source of truth — HA doesn't poll or re-scrape anything.
check both ends: `GET /api/integrations` on this app reports whether `calendar.family_2` only supports `create_event`, not `delete_event` —
`HA_WEBHOOK_URL` is set at all, and `ha_get_automation_traces` on a bad push can't be cleaned up via the HA API, only manually in Google
`automation.lunch_menu_family_calendar` shows whether HA is even Calendar. No duplicate-prevention either way: re-pushing the same
receiving the webhook. date's menu creates a second event. 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 — - **Manual actions (2026-09-03):** besides "Send Lunch Menu Now" (full job —
scrape, HA push, text everyone), the UI has "Push to Calendar Only" scrape, HA push, text everyone), the UI has "Push to Calendar Only"
(`POST /api/push-calendar` → `push_calendar_only()`, scrape + HA push, no (`POST /api/push-calendar` → `push_calendar_only()`, scrape + HA push, no