Bash is a great way to turn management of nodes into a workflow. For it to be truly useful, one needs to capture the responses in the terminal and be able to act on them. In a perfect world, the response to a command would be in a single line of response. Take, for example, a command to send a message. The response is four lines.
meshtastic --tcp 192.168.1.200 --dest '!b2a74524' --sendtext "Hello W2NJ Yagi 4524, W2NJ Mobile BB38 is calling to check on you." --ack --timeout 60
> Connected to radio
> Sending text message Hello W2NJ Yagi 4524, W2NJ BB38 is calling to check on you. to !b29fa658 on channelIndex:0
> Waiting for an acknowledgment from remote node (this could take a while)
> Received an ACK.
If you are reading off the terminal, that's probably okay. If you are trying to automate a process, it would look more like this:
MESSAGE="Hello ${DUT}, ${ATE} is calling to check on you."
meshtastic --tcp $ATEIP --dest $DUTID --sendtext "$MESSAGE" --ack --timeout $TIMEOUT
or better yet,
MESSAGE="Hello ${DUT}, ${ATE} is calling to check on you."
DUTREPLY=$(meshtastic --tcp $ATEIP --dest $DUTID --sendtext "$MESSAGE" --ack --timeout $TIMEOUT)
echo "Reply was $DUTREPLY"
The problem is that DUTREPLY is simply : "Connected to radio". What's we are really interested in is the end result on the fourth line, "Received an ACK".
Okay, maybe I could figure out how to capture the fourth line of reply. But there isn't alway a fourth line of reply. In the case below, all of the stdout goes to a file. The Meshatstic application doesn't take advantage of the stderr facility.
meshtastic --tcp $ATEIP --dest $DUTID --request-telemetry 2>&1 > $DUTTELE
> Connected to radio {stdout directed to a file}
> Sending device_metrics telemetry request tAborting due to: Timed out waiting for telemetryo !b29fa658 on channelIndex:0 (this could take a while)
> Aborting due to: Timed out waiting for telemetry
Meshtastic does not currently differentiate succesful termination output from error messages. I have resorted to the kluge of looking at file sizes to figure out whether a command was successsful or not. A telemetry request that failed is 166 bytes. A Connection Refused (Error 113) output is 61 B, and so on.
My suggestion/request is that Meshtastic regulalry prints a success or exit=0 message to stderr for any normal completion. Bt default, UNIX sends both stdout and sterror to stdout. No changes to user bash scripts are required. At the conclusion of execution, Meshtastic should send to stderr an exit code of zero for successful completion, and whetever non-zero error message currently obtains. If the user desires to monitor the stderr stream, that is his or her prerogative.
This request would not require a pile of refactoring all at once. Instead, each time the code corresponding to a Meshtasitc argument is touched, add the code required to send a success or failure messages to stderr. A good place to start would be this message, "Aborting due to: Timed out waiting for telemetry." Rewrite the output as an error, give it a number, and route it to stderr.
Bash is a great way to turn management of nodes into a workflow. For it to be truly useful, one needs to capture the responses in the terminal and be able to act on them. In a perfect world, the response to a command would be in a single line of response. Take, for example, a command to send a message. The response is four lines.
If you are reading off the terminal, that's probably okay. If you are trying to automate a process, it would look more like this:
or better yet,
The problem is that DUTREPLY is simply : "Connected to radio". What's we are really interested in is the end result on the fourth line, "Received an ACK".
Okay, maybe I could figure out how to capture the fourth line of reply. But there isn't alway a fourth line of reply. In the case below, all of the stdout goes to a file. The Meshatstic application doesn't take advantage of the stderr facility.
Meshtastic does not currently differentiate succesful termination output from error messages. I have resorted to the kluge of looking at file sizes to figure out whether a command was successsful or not. A telemetry request that failed is 166 bytes. A Connection Refused (Error 113) output is 61 B, and so on.
My suggestion/request is that Meshtastic regulalry prints a success or exit=0 message to stderr for any normal completion. Bt default, UNIX sends both stdout and sterror to stdout. No changes to user bash scripts are required. At the conclusion of execution, Meshtastic should send to stderr an exit code of zero for successful completion, and whetever non-zero error message currently obtains. If the user desires to monitor the stderr stream, that is his or her prerogative.
This request would not require a pile of refactoring all at once. Instead, each time the code corresponding to a Meshtasitc argument is touched, add the code required to send a success or failure messages to stderr. A good place to start would be this message, "Aborting due to: Timed out waiting for telemetry." Rewrite the output as an error, give it a number, and route it to stderr.