Open brad07x opened 1 month ago
Adding a little more info from testing - I noticed that responses to a mesh DM with the $ping
command partially worked - they were sent as broadcasts.
Reviewing MeshLink.py showed the ping command was the only one that didn't have destinationId=packet["toId"]
in the interface.sendText
method.
I can remove destinationId=packet["toId"]
from the other command and get responses, but as expected they are also sent as broadcasts.
I think I partially figured it out - all commands that include destinationId=packet["toId"]
in the interface.sendText
method need to be changed to destinationId=packet["fromId"]
instead, and mesh DM replies work.
The issue with this is that although DMs work fine, bot replies to broadcast messages on the channel with MeshLink are only sent to the source node that made the request (as a DM). I can see the command requests on other radios but only the requester gets a response from MeshLink after these modifications.
I'll keep poking to see if I can figure out a way to make it work both ways. It seems a check is needed for command responses to only include the destinationId=packet["fromId"]
argument if the original decoded packet's toID was not set to 'all' ('toId': '^all'
).
Very ugly solution, but arrived at something that somewhat works. Pardon the inexperience/spaghetti.
Just finished testing the snippet below with success on my local mesh by copying the help
command and modifying.
Mesh commands sent to broadcast (^all
) for the example dmdebug
command below were replied to with broadcasts, while mesh commands sent as DMs and including a nodeid in the fromID
were replied to with DMs.
elif (noprefix.startswith("dmdebug")):
final_dmdebug = "*** Incoming Message - DMDebug ***\n"+"From ID: "+packet["fromId"]+"\n"+"To ID: "+packet["toId"]
if (packet["toId"] != '^all'):
interface.sendText(final_dmdebug,channelIndex=config["send_channel_index"], destinationId=packet["fromId"])
elif (packet["toId"] == '^all'):
interface.sendText(final_dmdebug,channelIndex=config["send_channel_index"])
if(config["send_mesh_commands_to_discord"]):
send_msg("`MeshLink`> "+final_dmdebug)
Ok thank you for this fix. I will add it in the next major update. (Which also adds plugins)
Thanks for sharing a great project!
DM Responses Issue (or Feature Request if expected/not yet implemented): I noticed that MeshLink does not seem to respond to incoming direct messages from the mesh, but does still decode and process commands just fine (just without returning the results to the DM sender).
Messages sent to Broadcast within the mesh channel work fine and receive responses from MeshLink both on the Mesh and within Discord without any issues.
Steps:
send_mesh_commands_to_discord: True
config setting),Additional DM Enhancements/Feature Ideas: It would be awesome if functionality could be added to MeshLink to permit Discord channel users to DM a mesh node, i.e.
$dm <nodename> <message>
.Conversely, I noticed that mentions
@discordusername
from the mesh do not get processed as such when MeshLink publishes the message to Discord; they just show in plaintext. While I think that implementing actual Discord DM from MeshLink would likely be beyond the scope of the project, facilitating mentions in from incoming mesh messages that get published to the Discord message channel would be very useful for how I'd like to leverage the project.One other feature to consider concerning DMs could also be to provide a config setting to force MeshLink to only respond to incoming Mesh DMs and ignore broadcast messages on the mesh, similar to what @SpudGunMan has implemented in https://github.com/SpudGunMan/meshing-around. The mesh command prefix could be dropped if this were the case (as I would imagine most users would dedicate a serial node to MeshLink only/only one connection supported at a time).