Skip to content

v2.8.3 — api.links stops inventing direct links

Choose a tag to compare

@maxg10 maxg10 released this 15 Sep 20:41
· 30 commits to main since this release

api.links, added in 2.8.0, decided that a node was heard directly by this
mapper's radio if its hops field read zero. That is the Meshtastic test, and
only the Meshtastic test.

The core's own version of the same question — a few hundred lines away in the
backend — has always been more careful:

hops = node.get('hops') if net == 'MT' else node.get('hops_away')
if hops != 0: continue
if net == 'MT' and node.get('via_mqtt', False): continue

Two things the edge list was missing. Meshcore reports out_path_len, where
zero means an established outbound path rather than zero radio hops — the exact
distinction 2.7.2 introduced Network reach for — so a Meshcore contact could
enter a plugin's graph as a direct RF neighbour of the local node. And a node
heard via MQTT
was heard by somebody else's radio, not this one.

Both are excluded now, the developer guide states that the edge list is
Meshtastic-only, and the four cases are covered: a Meshtastic node at zero hops
is a link; the same node via MQTT is not; a Meshcore contact reading zero is not;
a Meshtastic node two hops away is not.

Meshcore nodes are unaffected everywhere else — they stay on the map and in
api.nodes. They are simply no longer claimed to be RF neighbours of anything.

Updating

cd ~/meshpulse && git pull origin main && ./install.sh && sudo systemctl restart meshpulse

Docker

docker compose pull && docker compose up -d

Fresh Install

git clone https://github.com/maxg10/meshpulse.git
cd meshpulse
./install.sh