Companion lost-status auto response

Development Companion builds containing this feature can automatically answer a private Am I lost? message with Yes or No. You choose the saved answer. The default is off, and the firmware does not infer lost status from GPS, distance, or a missing phone connection.

This is included in nRF52, ESP32 and RP2040 Companion profiles, including T1000-E and RAK Tag. Compact STM32 Companion images omit it to preserve their existing application and filesystem boundaries. A custom build can explicitly enable MESH_ENABLE_LOST_REPLY=1 when its flash budget permits; the normal flash and RAM checks still apply.

Configure it through a directly connected local Companion CLI:

get lost.reply
set lost.reply no
set lost.reply yes
set lost.reply off

The setting survives reboot and takes effect immediately. USB, BLE and other local Companion transports can use framed command 0x42. Builds with a text terminal also accept these commands there. LoRa CLI cannot read or change this local setting. A failed save restores the previous answer and reports an error. Older saved preference images load the new setting as off.

ESP32 Companions with WebConfig also have a Lost-status auto reply selection on the radio configuration page. Choose Off, Reply No or Reply Yes and save. The control is shown only on Companion firmware with this capability. The existing mobile app protocol needs no new message type; a native app toggle is not added by this firmware change.

Dog tracker example

The owner's Companion stores the tracker as a normal radio contact. Set the answer to no during normal operation. If the dog is lost, set it to yes. When the tracker sends Am I lost? privately to that reachable Companion, it receives the selected answer, even when the owner's phone is disconnected. The same configured answer applies to all eligible contacts on this Companion.

The opt-in Sensor dog tracker implements periodic fresh GPS acquisition, low power sleep, and owner check-ins. It uses a tagged encrypted request and response rather than parsing plain Yes or No text, so old answers cannot change a newer check-in. Store the Sensor as a persistent Sensor contact on the owner's Companion. The same saved lost.reply setting answers those checks; off returns Unknown. A fresh accepted GPS position updates the contact location through normal contact notifications.

Other clients can still use the plain text question. They must stay awake for the separate private answer; a delivery ACK is not that answer. Plain text answers have no request ID. The responding Companion must be powered on and reachable. Personal room mailboxes provide store-and-forward mail; automatic mailbox polling is not yet implemented in the Sensor tracker.

Matching and traffic limits

Only an authenticated ordinary private message from a known persistent radio contact is eligible. The contact must be an ordinary Companion/chat contact; room-server and repeater contacts are excluded. Temporary unknown senders, public channels, room chat posts and CLI messages do not trigger a response.

The exact phrase am I lost is matched without regard to ASCII letter case, with an optional final question mark and surrounding whitespace. Extra words or commands do not match. The reply is ordinary encrypted private text, Yes or No, and neither answer can trigger another automatic reply.

Automatic responses are limited to one per contact per minute and one globally per ten seconds. A bounded four-peer cache uses full public keys and the incoming request timestamp to suppress retries. Its state clears on reboot. The same retained request is not answered again; a fresh check uses a new timestamp. An old retry can receive another answer after a newer request replaces its saved timestamp or its peer slot is evicted. Queueing an answer records the request even if later delivery fails. An unanswered poll means unknown, and the tracker should trust replies only from its configured Companion's full public key.

The responder leaves packet capacity for normal receive/ACK work, uses a free ACK-tracking entry, and does not replace pending user messages or their delivery deadlines. Busy packet or ACK capacity, or a failed send, can prevent an answer; the tracker should retry later. A full offline app inbox does not disable the responder. Normal message reception and notification behavior remain in place.