Currently, the Position message has no standard way to signal that a transmission was triggered by a physical button interaction on the device. Devices like the SenseCAP 1000T already support a double-press gesture that calls sendAdHocPosition(), but the resulting packet is indistinguishable from a periodic automatic broadcast. Receivers (mobile apps, integrations) have no way to treat it differently — for example, to fire an alert or highlight it as an intentional manual check-in.
Proposed change
Add an optional ButtonEvent button_event = 24 field to Position, backed by a new message:
message ButtonEvent {
enum EventType {
NONE = 0; // Default — not a button-triggered position
DOUBLE_TAP = 1; // User double-tapped the device button
// Future extension e.g. LONG_PRESS = 2 when the user held the device button for an extended period
}
EventType event_type = 1;
}
Why a message rather than a bool or a bare enum?
A nested message is forward-compatible: fields like tap_count or hold_duration_ms can be added later without changing the Position wire format. A bare bool (the obvious minimal solution) can only express "was this a button press?" and would need to be superseded as soon as a second gesture type is needed.
Wire compatibility
Field 24 is currently unassigned in Position. This addition is fully backwards-compatible — receivers that don't know about button_event will silently ignore it.
Related firmware change
The corresponding firmware implementation should set button_event.event_type = DOUBLE_TAP in PositionModule when a double-press triggers sendAdHocPosition(). A PR will follow once this issue is discussed.
Currently, the Position message has no standard way to signal that a transmission was triggered by a physical button interaction on the device. Devices like the SenseCAP 1000T already support a double-press gesture that calls sendAdHocPosition(), but the resulting packet is indistinguishable from a periodic automatic broadcast. Receivers (mobile apps, integrations) have no way to treat it differently — for example, to fire an alert or highlight it as an intentional manual check-in.
Proposed change
Add an optional ButtonEvent button_event = 24 field to Position, backed by a new message:
Why a message rather than a bool or a bare enum?
A nested message is forward-compatible: fields like tap_count or hold_duration_ms can be added later without changing the Position wire format. A bare bool (the obvious minimal solution) can only express "was this a button press?" and would need to be superseded as soon as a second gesture type is needed.
Wire compatibility
Field 24 is currently unassigned in Position. This addition is fully backwards-compatible — receivers that don't know about button_event will silently ignore it.
Related firmware change
The corresponding firmware implementation should set button_event.event_type = DOUBLE_TAP in PositionModule when a double-press triggers sendAdHocPosition(). A PR will follow once this issue is discussed.