[discostur]

Closes the last README item, "also decode encrypted data".

[[sensor]]
mac = "A4:C1:38:00:11:22"
bindkey = "231d39c1d7cc1ab1aee224cd096db932"

The advertisement is decrypted before the object parser sees it, so everything downstream — output, --exec, Prometheus — works unchanged.

Both formats use AES-128-CCM with a 4-byte MIC, but they differ in ways that are easy to get wrong:

	nonce	associated data
BTHome v2	MAC ‖ D2 FC ‖ device-info byte ‖ 4-byte counter	none
MiBeacon	MAC reversed ‖ product id ‖ frame counter ‖ 3-byte counter	0x11

Note the MAC goes in one way round for BTHome and the other way round for MiBeacon. Both constructions follow the reference implementations, cited in the module docs: bthome-ble and xiaomi-ble.

Without a key an encrypted advertisement is still skipped rather than parsed — that behaviour arrived with the two decoder fixes earlier in the stack. A wrong key fails the MIC check and is reported. Worth stating plainly: a mistake in the nonce layout cannot produce plausible-but-wrong measurements, because the MIC would not match. It shows up as "could not decrypt".

Dependencies: aes and ccm from RustCrypto. Both pure Rust with no C to cross compile, which matters for the musl targets.

⚠️ I have no encrypted sensor to hand, so this is not confirmed against a real device. What the ten tests do check is a full round trip: they build a complete encrypted advertisement and then decrypt it, so encryption and decryption derive the nonce independently from the finished packet and a layout mistake fails the test. Three go through handle_service_data() end to end and assert the measurements that come out; others check that a wrong key and a MAC from a different device are both rejected. Still worth a run against a real encrypted sensor before trusting it — that is partly why this one is last and a draft.

Threading the MAC and key into the decoders needed a parameter, so handle_service_data() now takes a DecodeOptions. It implements Default ("no MAC, no key", the unencrypted case), so the change at existing call sites is mechanical.

---

I went through the README TODO list and found a few real bugs on the way, so this
is one of ten PRs. They are meant to be reviewed and merged in this order, and
each is a separate branch so you can take some and leave others:

1. chore/ci-deps-and-metadata — CI, unused deps, lockfile
2. test/decoder-assertions — make the decoder tests actually assert
3. fix/bthome-object-lengths — BTHome parser desync + encryption flag
4. fix/mibeacon-frame-control — MiBeacon hardcoded offset + encryption flag
5. fix/continuous-scan — one reading per sensor ever, and the watchdog loop
6. feat/logging-and-output (draft) — log levels, --format json
7. feat/config-file (draft) — name, calibrate and filter sensors
8. feat/exec-hook (draft) — --exec
9. feat/prometheus (draft) — --metrics-addr and --pushgateway-url
10. feat/encrypted-payloads (draft) — AES-CCM bind keys

6–10 are drafts because they build on each other; GitHub can only point a
cross-fork PR at main, so until the ones before it are merged each diff also
shows its ancestors. I will rebase and force-push as things merge, so each
shrinks to its own change. Nothing here is urgent — take them at whatever pace
suits, or tell me to close some.

Everything is checked with cargo fmt --check, cargo clippy -D warnings and
cargo test in a rust:1.96 container, since bluer's bluetoothd feature is
Linux-only and I develop on a Mac.