Add update_delivery_times action for frequent delivery-ETA polling

[dvejsada]

Closes #77

What

Adds a lightweight rohlikcz.update_delivery_times action that refreshes only the delivery announcements (a single API request) — the payload that carries the frequently shifting delivery ETA — and immediately notifies entities so the Delivery Time sensor updates. This lets automations poll every minute shortly before a delivery without the cost of a full update_data refresh, addressing the stale-ETA problem from #77. The order's delivery window (deliverySlot) is fixed once ordered, so it is deliberately not re-fetched.

Changes

• hub.py: new RohlikAccount.refresh_delivery_times(), modeled on refresh_slots() — updates data["delivery_announcements"] in place and calls async_update_listeners()
• services.py / const.py / services.yaml / icons.json: register and describe the new action (config entry selector only, no response)
• automations/update_delivery_times.yaml: copy-paste example that polls every minute while the ETA is within the next 30 minutes (and up to 10 minutes past it in case the courier is late) — self-regulating, no arming toggle needed
• readme.md: action table row, tip linking the example automation, data-updates section mention
• manifest.json: version bump to 0.6.1
• tests/test_init.py: new test verifying the action updates the Delivery Time sensor from a fresh announcement while leaving other data untouched

Testing

All 23 tests pass (pytest tests/).

🤖 Generated with Claude Code

https://claude.ai/code/session_01LFCKozF619nbadAAgAGmJY

---

Generated by Claude Code

[dvejsada]

@claude review

[claude]

Claude finished @dvejsada's task in 2m 8s —— View job

---

Review of PR #78 — update_delivery_times action

• Gather context (diff, changed files)
• Review hub.py changes
• Review services.py / const.py / services.yaml / icons.json
• Review automations/update_delivery_times.yaml
• Review tests/test_init.py
• Post review feedback

Summary: This is a clean, well-scoped addition that closely mirrors the existing refresh_slots() pattern, so it's easy to reason about and low-risk.

What checks out:

• hub.py:754-768 (refresh_delivery_times) — same shape as refresh_slots() (hub.py:741-752): no-ops if self.data is falsy, only overwrites data["delivery_announcements"], and calls async_update_listeners(). Confirmed via sensor.py:90/105/170 that DeliveryInfo/DeliveryTime read exactly data["delivery_announcements"]["data"]["announcements"], so the shape written here matches what the sensors expect.
• services.py:140-148 / services.py:254-262 — registration and error handling (HomeAssistantError wrapping) match async_refresh_slots exactly.
• const.py, services.yaml, icons.json — new constant/entry placed consistently alongside refresh_slots; no naming or duplication issues.
• manifest.json version bump (0.6.0 → 0.6.1) is the only version reference in the repo, so no other file needs updating.
• automations/update_delivery_times.yaml — the polling condition (-600 <= (as_datetime(eta) - now()).total_seconds() <= 1800) correctly implements "poll within 30 min before ETA, up to 10 min after" as described in the PR. Self-regulating design (no arming toggle) is a nice simplification vs. the refresh_slots.yaml example, and appropriate since it's driven off the sensor's own state.
• tests/test_init.py — new test correctly verifies the announcement is merged in-place and other data (login.user.id) is untouched, matching the "don't disturb the rest of the data" contract.

Minor observations (non-blocking):

• The hardcoded entity ID sensor.rohlik_cz_delivery_time in the automation example assumes default entity naming/single account — acceptable for a copy-paste example, same caveat applies to the existing refresh_slots.yaml example.
• icons.json is still missing a trailing newline (pre-existing, not introduced by this PR).

I was not able to execute pytest in this review environment (command execution required approval that wasn't available), so I verified correctness by reading the diff, hub.py, and sensor.py directly rather than by running the suite — the PR description states all 23 tests pass locally.

No changes requested — looks good to merge.

[dvejsada]

@claude review

[claude]

Claude finished @dvejsada's task in 1m 40s —— View job

---

Review of PR #78 — update_delivery_times action

• Gather context (diff, changed files, prior review)
• Check what changed since the last review (commit c7ec512)
• Review hub.py changes
• Review services.py / const.py / services.yaml / icons.json
• Review automations/update_delivery_times.yaml
• Review tests/test_init.py
• Post review feedback

Summary: Since my previous review, commit c7ec512 addressed both minor observations (missing trailing newline in icons.json, and clarified the hardcoded entity ID in the automation example with a comment on how to adapt it for non-default naming). I re-verified the full diff against origin/master and re-checked the substantive files; nothing else has changed and the implementation remains correct.

What checks out:

• hub.py:754-769 (refresh_delivery_times) — mirrors refresh_slots() exactly: no-ops if self.data is falsy, only overwrites data["delivery_announcements"], and calls async_update_listeners(). Matches the shape DeliveryInfo/DeliveryTime read in sensor.py:90/105/170 (data["delivery_announcements"]["data"]["announcements"]).
• services.py / const.py — SERVICE_UPDATE_DELIVERY_TIMES registration and HomeAssistantError wrapping match async_refresh_slots exactly.
• services.yaml, icons.json — new entries consistent with the existing refresh_slots entry; icons.json now ends with a trailing newline.
• automations/update_delivery_times.yaml — polling condition correctly implements "30 min before ETA, up to 10 min after"; now includes a comment clarifying that the entity ID should be adjusted for non-default naming/multiple accounts.
• tests/test_init.py — new test verifies the announcement merges in-place, the DeliveryTime sensor picks up the new ETA, and unrelated data (login.user.id) stays untouched.
• manifest.json version bump (0.6.0 → 0.6.1) is consistent, no other version references in the repo.

No issues found. I was not able to execute pytest in this review environment (command execution required approval that wasn't available), so I verified correctness by reading the diff and cross-referencing hub.py/sensor.py directly.

Looks good to merge.