Polling battery voltage using CLI -- request for admin method.

[roberthadow]

I use Heltec V3 and V4. Firmware v2.7.;26
Ubuntu
Python 3.12.3
Meshtstic v2.7.10

I want to poll device battery voltage remotely. From my PC, I can use the web interface for USB-connected devices to see battery voltage.

For those devices connected by WiFi, I can query the device directly. I capture the file NODE.info and use grep to extract battery voltage.

meshtastic --tcp 192.168.1.203 --info --timeout 60
# This works
meshtastic --tcp 192.168.1.203 --request-telemetry --timeout 60
#  This fails with "Warning: Must use a destination node ID."
meshtastic --tcp 192.168.1.203 --get power --timeout 60
#  This works, but it doesn't include the current battery voltage.

I would like to turn off Bluetooth and WiFi on the remote nodes to save energy. The recommended method then is to launch admin commands over LoRa. In my setup, 192.168.1.200 and its public key is configured on each device as the admin key.

meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --info --timeout 60
#  This fails with:
#     Showing info of remote node is not supported.
#     Use the '--get' command for a specific configuration (e.g. 'lora') instead.
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --get power --timeout 60
# This fails consistently, even with an extended timeout
#    Requesting current config from remote node (this can take a while).
#    Aborting due to: Timed out waiting for an acknowledgment
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60
# This fails consistently, even with an extended timeout
#    Sending device_metrics telemetry request to !b03d60c0 on channelIndex:0 (this could take a while)
#    Aborting due to: Timed out waiting for telemetry
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --ch-index 1 --request-telemetry --timeout 60
# This fails consistently, even with an extended timeout
#    Sending device_metrics telemetry request to !b03d60c0 on channelIndex:1 (this could take a while)
#    Aborting due to: Timed out waiting for telemetry

Gemini recommends another method. It seems it's a hallucination. I don't know where it came up with the idea, but it's not a bad one.

meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --get power.battery_voltage
# This fails because power.battery_voltage doesn't exist.

In short, none of the recommended documented methods to query battery voltage from a remote node work. Please implement an admin method to query battery voltage or fix a documented method that consistently fails today.

I can provide a reproducible example (bash) to deploy on two Heltec devices, but it will it won't be so minimal.

[tylerpieper]

This might be more firmware related. I think router-type roles don't respond to device_metrics requests. I have admin on one and it only emits those stats on its schedule.

[roberthadow]

Hello @tylerpieper --

You are correct. The failure may well be in the device firmware. Nevertheless, the problem presents itself when one tries to exercise CLI commands in accord with the Python CLI documentation. Battery voltage displays fine when using the Android app. Battery voltage displays fine when using the web app (client.meshtastic.org). So we know that the device firmware measures and reports battery voltage. It just won't do so when using the CLI interface using --dest, implying admin mode.

I only have one Heltec node whose private key is distributed as the admin key. To launch messages from it, it has to be within WiFi range of my home network. Normally it is plugged in anyway. I don't care about the device m,etrics from this device, only the remote nodes.

[tylerpieper]

Not all commands that are valid CLI work with the --dest flag over remote admin. The documentation probably just needs to be cleaned up to clarify what does and doesn't work remotely.

…

