Hi.
Not sure, but kind of snr it shows when someone who pinged it via hop atleast?
2025-11-10 13:08:31,552 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 13:08:31,553 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: M1DEA_4
2025-11-10 13:08:31,554 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: M1DEA_4 isDM:False playing:False
2025-11-10 13:08:31,555 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:5.25 RSSI:-69 To: M1DEA_4
I assume it shoud said about 1 hop only isn't it?
<!-- github-sync-id:3607248438 -->
Yea what's the setup? UDP bot? Directly near a normal node? It detected the flood but had the data to show a RF path still?
Yea what's the setup? UDP bot? Directly near a normal node? It detected the flood but had the data to show a RF path still?
<!-- github-comment-id:3510730434 -->
Main node on my window with wifi connection interact with:
Outside via RF.
With meshbot via wifi.
With other nodes set into client_mute available via RF and wifi with udp config enabled.
Main node on my window with wifi connection interact with:
Outside via RF.
With meshbot via wifi.
With other nodes set into client_mute available via RF and wifi with udp config enabled.
<!-- github-comment-id:3510798201 -->
Can you checkout the latest lab branch and look at the debug logs added let me know what you think - I suspect this is UDP echo but want to find a better way to trap it
Can you checkout the latest lab branch and look at the debug logs added let me know what you think - I suspect this is UDP echo but want to find a better way to trap it
<!-- github-comment-id:3518851680 -->
Can you checkout the latest lab branch and look at the debug logs added let me know what you think - I suspect this is UDP echo but want to find a better way to trap it
Not sure how can I do it with update.sh script?
> Can you checkout the latest lab branch and look at the debug logs added let me know what you think - I suspect this is UDP echo but want to find a better way to trap it
Not sure how can I do it with update.sh script?
<!-- github-comment-id:3519889546 -->
It should say something switched and launch like normal
Should boot up with more debug logs running
After an update and while stopped bot not running
Do a sudo `git checkout lab`
It should say something switched and launch like normal
Should boot up with more debug logs running
<!-- github-comment-id:3520048952 -->
It should say something switched and launch like normal
Should boot up with more debug logs running
No lab nor main:
./launch.sh mesh
Traceback (most recent call last):
File "/home/service5/meshing-around/mesh_bot.py", line 16, in
from modules.system import *
File "/home/service5/meshing-around/modules/system.py", line 7, in
from meshtastic.util import generate_channel_hash
ImportError: cannot import name 'generate_channel_hash' from 'meshtastic.util' (/home/service5/meshing-around/venv/lib/python3.11/site-packages/meshtastic/util.py)
> After an update and while stopped bot not running
>
> Do a sudo `git checkout lab`
>
> It should say something switched and launch like normal
>
> Should boot up with more debug logs running
No lab nor main:
./launch.sh mesh
Traceback (most recent call last):
File "/home/service5/meshing-around/mesh_bot.py", line 16, in <module>
from modules.system import *
File "/home/service5/meshing-around/modules/system.py", line 7, in <module>
from meshtastic.util import generate_channel_hash
ImportError: cannot import name 'generate_channel_hash' from 'meshtastic.util' (/home/service5/meshing-around/venv/lib/python3.11/site-packages/meshtastic/util.py)
<!-- github-comment-id:3520099542 -->
Yea you kinda get one free hop. Is the saying the first or the last
This is a direct radio flood route ping response, any hops beyond here should be hopping?
This is an ideal outcome? No?
Yea you kinda get one free hop. Is the saying the first or the last
This is a direct radio flood route ping response, any hops beyond here should be hopping?
This is an ideal outcome? No?
<!-- github-comment-id:3520655228 -->
Yea you kinda get one free hop. Is the saying the first or the last
But this confuses users, no idea what do you mean by one free hop.
Your logs clearly shows 1 hop counted, why does bot sends not just 1 Hop received but snr data from last node it sends??
> Yea you kinda get one free hop. Is the saying the first or the last
But this confuses users, no idea what do you mean by one free hop.
Your logs clearly shows 1 hop counted, why does bot sends not just 1 Hop received but snr data from last node it sends??
<!-- github-comment-id:3520664949 -->
??
It looks like iam missing something, there is no direct radio connection when you had it in one hop.
> This is a direct radio flood route ping response
??
It looks like iam missing something, there is no direct radio connection when you had it in one hop.
<!-- github-comment-id:3520675068 -->
The added [F] also indicates its flood or fishy nature. But the experience for the end user is higher as it has the RF data.
The hop beyond here will drop that data and be back in 2hop
And any real RF will not add the [F] but only hops
So the common use case (what you have setup) for this new UDP mode would be working ideally for meshing-around
who wants to set it up and see 1 hop for every single ping always?
The added [F] also indicates its flood or fishy nature. But the experience for the end user is higher as it has the RF data.
The hop beyond here will drop that data and be back in 2hop
And any real RF will not add the [F] but only hops
So the common use case (what you have setup) for this new UDP mode would be working ideally for meshing-around
who wants to set it up and see 1 hop for every single ping always?
<!-- github-comment-id:3520965124 -->
> who wants to set it up and see 1 hop for every single ping always?
Looks like i clearly don't get your idea.
Uses asks what the hell is going on, because thay are pretty sure they cannot be so close to the bot as it says with snr.
This is example of normal answer from one of my portable nodes:
2025-11-12 08:46:21,340 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:5 hop_start:5 calculated_hop_count:0 fi
nal_hop_value:Direct via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 08:46:21,341 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: ZedIsPb2
2025-11-12 08:46:21,342 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: ZedIsPb2 isDM:False pl
aying:False
2025-11-12 08:46:21,342 | INFO | Device:1 Sending DM: 🏓PONG [RF] SNR:6.0 RSSI:-37 To: ZedIsPb2
Here from some other users with good view on my node and my local node via wifi connected:
2025-11-11 20:00:37,199 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:5 hop_start:5 calculated_hop_count:0 fi
nal_hop_value:Direct via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-11 20:00:37,200 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: Juiroy
2025-11-11 20:00:37,203 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: Juiroy isDM:False play
ing:False
2025-11-11 20:00:37,204 | INFO | Device:1 Sending DM: 🏓PONG [RF] SNR:-13.25 RSSI:-100 To: Juiroy
2025-11-11 20:01:01,245 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:5 hop_start:5 calculated_hop_count:0 fi
nal_hop_value: via_mqtt:False transport_mechanism:TRANSPORT_MULTICAST_UDP Hostname:None
2025-11-11 20:01:01,246 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: ZedIsSttn1
2025-11-11 20:01:01,247 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: ZedIsSttn1 isDM:False
playing:False
2025-11-11 20:01:01,248 | INFO | Device:1 Sending DM: 🏓PONG [F] To: ZedIsSttn1
2025-11-11 20:01:06,581 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:1 hop_start:1 calculated_hop_count:0 fi
nal_hop_value:Direct via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-11 20:01:06,583 | INFO | Device:1 Channel: 0 Received DM: test From: Juiroy
2025-11-11 20:01:06,584 | DEBUG | System: Bot detected Commands:[{'cmd': 'test', 'index': 0}] From: Juiroy isDM:True playi
ng:False
2025-11-11 20:01:06,585 | INFO | Device:1 Sending DM: 🎙Roger that! [RF] SNR:-14.0 RSSI:-101 To: Juiroy
<!-- github-comment-id:3521004661 -->
Anyway, how about add some config option, to says one hop when it is really one hop?
Atleast for those like me it will be usable to prevent question from users.
Anyway, how about add some config option, to says one hop when it is really one hop?
Atleast for those like me it will be usable to prevent question from users.
<!-- github-comment-id:3521015183 -->
Next example, user goes via 1 hop node that looks at mine with bot.
This is one hop, no snr shoud be there as they are thinking it was received directly.
Next example, user goes via 1 hop node that looks at mine with bot.
This is one hop, no snr shoud be there as they are thinking it was received directly.
2025-11-12 13:27:34,036 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 13:27:34,037 | INFO | Device:1 Channel:0 ReceivedChannel: Ping From: SIRIUS_1
2025-11-12 13:27:34,038 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: SIRIUS_1 isDM:False playing:False
2025-11-12 13:27:34,039 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:-19.5 RSSI:-107 To: SIRIUS_1
<!-- github-comment-id:3521242812 -->
You could always remove the UDP node? If you don't like the way it works just change the build?
So you suggest to disable udp config option for the node that is used by bot?
> You could always remove the UDP node? If you don't like the way it works just change the build?
So you suggest to disable udp config option for the node that is used by bot?
<!-- github-comment-id:3522912955 -->
It sounds like you have two nodes connected in such a way the product is behaving optimally for all users?
If you had one node only segmented it wouldn't be this way?
Did you watch the logs in lab
It sounds like you have two nodes connected in such a way the product is behaving optimally for all users?
If you had one node only segmented it wouldn't be this way?
Did you watch the logs in lab
<!-- github-comment-id:3523151517 -->
Not really get it of what should i do to make it work correctly.
I used it as my usual setup it behaves incorrect, i made it with your recommendation to disable udp config option to prevent data exchange via lan with other node - it still behaves incorrect.
Not really get it of what should i do to make it work correctly.
I used it as my usual setup it behaves incorrect, i made it with your recommendation to disable udp config option to prevent data exchange via lan with other node - it still behaves incorrect.
<!-- github-comment-id:3523241780 -->
Why would the removal of F and loss of data be good here? I don't get it
Can you draw a picture of how everything is connected and configured for UDP or MQTT and RF channel 0 name?
Why would the removal of F and loss of data be good here? I don't get it
Can you draw a picture of how everything is connected and configured for UDP or MQTT and RF channel 0 name?
<!-- github-comment-id:3523264053 -->
Why would the removal of F and loss of data be good here? I don't get it
Iam not asking of removal.
Iam only asking for provide correct info to the users.
Right now users who in one hop from the bot, after sending ping not gettings message with 1hop, but message with snr in text, so they are thinking bot sees them directly - but it is not.
We do a lot of traces, they still under one hop, not directly.
> Why would the removal of F and loss of data be good here? I don't get it
Iam not asking of removal.
Iam only asking for provide correct info to the users.
Right now users who in one hop from the bot, after sending ping not gettings message with 1hop, but message with snr in text, so they are thinking bot sees them directly - but it is not.
We do a lot of traces, they still under one hop, not directly.
<!-- github-comment-id:3523375128 -->
When m4da sends ping message for zed9, bot sees 1 hop correctly (check logs above).
But for some reason instead of answer to m4da message saying 1hop - bot says: pong snr rssi.
This is the problem.
> Can you draw a picture of how everything is connected and configured for UDP or MQTT and RF channel 0 name?
RF everywhere:
m4da - klvr - zed9(heltec-wifi-bot)
When m4da sends ping message for zed9, bot sees 1 hop correctly (check logs above).
But for some reason instead of answer to m4da message saying 1hop - bot says: pong snr rssi.
This is the problem.
<!-- github-comment-id:3523646959 -->
Problem is relative if you shut off UDP how is the RF everywhere not causing the problem with UDP
Do you use UDP?
Did you look at the flood logs and specifically the log output in alpha.
I didn't see full configs and have no problem with the output myself
Do you want me to keep it exactly like it is and add 1 hop to this one message only just for your config decisions?
What about everyone else who wants the data displayed and isn't wanting every single ping to be 1 hop in this configuration?
Problem is relative if you shut off UDP how is the RF everywhere not causing the problem with UDP
Do you use UDP?
Did you look at the flood logs and specifically the log output in alpha.
I didn't see full configs and have no problem with the output myself
Do you want me to keep it exactly like it is and add 1 hop to this one message only just for your config decisions?
What about everyone else who wants the data displayed and isn't wanting every single ping to be 1 hop in this configuration?
<!-- github-comment-id:3523677282 -->
Problem is relative if you shut off UDP how is the RF everywhere not causing the problem with UDP
Where is this option?
If it is settings - network - udp config on the heltec side, i already disabled that, nothing changed.
Do you use UDP?
Maybe we are talking about different settings?
Is it somewhere in the bot config?
Did you look at the flood logs and specifically the log output in alpha.
Where is it?
I have posted all the log i see from the bot related to the messages exchange with users.
I didn't see full configs and have no problem with the output myself
Do you want me to keep it exactly like it is and add 1 hop to this one message only just for your config decisions?
What about everyone else who wants the data displayed and isn't wanting every single ping to be 1 hop in this configuration?
Everyone else on the direct connected normally gets RF snr rssi as it should.
It looks like for some reason, iam not undestand, issue only with one hop sitting users.
> Problem is relative if you shut off UDP how is the RF everywhere not causing the problem with UDP
>
Where is this option?
If it is settings - network - udp config on the heltec side, i already disabled that, nothing changed.
> Do you use UDP?
>
Maybe we are talking about different settings?
Is it somewhere in the bot config?
> Did you look at the flood logs and specifically the log output in alpha.
>
Where is it?
I have posted all the log i see from the bot related to the messages exchange with users.
> I didn't see full configs and have no problem with the output myself
>
> Do you want me to keep it exactly like it is and add 1 hop to this one message only just for your config decisions?
>
> What about everyone else who wants the data displayed and isn't wanting every single ping to be 1 hop in this configuration?
Everyone else on the direct connected normally gets RF snr rssi as it should.
It looks like for some reason, iam not undestand, issue only with one hop sitting users.
<!-- github-comment-id:3523772035 -->
How far apart are the nodes the bot and you. Are they on the same WiFi network can they ping each other
How far apart are the nodes the bot and you. Are they on the same WiFi network can they ping each other

