You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To specify a node, we currently use an exclamation mark, which has other effects in bash. It would be ideal to also allow nodes to be specified by their numeric value, as well as by 0xdeadbeef as well as !deadbeef.
I'll keep this open for the time being, because I think we'd still like to add some handling for passing node IDs in pure decimal at the command line. I think we can add some handling that treats a value as decimal if it has no prefix at all and all digits could be decimal. I'm not sure entirely what we should do with an unprefixed 8-digit all-decimal-digits value, though.
[...] I'm not sure entirely what we should do with an unprefixed 8-digit all-decimal-digits value, though.
There will be no choice: the prefix will initiate the interpretation of the following string as defined by the prefix. No prefix then is just a shortcut to interpret as a decimal number, otherwise there is an ambiguity which cannot be resolved. Having a clear rule will also keep the code clean and understandable.
While implementing this I noticed two things about the current hex branch in _sendPacket() (isinstance(destinationId, str) and len(destinationId) >= 8 → int(destinationId[-8:], 16)):
digits-only input like --dest 12345678 currently parses as 0x12345678 (=305419896) — under the rule above it would become decimal instead, so I'd flag that as an intentional change in the PR/docs.
any non-hex string of 8+ chars (e.g. a long node name) raises a raw ValueError before the NodeDB lookup can run — my branch turns that into the same friendly "not found in DB" exit the rest of the path uses.
On juergenRe's ambiguity point: I checked and destination strings are never resolved against node names today (self.nodes is keyed by !hex user ids), so there's no name-collision surface. Digit strings shorter than 8 characters currently just error out ("not found in DB"), so decimal support adds a capability; longer ones are the intentional behaviour change flagged in point 1.
I have a working branch with tests covering all input classes (prefixed/bare hex, decimals incl. range limits, unicode digit lookalikes, overlong inputs) verified against a real node, and will open a PR here as soon as you're happy with the direction.
Activity
dl33t-me commentedon Jan 21, 2025
Would this need to be changed in the firmware or just in the pattern matching from the command line?
ianmcorvidae commentedon Jan 21, 2025
this should only need updating within the CLI/library -- everything is converted to an integer to send to the radio
migillett commentedon Jan 26, 2025
Made a PR to potentially address this issue.
#731
I'm open to comments on improving this though.
migillett commentedon Feb 19, 2025
PR just merged to main. You can now use
!or0xprefixes when setting node destinations. ie:--dest "0x12345678"or--dest "!12345678"ianmcorvidae commentedon Feb 19, 2025
I'll keep this open for the time being, because I think we'd still like to add some handling for passing node IDs in pure decimal at the command line. I think we can add some handling that treats a value as decimal if it has no prefix at all and all digits could be decimal. I'm not sure entirely what we should do with an unprefixed 8-digit all-decimal-digits value, though.
juergenRe commentedon Oct 26, 2025
There will be no choice: the prefix will initiate the interpretation of the following string as defined by the prefix. No prefix then is just a shortcut to interpret as a decimal number, otherwise there is an ambiguity which cannot be resolved. Having a clear rule will also keep the code clean and understandable.
RuffR1d3r commentedon Aug 24, 2026
Happy to pick up the remaining piece of this — pure-decimal node IDs at the CLI.
From the thread so far, the consensus rule would be:
!deadbeef/0xdeadbeef→ hex node id (already works since 464: allow for 0x node prefix values #731)While implementing this I noticed two things about the current hex branch in
_sendPacket()(isinstance(destinationId, str) and len(destinationId) >= 8→int(destinationId[-8:], 16)):--dest 12345678currently parses as0x12345678(=305419896) — under the rule above it would become decimal instead, so I'd flag that as an intentional change in the PR/docs.ValueErrorbefore the NodeDB lookup can run — my branch turns that into the same friendly "not found in DB" exit the rest of the path uses.On juergenRe's ambiguity point: I checked and destination strings are never resolved against node names today (
self.nodesis keyed by!hexuser ids), so there's no name-collision surface. Digit strings shorter than 8 characters currently just error out ("not found in DB"), so decimal support adds a capability; longer ones are the intentional behaviour change flagged in point 1.I have a working branch with tests covering all input classes (prefixed/bare hex, decimals incl. range limits, unicode digit lookalikes, overlong inputs) verified against a real node, and will open a PR here as soon as you're happy with the direction.
fix: support purely decimal node IDs for --dest (issue meshtastic#464)