Currently the integration only forwards a location update to Dawarich when the configured device_tracker entity's state changes. Since HA device_tracker entities are typically push-based (they update on zone transitions or significant GPS movement, not on a fixed schedule), this means no data is sent to Dawarich for long stretches while stationary — e.g. hours at home with no state change.
This causes a real problem downstream in Dawarich: its visit-detection algorithm treats long gaps in incoming points as "user left and returned," fragmenting what should be a single continuous stay into many short, separate "suggested visits" that all need manual review/confirmation. A single day at home can generate 5-6+ spurious visit suggestions purely from tracker silence, not actual movement.
Requested feature:
An optional periodic "heartbeat" push — configurable interval (e.g. every 5/10/15 min) — that re-sends the tracker's current location to Dawarich regardless of whether the underlying entity's state has changed. This would keep a continuous stream of points flowing during stationary periods and let Dawarich's detector correctly treat them as one uninterrupted stay.
Possible implementation approaches:
A time_pattern-based push scheduled by the integration itself, sending the last known coordinates on each tick
An additional config option (e.g. "Heartbeat interval") in the integration setup flow, defaulting to off/0 for backward compatibility
Alternatively, exposing a service (e.g. dawarich.push_location) that users could call from their own HA automations on a schedule, if a fully built-in scheduler is out of scope
Currently the integration only forwards a location update to Dawarich when the configured device_tracker entity's state changes. Since HA device_tracker entities are typically push-based (they update on zone transitions or significant GPS movement, not on a fixed schedule), this means no data is sent to Dawarich for long stretches while stationary — e.g. hours at home with no state change.
This causes a real problem downstream in Dawarich: its visit-detection algorithm treats long gaps in incoming points as "user left and returned," fragmenting what should be a single continuous stay into many short, separate "suggested visits" that all need manual review/confirmation. A single day at home can generate 5-6+ spurious visit suggestions purely from tracker silence, not actual movement.
Requested feature:
An optional periodic "heartbeat" push — configurable interval (e.g. every 5/10/15 min) — that re-sends the tracker's current location to Dawarich regardless of whether the underlying entity's state has changed. This would keep a continuous stream of points flowing during stationary periods and let Dawarich's detector correctly treat them as one uninterrupted stay.
Possible implementation approaches:
A time_pattern-based push scheduled by the integration itself, sending the last known coordinates on each tick
An additional config option (e.g. "Heartbeat interval") in the integration setup flow, defaulting to off/0 for backward compatibility
Alternatively, exposing a service (e.g. dawarich.push_location) that users could call from their own HA automations on a schedule, if a fully built-in scheduler is out of scope