search

meshtastic / Meshtastic-Android

Android application for Meshtastic
https://meshtastic.org
GNU General Public License v3.0
752 stars 217 forks source link

[Feature Request] Request Location until Reply #1170

Closed barryhunter closed 3 months ago

barryhunter commented 4 months ago

It would be nice if there as a option to have the App continuously 'ping' a node requesting location, until it gets a reply.

Scenario: Have a Meshtastic device attached to a mobile item (eg for tracking lost pets), but might be out of direct radio contact, so that the normal 'Request Location' doesnt work. Say the animal is in ravine. ... so you want to drive around the neighbourhood, and keep pinging until get a reply.

The App could automate this. For example, if don't get an immediate reply, to the position request, it then keeps sending out pings until (hopefully!) gets a reply. sending pings every 30 or 60 seconds possibly.

It would really should have audible alarm/notification when it gets a reply (which also stops further pings!) Also it would only run for say 30 or 60 minutes. For longer use, would have to renew the request.

To limit abuse it would only be available for nodes you already have the position for, and perhaps only nodes NOT seen in the last 30 minutes (for example). It could be even only be nodes connected to NOT with the 'default' channel. (ie your own nodes share a private channel with, rather than anyone on defaults like 'longfast')

As a stretch goal, it could have a 'smart position' feature. Ie sends the ping when (you) move more than say 500m. Rather than just a time period.

Finally, to avoid annoying any local meshes too much, if it doesnt get the reply with the 'normal' HopLimit, it could reduce and send further pings with hoplimit=0. On the basis that if the 'lost' device was in contact with the mesh, would already have a reply, so the mesh itself must be out of contact. So might as well save the pings bouncing around the mesh.

andrekir commented 3 months ago

this needs a different approach. spamming the mesh in general is not good. check if the tracker role (with priority for position broadcasts) fits your needs.

barryhunter commented 3 months ago

THe kinda point of this is it would be for when the device has become out of radio range (for whatever reason) ... dont want to spam a local 'mesh' particully (hence the suggestion to use HopLimit=0) - becauase it out of contact with the device ... but to try to regain contact with a "lost" device.

The LOST_AND_FOUND role is kinda close fit, but has the chicken-and-egg issue, that (AFAIK) the lost device cant (for example) enter LOST_AND_FOUND role automatically, if it looses contact with the mesh (or a 'paired' device)

Even with a Tracker set to periodic pings, you could be 'driving the neighbourhood', and without keeping a very close eye on the Node list, completely miss that received a ping from the 'lost device' - so even without the bit about sending out proactive position requests - the notification component to signal when 'connection reestablished'

meshtastic-bot commented 3 months ago

This issue has been mentioned on Meshtastic. There might be relevant details there:

https://meshtastic.discourse.group/t/is-there-a-way-to-enter-lost-and-found-automatically/14310/1