Feature area
Integration logic/state
Problem or use case
When ChoreOps sends a mobile push notification (chore claimed, reward claimed, reminder, badge earned), tapping the notification body opens the HA Companion App but lands on whatever screen was last open — not on the approval workflow. To actually approve the chore, I have to manually navigate there.
Proposed solution
Add an optional per-user field in the user config — something like "Notification tap URL" — that sets the clickAction value in the mobile notification payload. When set, tapping the notification body navigates directly to that URL.
The HA Companion App supports clickAction as a relative path (e.g. /lovelace/0) or absolute URL, passed through as-is — works for both stock HA dashboards and custom setups.
Implementation note (happy to submit a PR if the direction looks good): build_extra_data() already passes a dict merged into the notification payload via data.update(extra_data) in async_send_notification(). Adding clickAction to that dict is sufficient — no changes to the send path needed. The new field would follow the same pattern as mobile_notify_service: a per-user TextSelector in the identity section of the options flow, stored in UserData, optional with empty-string default (backward compatible, no migration needed).
Expected outcome
Tapping a ChoreOps push notification drops me directly into my approval view. For my setup that's a custom admin dashboard at /command-center/chore-ops-center — one tap instead of navigate + find the right view.
Alternatives considered
- HA automation on
mobile_app_notification_action events — only fires on action button taps, not on notification body tap.
- Custom notification automations to duplicate ChoreOps' logic with
clickAction added — fights against the built-in notification system and duplicates maintenance burden.
Additional context
HA Companion App docs for clickAction: https://companion.home-assistant.io/docs/notifications/notifications-basic/#notification-click-action
Feature area
Integration logic/state
Problem or use case
When ChoreOps sends a mobile push notification (chore claimed, reward claimed, reminder, badge earned), tapping the notification body opens the HA Companion App but lands on whatever screen was last open — not on the approval workflow. To actually approve the chore, I have to manually navigate there.
Proposed solution
Add an optional per-user field in the user config — something like "Notification tap URL" — that sets the
clickActionvalue in the mobile notification payload. When set, tapping the notification body navigates directly to that URL.The HA Companion App supports
clickActionas a relative path (e.g./lovelace/0) or absolute URL, passed through as-is — works for both stock HA dashboards and custom setups.Implementation note (happy to submit a PR if the direction looks good):
build_extra_data()already passes a dict merged into the notification payload viadata.update(extra_data)inasync_send_notification(). AddingclickActionto that dict is sufficient — no changes to the send path needed. The new field would follow the same pattern asmobile_notify_service: a per-userTextSelectorin the identity section of the options flow, stored inUserData, optional with empty-string default (backward compatible, no migration needed).Expected outcome
Tapping a ChoreOps push notification drops me directly into my approval view. For my setup that's a custom admin dashboard at
/command-center/chore-ops-center— one tap instead of navigate + find the right view.Alternatives considered
mobile_app_notification_actionevents — only fires on action button taps, not on notification body tap.clickActionadded — fights against the built-in notification system and duplicates maintenance burden.Additional context
HA Companion App docs for clickAction: https://companion.home-assistant.io/docs/notifications/notifications-basic/#notification-click-action