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
0f7e47e55e