On Fri, Jul 3, 2026, 11:06 Robert Hadow ***@***.***> wrote: *roberthadow* left a comment (meshtastic/python#947) <#947 (comment)> Hello @tylerpieper <https://github.com/tylerpieper> -- You are correct. The failure may well be in the device firmware. Nevertheless, the problem presents itself when one tries to exercise CLI commands in accord with the Python CLI documentation. Battery voltage displays fine when using the Android app. Battery voltage displays fine when using the web app (client.meshtastic.org). So we know that the device firmware measures and reports battery voltage. It just won't do so when using the CLI interface using *--dest*, implying admin mode. I only have one Heltec node whose private key is distributed as the admin key. To launch messages from it, it has to be within WiFi range of my home network. Normally it is plugged in anyway. I don't care about the device m,etrics from this device, only the remote nodes. — Reply to this email directly, view it on GitHub <#947?email_source=notifications&email_token=ANA3X3I6QJUUVWV5M5UUZVT5C7YYXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBXHA2TCMBZGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4878510920>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ANA3X3MJ4PSJOEUHO6XUYTD5C7YYXAVCNFSNUABFKJSXA33TNF2G64TZHMZDKOJRHAZDKMJUHNEXG43VMU5TIOBQGUZDKNJZHEZ2C5QC> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/ANA3X3PIJOCNQPSR66RPLUT5C7YYXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBXHA2TCMBZGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android <https://github.com/notifications/mobile/android/ANA3X3P3SUG7UQARFX4XZFL5C7YYXA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOBXHA2TCMBZGIYKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you were mentioned.Message ID: ***@***.***>

[roberthadow]

Hello @tylerpieper --

I observe several types of failures while using CLI.

(1) A command that works over a direct connection throws a not-allowed exception when routed over LoRa. Example:

meshtastic --tcp 192.168.1.203 --info --timeout 60 ## works
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --info --timeout 60 ## fails. not alowed with --dest

(2) A command that seems to work reliably as a single line in the terminal fails in a bash script. Here are fourteen commands that are generally reliable. When executied serially, a number fail.

meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --sendtext "Hello from BB38" --ack --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0'  --set bluetooth.fixedPin 121212 --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --sendtext "Hello from BB38" --ack --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --sendtext "Hello from BB38" --ack --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --sendtext "Hello from BB38" --ack --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --get bluetooth.fixedPin  --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --set bluetooth.fixedPin 131313 --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --get bluetooth.fixedPin  --timeout 60 
meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --request-telemetry --timeout 60 

From fourteen commands, I got six exceptions. Power is not a problem on either device. They are both powered by USB.

Connected to radio
Sending device_metrics telemetry request to !b03d60c0 on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 90.00%
Voltage: 4.06 V
Total channel utilization: 6.36%
Transmit air utilization: 0.06%
Uptime: 62 s
Connected to radio
Sending text message Hello from BB38 to !b03d60c0 on channelIndex:0 
Waiting for an acknowledgment from remote node (this could take a while)
Received an ACK.
Connected to radio
Requesting current config from remote node (this can take a while).

bluetooth:
enabled: true
mode: FIXED_PIN
fixed_pin: 131313

Set bluetooth.fixed_pin to 121212
Writing modified preferences to device
Writing bluetooth configuration to device
Waiting for an acknowledgment from remote node (this could take a while)
Received a NAK, error reason: ADMIN_BAD_SESSION_KEY
Connected to radio
Sending device_metrics telemetry request to !b03d60c0 on channelIndex:0 (this could take a while)
Aborting due to: Timed out waiting for telemetry
Connected to radio
Sending text message Hello from BB38 to !b03d60c0 on channelIndex:0 
Waiting for an acknowledgment from remote node (this could take a while)
Received an ACK.
Connected to radio
Sending device_metrics telemetry request to !b03d60c0 on channelIndex:0 (this could take a while)
Aborting due to: Timed out waiting for telemetry
Connected to radio
Sending text message Hello from BB38 to !b03d60c0 on channelIndex:0 
Waiting for an acknowledgment from remote node (this could take a while)
Received an ACK.
ERROR file:stream_interface.py __reader line:240 Unexpected OSError, terminating meshtastic reader... [Errno 104] Connection reset by peer
Error connecting to 192.168.1.200:Timed out waiting for connection completion
Connected to radio
Sending text message Hello from BB38 to !b03d60c0 on channelIndex:0 
Waiting for an acknowledgment from remote node (this could take a while)
Received an ACK.
Connected to radio
Sending device_metrics telemetry request to !b03d60c0 on channelIndex:0 (this could take a while)
Aborting due to: Timed out waiting for telemetry
Connected to radio
Requesting current config from remote node (this can take a while).

bluetooth:
enabled: true
mode: FIXED_PIN
fixed_pin: 121212

Completed getting preferences
Connected to radio
Requesting current config from remote node (this can take a while).

bluetooth:
enabled: true
mode: FIXED_PIN
fixed_pin: 121212

Set bluetooth.fixed_pin to 131313
Writing modified preferences to device
Writing bluetooth configuration to device
Waiting for an acknowledgment from remote node (this could take a while)
Received a NAK, error reason: ADMIN_BAD_SESSION_KEY
Connected to radio
Requesting current config from remote node (this can take a while).

bluetooth:
enabled: true
mode: FIXED_PIN
fixed_pin: 131313

Completed getting preferences
Connected to radio
Sending device_metrics telemetry request to !b03d60c0 on channelIndex:0 (this could take a while)
Telemetry received:
Battery level: 76.00%
Voltage: 3.95 V
Total channel utilization: 11.20%
Transmit air utilization: 0.09%
Uptime: 2 s

I ran the same sequence of commands again. The second time I got four exceptions.

I ran the same sequence of commands again. The third time I got six exceptions.

I ran the same sequence of commands again. The fourth time I got only two exceptions.

I ran the same sequence of commands again. The fifth time I got seven exceptions including "Error connecting to 192.168.1.200:[Errno 113] No route to host" at the get-go. Nevertheless, half of the the rest worked.

(3) An admin command that successfully changes a configuration element on the node, but the acknowledgement fails on the PC. Examples:

meshtastic --tcp 192.168.1.200 --dest '!b03d60c0' --set bluetooth.fixedPin 131313 --timeout 60 
# Received a NAK, error reason: MAX_RETRANSMIT
# Received a NAK, error reason: ADMIN_BAD_SESSION_KEY

That an exeption is thrown after the configuration change is successfully made on the device leads me to believe the flawed code is not in the firmware, but in the Python CLI code on the PC.

[roberthadow]

The software conforms substantially to the documentation.

In the old days, in a commercial environment, the common provision for software warranty was written like this: "The Software will operate substantially in accord with the Documentation." Software was defined. In the dinosaur days, Documentation might have been defined as the man page, the output of the help argument, or the written documentation.

Meshtastic offers no warranty, so update of the documentation, including help and the web pages that describe it, often fall out of sync.
That's understandable. It's a lot more fun to build a new feature than do regression testing that ensures that operation of changed code matches the docs.

The documentation implies a lot of functionality that v2.7.26 does not deliver. The most general of these is described in the output of the --get 0 arguments. It describes generally that --get FIELD should return the value of value of any configuration VALUE.
Similalry, --set FIELD VALUE is the setter method for any configuration element as long as the VALUE is an allowable value.

--get FIELD and --set FIELD VALUE are not universal. As a simple example, -- set owner OWNER doesn't work. It requires an alternate formulation: -- set-owner OWNER. There is no eqvivalent command --get-owner. To achieve the same end one would have to --info, then grep the result.

For the sake of consistency, every configuration element should be accessible by --get FIELD and --set FIELD VALUE. This capability needs to be tempered by security concerns, I understand.

From the CLI interface, there are multiple routes to any device. The first family is direct: by USB, TCP, or Bluetooth.
The second family is through an admin node, then over LoRa to the node of interest. The documentation implies that every command
that can be executed by direct connection should be executable as an admin command, i.e. using --dest DESTID. Today, this is not the case.

Insofar as an admin command requires the security provided by the admin key, there is no security concern that should limit the execution of commands over LoRa. There are plenty of bandwidth concerns however. In the same way that --traceroute expends a lot of LoRa resource, so should requests for a nodes list be throttled.

As a general matter, I suggest that any command executuable over a direct connection be allowed over LoRa as an admin command.
Then, after we've proven they all work, trim the list of resource-wasting activities and changes that have a negative security implication.