dustcouncil/bandsaunter
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Show a sensor's identity in both bases, and take either

Browse source 
Reported as bandsaunter using "completely different" identities from a script
that had been watching the same sensors for years.  They are the same
identities.  Their list against this program's:

    14645 = 3935      8677 = 21E5      14717 = 397D
    3542  = 0DD6      10011 = 271B

Five of their eight, matching exactly; the other three simply were not
transmitting during the three seconds of capture I had.  One base is
hexadecimal and the other decimal, and nothing anywhere said so.

The hexadecimal is not arbitrary -- the identity is a bit field with the
channel packed into the top two bits, and that shape is visible in hex and
invisible in decimal, which is why the decoder carries it that way.  But
rtl_433 and everything built on it prints these in decimal, so anybody who
comes to this with their own sensors already written down has the other form,
and being handed a list that looks unrelated to theirs is a poor welcome.

So both are shown wherever a person reads: the live display when there is room
for the column, the report, the sensor list and the spreadsheet.  `bandsaunter
sensors` is the table for correlating two lists and now has them side by side,
with a line saying which is which and why.

Either may be typed at --name.  One case needs care rather than cleverness:
"3935" is a valid identity in both bases and they are different sensors, so
when both are out there it says the identity is ambiguous and asks for the
whole key instead of picking whichever the code reaches first.

A first attempt at the lookup converted a decimal identity to hexadecimal and
matched on that as well as comparing decimals directly.  Both worked, so
neither could be tested apart from the other; the conversion was removed
rather than given a test written backwards from it.

Full suite 2391 passed, checked against five deliberately broken builds.
Built as 2026-09-20_01.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_016PsWPTweCT6pwxKngvVxcg
This commit is contained in:
The Dust Council 2026-09-20 14:47:08 -07:00
parent 03d3600ecc
commit 0f7e47e55e
10 changed files with 246 additions and 15 deletions
Download patch file Download diff file Expand all files Collapse all files

11
packaging/make-man.py
View file

@ -1329,6 +1329,17 @@ of a hat in a factory \[em] or a different number out of the same hat the next
time the batteries were changed. It tells one sensor from another and is no
use at all for telling which is which.
.PP
It is shown in both bases. These identities are bit fields with the channel
packed above them, so this prints them in hexadecimal where that shape shows,
while rtl_433 and everything built on it prints them in decimal: 3935 and
14645 are the same sensor. Anyone arriving with a list of their own already
has it in decimal, so
.B bandsaunter sensors
puts the two side by side and either may be typed at
.BR \-\-name .
An identity that is a valid number in both bases is reported as ambiguous
rather than resolved by guesswork.
.PP
So press
.B n
while listening. The display comes down, the sensors are listed with numbers,