You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think it would would be interesting to be able to either filter or view nodes by the Uplink Node.
Essentially the ID in the original MQTT topic
msh/UK/2/c/LongFast/!da545934
Position messages on that topic, will just be the nodes that !da545934 is able to hear (even multi-hop).
While neighbours is good, and it is specifically the 'direct' neighbours. This would show the nodes, the particular node received, even multi-hop. which would show more of the mesh coverage. (although would only work if the Uplink node itself is publishing its position!)
Could be kinda like the 'Neighbours' buttons, and just draws a line to every node it has received a position report from.
Maybe Nodes we heard- analogous to the 'neighbours (we heard)' - ie it's not just direct neighbours, but all nodes heard.
Or maybe could be that enter a Node ID in search, and it would only show reports via that Node.
But could also have the reverse. Nodes heard us - shows all the Uplink nodes that have received a position packet from the node.
Ie see how far away a particular node has been heard - even multi-hop. (just with the limitation would only know about uplink nodes that heard the node, and again only if the upload node itself published its position)
(When I say 'Uplink Node' I think in the code they called the 'gateway' node. Saved packets store the gateway_id. So ultimately its viewing nodes by which gateway(s) they connected to)
The text was updated successfully, but these errors were encountered:
barryhunter
changed the title
feature request: filter by node doing the uplink
feature request: view nodes by which gateways they heard by
May 31, 2024
Been looking in the code more. So effectively the Nodes we heard (again only functional on uplink/gateway nodes) would be
SELECT node_id FROM position WHERE gateway_id = {nodeId}
... all the nodes heard.
And Nodes heard us would be
SELECT `gateway_id` FROM `Position` WHERE `from` = {nodeId}
UNION
SELECT `gateway_id` FROM `TextMessage` WHERE `from` = {nodeId}
... then lookinup which of those gateways have a known position or as one query...
SELECT p.`from`, latitude_i, longitude_i
FROM Position p INNER JOIN ServiceEnvelope se ON (se.gateway_id = p.from)
WHERE se.from = {nodeId}
... which is finding the gateways with position packets, that have 'received' a packet from specific node. Shows all the gateways - if there are multiple. If there may be gateways without a position in the database, they will naturally be exlucded.
I think the ServiceEnvelope table, would include a row for all packets received from a particular node. Regardless if a position/text etc packet. So the easiest to use.
sorry, not familiar with prisma syntax! Hoping the mysql format, might make it clearer what asking. Asmint strugging to explain clearly!
I think it would would be interesting to be able to either filter or view nodes by the Uplink Node.
Essentially the ID in the original MQTT topic
msh/UK/2/c/LongFast/!da545934
Position messages on that topic, will just be the nodes that !da545934 is able to hear (even multi-hop).
While neighbours is good, and it is specifically the 'direct' neighbours. This would show the nodes, the particular node received, even multi-hop. which would show more of the mesh coverage. (although would only work if the Uplink node itself is publishing its position!)
Could be kinda like the 'Neighbours' buttons, and just draws a line to every node it has received a position report from.
Maybe
Nodes we heard
- analogous to the 'neighbours (we heard)' - ie it's not just direct neighbours, but all nodes heard.Or maybe could be that enter a Node ID in search, and it would only show reports via that Node.
But could also have the reverse.
Nodes heard us
- shows all the Uplink nodes that have received a position packet from the node.Ie see how far away a particular node has been heard - even multi-hop. (just with the limitation would only know about uplink nodes that heard the node, and again only if the upload node itself published its position)
(When I say 'Uplink Node' I think in the code they called the 'gateway' node. Saved packets store the gateway_id. So ultimately its viewing nodes by which gateway(s) they connected to)
The text was updated successfully, but these errors were encountered: