UpdateCoreData.updateAnyPacketFrom: mirror firmware's lastHeard/snr/rssi/hopsAway update logic from NodeDB::updateFrom
#1492
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
While thinking about #1488 I realized that the logic for updating
lastHeardwas different from that used in the firmware.In the firmware, updates to
last_heard,rx_snr,rx_time,via_mqtt,hops_awayare all set in one small functionNodeDB::updateFrom, which receives all packets:https://github.com/meshtastic/firmware/blob/28f53d132aa0d3903482ea9b475527068389244a/src/mesh/NodeDB.cpp#L1733-L1762
I think it simplifies things to use essentially the same logic in the client, especially since we update
lastHeardetc from the radio whenever we connect and re-fetch the node database.This change:
lastHeardwas being updated whenever we sent a DM, due toaddContactFromURLcallingupsertNodeInfoPacketwith a synthetic packetrxTimeto updatelastHeardlike the firmware does, and neverposition.timestampwhich can be in the future)lastHeardandrxSnretcI've tested it on iOS and macOS clients. The result seems to be a more active node list, no nodes with times in the future, and immediate updates to SNR/RSSI when viewing nearby nodes!
Checklist