Plumb timeout from --timeout through MeshInterface

[horrible-knots]

This should fix #838. It adds a timeout parameter to the tcp, ble, stream, and serial interfaces, which gets passed down to MeshInterface directly or through StreamInterface. I tested a short and long timeout through serial and tcp and it honors it now.

[CLAassistant]

All committers have signed the CLA.

[ianmcorvidae]

Thanks for this. Looks pretty good to me, seeing if CI catches anything but otherwise should be good to go I think.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 59.99%. Comparing base (7554c03) to head (2de7c30).
⚠️ Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #839   +/-   ##
=======================================
  Coverage   59.99%   59.99%           
=======================================
  Files          24       24           
  Lines        4267     4267           
=======================================
  Hits         2560     2560           
  Misses       1707     1707           

Flag	Coverage Δ
unittests	59.99% <100.00%> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[roberthadow]

When is a --timeout command likely to be rolled out to a firmware version and documentation?

[horrible-knots]

When is a --timeout command likely to be rolled out to a firmware version and documentation?

It's not a new feature of the CLI or related to the firmware. It's the timeout on waiting for a response from a node. It fixes a bug that made MeshInterface use the default 20 second timeout, making it difficult to administer remote nodes over a few hops.

[roberthadow]

I have a small fleet of Heltec V3s, the cheapest of the bunch, and likely the slowest. I use a bash script to test and exercise them over tcp Between each command set is a sleep of 60 seconds. Nevertheless, for anything beyond a broadcast or direct message, say an acknowledgement or traceroute, it's more likely I get a timeout than a response.

meshtastic --host 192.168.1.202 --traceroute '!b4c7a8df' 
sleep 60s
echo " "
meshtastic --host 192.168.1.203 --traceroute '!b4c7a8df' 
sleep 60s
echo " "

My interpretation of the thread above is that the Python standard timeout is 20 seconds and you were suggesting the timeout period to be user-adjustable as a preference. I frankly don't know whether this is a function of the device firmware or the meshtasticd library.

[horrible-knots]

I see, the bug has affected you too. If you run meshtastic --help you'll see --timeout SECONDS How long to wait for replies. Default 300s. It was always intended to be configurable, with a default of 5 minutes. The PR will make it actually wait 5 minutes, or however long you specify.

This is as opposed to timing out after 20 seconds and not being controllable by the --timeout parameter, which is the cause of "it's more likely I get a timeout than a response" if you're expecting a successful traceroute.

This is fully a bug in the meshtastic CLI not waiting long enough.

[roberthadow]

So is --timeout 999 a part of meshtasticd or part of of the firmware? If the first, I assume that it will part of the meshtasticd release that follows 2.7.3. If the second, a version that follows 2.7.12...

If it's a part of meshtasticd, it would be nice if --timeout would be sticky, rather than being a parameter required at each execution of meshtastic.

It would be nicer still if --timeout were part of the device firmware user configuration. That way, any command requiring a LoRa response, no matter whether from CLI over TCP, over serial or USB, or BLE would wait for a response before failing.

[horrible-knots]

I think there's been some confusion about and nature of this PR and the names and purposes of meshtastic tools.

This fix is solely for the Meshtastic Python CLI tool. It is not a firmware change, and it’s not related to meshtasticd. Just to clarify:

• meshtasticd allows you to simulate a Meshtastic device for testing purposes.
• The Python CLI allows you to connect to a real or simulated Meshtastic device and send commands.

Regarding making --timeout persistent or user-configurable in the device:
That would be a larger feature request. It's definitely out of scope for this bugfix PR, but might be worth opening a separate issue or discussion thread if you'd like to propose that.

To reiterate, this PR:

• Fixes a bug in the CLI’s timeout handling.
• Doesn’t touch firmware or meshtasticd.
• Doesn’t add new features -- it makes existing documented behavior actually work.

I’d like to keep the scope here focused on resolving #838.