Add cmd_delay to serial connections for slow hosts#41
Conversation
On older hosts, like Raspberry Pi model B, the default delay of 0.5 seconds sometimes would expire before the serial device would respond with data. This change allows the delay between issuing the command and reading the result to be increased for older hosts.
|
This issue was discussed briefly in the LetsMesh forum. https://forum.letsmesh.net/t/problem-generating-tokens/622 |
| def _send(self, cmd: str) -> str: | ||
| """Send command and read response under lock.""" | ||
| with self._lock: | ||
| return self._send_unlocked(cmd, delay) |
There was a problem hiding this comment.
An AI review flagged the following issue which at a glance at least appears to be a valid problem:
PR #41 introduces a startup-breaking NameError in serial mode. In /tmp/mesh-pr41/bridge/serial_connection.py:79, the refactor removes the delay parameter but still calls _send_unlocked(cmd, delay) at /tmp/mesh-pr41/bridge/serial_connection.py:82. Any command path that uses _send() (set_time(), get_name(), get_pubkey(), etc.) will crash before the bridge can finish startup. Risk: very high, direct regression.
There was a problem hiding this comment.
Sorry, it appears that I missed removing the delay parameter here. When I get on the system that has the repo, I will submit another commit to fix this and push it.
Signed-off-by: Gerard Hickey <hickey@kinetic-compute.com>
|
Sorry for the delay, I finally had more than 2 mins to get this PR updated. Should be good to go now. |
On older hosts, like Raspberry Pi model B, the default delay of 0.5 seconds sometimes would expire before the serial device would respond with data. This change allows the delay between issuing the command and reading the result to be increased for older hosts.