-
Notifications
You must be signed in to change notification settings - Fork 963
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't send to public channel #5310
Conversation
Why would you want to send this to the originating nodenumber? |
So it won't go on default public channel. |
But this means it will not be sent out over LoRa at all. You can make your primary channel private and add the public channel as a secondary channel if you don't want to send it on the public channel. |
That kind of the issue, they don't do that and ends up spamming the channel. |
But not sending it out over LoRa at all is not a proper solution. |
That fair.. Closing it. |
FWIW, I liked the previous idea of adding the configuration of DMing to a specific nodenum destination. Particularly for the use case of detecting a state, I think often the desired recipient is one node on the mesh rather than the whole mesh |
That is also the one I would prefer and Garth wanted at solution that didn't involve changes that might not get into the apps. |
A cli only solution will get essentially zero use. |
I agree this should not be on the default key anymore, the choosing of a channel or an individual node is not something We are currently set up to manage. |
Is this acceptable ? |
Looks good to me |
`p->to` wasn't set and had the same value as broadcast, it's now set to our own NodeNum.
71faa29
to
738a5d7
Compare
p->to
wasn't set and had the same value as broadcast, it's now set to our own NodeNum.