Repository navigation
Accept node.id in decimal and hex #464
Description
Activity
- addedgood first issueGood for newcomersGood for newcomershelp wantedExtra attention is neededExtra attention is needed
on Mar 16, 2024 Would this need to be changed in the firmware or just in the pattern matching from the command line?
this should only need updating within the CLI/library -- everything is converted to an integer to send to the radio
Made a PR to potentially address this issue.
#731I'm open to comments on improving this though.
PR just merged to main. You can now use
!or0xprefixes when setting node destinations. ie:--dest "0x12345678"or--dest "!12345678"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.
Reacted by Michael Gillett[...] 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.
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)- digits-only, no prefix → decimal node number
- anything else → unchanged behaviour
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 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. - any non-hex string of 8+ chars (e.g. a long node name) raises a raw
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.
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.