mirror of
https://github.com/jkingsman/Remote-Terminal-for-MeshCore.git
synced 2026-10-30 22:41:57 +01:00
messages using pyMC via TCP zero hop only #211
Assignees
adam (Adam Wojcieszonek)
Clear assignees
adam (Adam Wojcieszonek)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: adam/Remote-Terminal-for-MeshCore#211
Reference in new issue
Block a user
hi
messages sent on Remote-Terminal using pyMC companion via TCP are only seen zero hop only. are not getting repeated.
I see them on close by compainions but are not getting repeated.
If I connect my phone with offical android app to that same IP/PORT (virtual companion) it works fine.
thank you
N7eal
Hmmm that's going to be a bit tricky to debug without capture of what's going across the wire. Officially, we only support direct connection to the radio. Do you see any illuminating information with debug mode turned on (see the advanced Readme for instructions)? Incorrect broadcast mode seems very odd; are you seeing this with group messages? Can you validate with letsmesh or etc.?
only thing I see is the TX queue showing something other than zero, but my other desktop client (colorado mesh) that connects to the same pyMC virtual companion shows similar numbers. So maybe it's a pyMC problem... but I can transmit and get repeated just fine on that app.
I do see it on the letmesh or wcmesh analyzer.wcmesh.com but only because that pyMC is an observer feeding Letmesh; however, I do not see it repeated by any repeater including my own 10 feed away.
And I assume you've validated this with another client and you see messages going out? Have you changed the hop width in RemoteTerm and perhaps your nearest repeater is not multibyte compatible?
I've added some more information about message-send scope to debug logging (running with env var
MESHCORE_LOG_LEVEL=DEBUG) that might be illuminating; let me know what you see.yes I also use Colorado-mesh desktop client (windows) and messages going out thru pyMC are fine and hop away.
were in Remote-terminal is the hop width setting? I'm on windows.
have a lot of near by repeaters don't think it's multi byte, works fine on the other pyMC client.
I will try the debug.
there are people using it with pyMC, I see it discussed on their discord https://discord.gg/ruTyUPHt
I set log to debug in the config.py, did not see anything that jumped out at me.
It's in the radio settings pane. There are MANY bugs with pymc, some of which are being fixed right now and some of which have been fixed on pymc head. Are you running the bleeding edge most recent version of pymc?
I spent some time getting pyMC (openhop) core to expose a working frameserver that properly supports remoteterm because I want SPI device support - https://github.com/Irate-Architect/openhop_core - there is a lot that has to change for full support.
Did this end up resolving? I've generally adopted a policy of guaranteeing support with stock firmware but not trying to whackamole bugs with pyMC or any platform that has divergence from the mainline firmware interface. Generally, if you have some packet samples for me I can do my best but at the end of the day, to be totally honest, I'm not super interested in spinning up a pymc instance to chase down implementation spec divergences heh.
I've spent most of the last two weeks working on firmware conformance in openHop. I started using RemoteTerm full time a few days ago, and it's working well now. There were some major inconsistencies across the companion implementation and specific deficiencies in the openHop companion login process around path and req packets and path teaching. Please give it another try and let me know if you see other issues.
Many many thanks @agessaman -- yay for smooth sailing!