<!-- github-comment-id:3523791291 -->
How far apart are the nodes the bot and you. Are they on the same WiFi network can they ping each other
m4da in a few kilometers
klvr hightower in a few houses up on the road - 1-2 kilometers.
There is no wifi connections in between of this nodes.
Disabled.
> How far apart are the nodes the bot and you. Are they on the same WiFi network can they ping each other
>
m4da in a few kilometers
klvr hightower in a few houses up on the road - 1-2 kilometers.
There is no wifi connections in between of this nodes.
> 
Disabled.
<!-- github-comment-id:3523822740 -->
> I thought this was all local all long.
>
> Can you try the alpha again
2025-11-13 09:06:58,367 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop (Relay:148) via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-13 09:06:58,368 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: DUB4
2025-11-13 09:06:58,369 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: DUB4 isDM:False playing:False
2025-11-13 09:06:58,370 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:5.75 RSSI:-66 To: DUB4
No msg 1 hop again, will update to the latest.
<!-- github-comment-id:3525690528 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Hi.
Not sure, but kind of snr it shows when someone who pinged it via hop atleast?
2025-11-10 13:08:31,552 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 13:08:31,553 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: M1DEA_4
2025-11-10 13:08:31,554 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: M1DEA_4 isDM:False playing:False
2025-11-10 13:08:31,555 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:5.25 RSSI:-69 To: M1DEA_4
I assume it shoud said about 1 hop only isn't it?
Yea what's the setup? UDP bot? Directly near a normal node? It detected the flood but had the data to show a RF path still?
Main node on my window with wifi connection interact with:
Outside via RF.
With meshbot via wifi.
With other nodes set into client_mute available via RF and wifi with udp config enabled.
2025-11-10 13:48:31,168 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 13:48:31,169 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: M1DEA_4
2025-11-10 13:48:31,171 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: M1DEA_4 isDM:False playing:False
2025-11-10 13:48:31,172 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:6.0 RSSI:-68 To: M1DEA_4
2025-11-10 13:55:24,802 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 13:55:24,804 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: M1DEA_4
2025-11-10 13:55:24,805 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: M1DEA_4 isDM:False playing:False
2025-11-10 13:55:24,806 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:5.0 RSSI:-70 To: M1DEA_4
So, we got 1 hop.
Why does bot doesn't show 1 hop)
Some other log marked as F and snr
2025-11-10 16:23:23,432 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:2 hop_start:5 calculated_hop_count:3 final_hop_value:3 Hops via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 16:23:23,433 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: !82e2040e
2025-11-10 16:23:23,434 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: !82e2040e isDM:False playing:False
2025-11-10 16:23:23,435 | INFO | Device:1 Sending DM: 🏓PONG [F] 3 Hops🐇 To: !82e2040e
2025-11-10 16:23:42,826 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 16:23:42,827 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: !82e2040e
2025-11-10 16:23:42,829 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: !82e2040e isDM:False playing:False
2025-11-10 16:23:42,830 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:-10.75 RSSI:-96 To: !82e2040e
2025-11-10 16:25:01,391 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:3 hop_start:5 calculated_hop_count:2 final_hop_value:2 Hops via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-10 16:25:01,392 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: !82e2040e
2025-11-10 16:25:01,394 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: !82e2040e isDM:False playing:False
2025-11-10 16:25:01,394 | INFO | Device:1 Sending DM: 🏓PONG [F] 2 Hops🐇 To: !82e2040e
Can you checkout the latest lab branch and look at the debug logs added let me know what you think - I suspect this is UDP echo but want to find a better way to trap it
Not sure how can I do it with update.sh script?
After an update and while stopped bot not running
Do a sudo
git checkout labIt should say something switched and launch like normal
Should boot up with more debug logs running
No lab nor main:
./launch.sh mesh
Traceback (most recent call last):
File "/home/service5/meshing-around/mesh_bot.py", line 16, in
from modules.system import *
File "/home/service5/meshing-around/modules/system.py", line 7, in
from meshtastic.util import generate_channel_hash
ImportError: cannot import name 'generate_channel_hash' from 'meshtastic.util' (/home/service5/meshing-around/venv/lib/python3.11/site-packages/meshtastic/util.py)
Basically it won't start even with a clean config from a config.template at all.
Rerun pip install requirements and after upgrade of meshtastic it started. Will take a look for logs.
Thanks, also cleaned up this error
Still 1 hope but snr:
2025-11-12 11:05:39,652 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 11:05:39,653 | INFO | Device:1 Channel:0 ReceivedChannel: Ping From: Meshtastic b618
2025-11-12 11:05:39,655 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: Meshtastic b618 isDM:False playing:False
2025-11-12 11:05:39,657 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:1.25 RSSI:-87 To: Meshtastic b618
This one does for 2 hopes today:
2025-11-12 11:05:32,619 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:3 hop_start:5 calculated_hop_count:2 final_hop_value:2 Hops via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 11:05:32,619 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: M1DEA_4
2025-11-12 11:05:32,621 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: M1DEA_4 isDM:False playing:False
2025-11-12 11:05:32,622 | INFO | Device:1 Sending DM: 🏓PONG [F] 2 Hops🐇 To: M1DEA_4
2025-11-12 11:08:22,034 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 11:08:22,035 | INFO | Device:1 Channel:0 ReceivedChannel: Ping From: M1DEA_4
2025-11-12 11:08:22,037 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: M1DEA_4 isDM:False playing:False
2025-11-12 11:08:22,038 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:5.75 RSSI:-65 To: M1DEA_4
So, it looks like when we got 1 hop bot mistkengly sends snr intead of message about 1 hop.
Yea you kinda get one free hop. Is the saying the first or the last
This is a direct radio flood route ping response, any hops beyond here should be hopping?
This is an ideal outcome? No?
But this confuses users, no idea what do you mean by one free hop.
Your logs clearly shows 1 hop counted, why does bot sends not just 1 Hop received but snr data from last node it sends??
??
It looks like iam missing something, there is no direct radio connection when you had it in one hop.
The added [F] also indicates its flood or fishy nature. But the experience for the end user is higher as it has the RF data.
The hop beyond here will drop that data and be back in 2hop
And any real RF will not add the [F] but only hops
So the common use case (what you have setup) for this new UDP mode would be working ideally for meshing-around
who wants to set it up and see 1 hop for every single ping always?
Uses asks what the hell is going on, because thay are pretty sure they cannot be so close to the bot as it says with snr.
This is example of normal answer from one of my portable nodes:
2025-11-12 08:46:21,340 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:5 hop_start:5 calculated_hop_count:0 fi
nal_hop_value:Direct via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 08:46:21,341 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: ZedIsPb2
2025-11-12 08:46:21,342 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: ZedIsPb2 isDM:False pl
aying:False
2025-11-12 08:46:21,342 | INFO | Device:1 Sending DM: 🏓PONG [RF] SNR:6.0 RSSI:-37 To: ZedIsPb2
Here from some other users with good view on my node and my local node via wifi connected:
2025-11-11 20:00:37,199 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:5 hop_start:5 calculated_hop_count:0 fi
nal_hop_value:Direct via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-11 20:00:37,200 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: Juiroy
2025-11-11 20:00:37,203 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: Juiroy isDM:False play
ing:False
2025-11-11 20:00:37,204 | INFO | Device:1 Sending DM: 🏓PONG [RF] SNR:-13.25 RSSI:-100 To: Juiroy
2025-11-11 20:01:01,245 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:5 hop_start:5 calculated_hop_count:0 fi
nal_hop_value: via_mqtt:False transport_mechanism:TRANSPORT_MULTICAST_UDP Hostname:None
2025-11-11 20:01:01,246 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: ZedIsSttn1
2025-11-11 20:01:01,247 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: ZedIsSttn1 isDM:False
playing:False
2025-11-11 20:01:01,248 | INFO | Device:1 Sending DM: 🏓PONG [F] To: ZedIsSttn1
2025-11-11 20:01:06,581 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:1 hop_start:1 calculated_hop_count:0 fi
nal_hop_value:Direct via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-11 20:01:06,583 | INFO | Device:1 Channel: 0 Received DM: test From: Juiroy
2025-11-11 20:01:06,584 | DEBUG | System: Bot detected Commands:[{'cmd': 'test', 'index': 0}] From: Juiroy isDM:True playi
ng:False
2025-11-11 20:01:06,585 | INFO | Device:1 Sending DM: 🎙Roger that! [RF] SNR:-14.0 RSSI:-101 To: Juiroy
Anyway, how about add some config option, to says one hop when it is really one hop?
Atleast for those like me it will be usable to prevent question from users.
Next example, user goes via 1 hop node that looks at mine with bot.
This is one hop, no snr shoud be there as they are thinking it was received directly.
2025-11-12 13:27:34,036 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 13:27:34,037 | INFO | Device:1 Channel:0 ReceivedChannel: Ping From: SIRIUS_1
2025-11-12 13:27:34,038 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: SIRIUS_1 isDM:False playing:False
2025-11-12 13:27:34,039 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:-19.5 RSSI:-107 To: SIRIUS_1
You could always remove the UDP node? If you don't like the way it works just change the build?
So you suggest to disable udp config option for the node that is used by bot?
And no it doesn't help!
Here goes 1 hop again, but it was send with snr instead of 1 hop:
2025-11-12 20:19:48,998 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-12 20:19:49,000 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: mobileSky
2025-11-12 20:19:49,002 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: mobileSky isDM:False playing:False
2025-11-12 20:19:49,003 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:-11.75 RSSI:-102 To: mobileSky
It sounds like you have two nodes connected in such a way the product is behaving optimally for all users?
If you had one node only segmented it wouldn't be this way?
Did you watch the logs in lab
Not really get it of what should i do to make it work correctly.
I used it as my usual setup it behaves incorrect, i made it with your recommendation to disable udp config option to prevent data exchange via lan with other node - it still behaves incorrect.
Why would the removal of F and loss of data be good here? I don't get it
Can you draw a picture of how everything is connected and configured for UDP or MQTT and RF channel 0 name?
Iam not asking of removal.
Iam only asking for provide correct info to the users.
Right now users who in one hop from the bot, after sending ping not gettings message with 1hop, but message with snr in text, so they are thinking bot sees them directly - but it is not.
We do a lot of traces, they still under one hop, not directly.
RF everywhere:
m4da - klvr - zed9(heltec-wifi-bot)
When m4da sends ping message for zed9, bot sees 1 hop correctly (check logs above).
But for some reason instead of answer to m4da message saying 1hop - bot says: pong snr rssi.
This is the problem.
Problem is relative if you shut off UDP how is the RF everywhere not causing the problem with UDP
Do you use UDP?
Did you look at the flood logs and specifically the log output in alpha.
I didn't see full configs and have no problem with the output myself
Do you want me to keep it exactly like it is and add 1 hop to this one message only just for your config decisions?
What about everyone else who wants the data displayed and isn't wanting every single ping to be 1 hop in this configuration?
Where is this option?
If it is settings - network - udp config on the heltec side, i already disabled that, nothing changed.
Maybe we are talking about different settings?
Is it somewhere in the bot config?
Where is it?
I have posted all the log i see from the bot related to the messages exchange with users.
Everyone else on the direct connected normally gets RF snr rssi as it should.
It looks like for some reason, iam not undestand, issue only with one hop sitting users.
How far apart are the nodes the bot and you. Are they on the same WiFi network can they ping each other
m4da in a few kilometers
klvr hightower in a few houses up on the road - 1-2 kilometers.
There is no wifi connections in between of this nodes.
Disabled.
I thought this was all local all long.
Can you try the alpha again
Main now has lots of ping changes
Run latest api and firmware
2025-11-13 09:06:58,367 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop (Relay:148) via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-13 09:06:58,368 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: DUB4
2025-11-13 09:06:58,369 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: DUB4 isDM:False playing:False
2025-11-13 09:06:58,370 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:5.75 RSSI:-66 To: DUB4
No msg 1 hop again, will update to the latest.
Yea go to main and pull latest use update.sh
Thanks for sticking with this
One via hop and one in direct. Same behaviour
2025-11-13 09:37:14,370 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop Relay:94 via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-13 09:37:14,371 | INFO | Device:1 Channel:1 ReceivedChannel: Ping From: SIRIUS_1
2025-11-13 09:37:14,373 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: SIRIUS_1 isDM:False playing:False
2025-11-13 09:37:14,374 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:-13.0 RSSI:-100 To: SIRIUS_1
2025-11-13 09:37:32,504 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:0 hop_start:1 calculated_hop_count:0 final_hop_value: Relay:94 via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-13 09:37:32,505 | INFO | Device:1 Channel: 0 Received DM: Ping From: SIRIUS_1
2025-11-13 09:37:32,507 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: SIRIUS_1 isDM:True playing:False
2025-11-13 09:37:32,508 | INFO | Device:1 Sending DM: 🏓PONG [F] SNR:-18.5 RSSI:-107 To: SIRIUS_1
I found a problem!!
Try now 🤞
Hm looks better
2025-11-13 10:05:31,037 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:1 hop_start:5 calculated_hop_count:4 final_hop_value:4 Hops Relay:94 via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-13 10:05:31,038 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: DUB4
2025-11-13 10:05:31,039 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: DUB4 isDM:False playing:False
2025-11-13 10:05:31,040 | INFO | Device:1 Sending DM: 🏓PONG [F] 4 Hops Relay:94 To: DUB4
2025-11-13 10:06:00,595 | DEBUG | System: Packet HopDebugger: hop_away:0 hop_limit:4 hop_start:5 calculated_hop_count:1 final_hop_value:1 Hop Relay:78 via_mqtt:False transport_mechanism:TRANSPORT_LORA Hostname:None
2025-11-13 10:06:00,596 | INFO | Device:1 Channel:1 ReceivedChannel: ping From: DUB4
2025-11-13 10:06:00,597 | DEBUG | System: Bot detected Commands:[{'cmd': 'ping', 'index': 0}] From: DUB4 isDM:False playing:False
2025-11-13 10:06:00,598 | INFO | Device:1 Sending DM: 🏓PONG [F] 1 Hop Relay:78 To: DUB4
What is hop relay?
Whew! Thanks!
It's the last node to have touched the packet
The last two of the !ID