Serial port 'Exception: Timed out waiting for connection completion'

Support
1

I have a t-beam 1.0 connected to a raspberry pi via USB, running regular Meshtastic CLI calls (roughly every hour). Since upgrading the device from 1.1.50 to 1.2.13 and the Meshtastic CLI to 1.2.15, I notice the device seems to go to sleep after a while, resulting in Meshtastic calls throwing a Exception: Timed out waiting for connection completion.

This seems to happen regardless of whether the device is_router true or not.

This seems like new behaviour, so is there a new default timeout I should be using somewhere to prevent this?

2

Now replicated it with a second device connected via USB to a Windows machine.

Starts up fine after a fresh device boot, all Meshtastic CLI calls return normally and it seems as long as I don’t leave it for too long, there are no timeouts. As soon as I have a long enough a delay between CLI calls, I get the Exception: Timed out waiting for connection completion.

3

Thanks for the report. This is fixed in the device code and it will be in the next bin.

2 Likes
4

I’ve upgraded my device to 1.2.17 now and the CLI to the latest 1.2.17 version and I’m still finding these constant timeouts waiting for completion.

These are devices either connected permanently to a Windows or Pi USB port, that will execute a meshtastic CLI every now and then. Things seems fine for a short while, then suddenly all calls timeout and can only be corrected by rebooting the device.

Here’s the output in case it helps identify this behaviour.

> meshtastic --info
> Traceback (most recent call last):
> File “/home/pi/.local/bin/meshtastic”, line 10, in sys.exit(main())
> File “/home/pi/.local/lib/python3.7/site-packages/meshtastic/main.py”, line 637, in main common()
> File “/home/pi/.local/lib/python3.7/site-packages/meshtastic/main.py”, line 496, in common args.port, debugOut=logfile, noProto=args.noproto)
> File “/home/pi/.local/lib/python3.7/site-packages/meshtastic/init.py”, line 1155, in init self, debugOut=debugOut, noProto=noProto, connectNow=connectNow)
> File “/home/pi/.local/lib/python3.7/site-packages/meshtastic/init.py”, line 995, in init self.connect()
> File “/home/pi/.local/lib/python3.7/site-packages/meshtastic/init.py”, line 1012, in connect self._waitConnected()
> File “/home/pi/.local/lib/python3.7/site-packages/meshtastic/init.py”, line 664, in _waitConnected raise Exception(“Timed out waiting for connection completion”)
> Exception: Timed out waiting for connection completion

2 Likes
5

Hmm. Interesting! Those nodes have standard default settings?

6

Yes, fresh full erase and firmware install. 3 devices all exhibit this using both Windows and Raspian.

It looks like the behaviour is that if there are longer gaps between using the CLI, the problem arises, for any of the CLI functions that require access to the device (e.g. --nodes, --info, --sendtext, etc.).

7

How are you rebooting, using the power button or unplugging from power?

8

both work, but when the device is not easily accessible, I now use the --reboot parameter and that clears up the problem.

1 Like
9

i think there is a node bug in general ive tested several radio now

10

Correction. I’ve noticed that these ones are default, except they either use is_low_power true or is_router true.

It seems that disabling either of those and reverting to defaults avoids this problem, so it does seem to be related to the power management of the router or low power modes.

1 Like
11

ah yes this I abelieve has been pointed out about a sleep issue, thank you for your work!

1 Like
12

Yes. Router/low power nodes will drop the usb link when the display is off. This is to save power.

2 Likes