Add device name suffix with BLE address for counter identification - #16
Merged
Merged
Conversation
Every counter advertised the identical local name "BeeCounter", so an apiary with several in range produced a scan list of identical rows: picking the right one for pairing, or working out which of three on a bench is being flashed, meant opening a scanner's detail view and reading addresses. The advertised name is now built at boot as "HiveTraffic-AB:12", where the suffix is the last two bytes of the counter's own BLE address rendered the way a scanner prints them. NimBLE settles its own-address type before init() returns and both the reported address and the advertised packets follow it, so the suffix is literally the tail of the address shown beside the entry. On the ESP32-C6 that address is the factory eFuse MAC: unique per unit and stable across reboots, reflashes and OTA updates, with nothing to provision per device. The same string is pushed to the GAP Device Name characteristic, so a client that connects and reads it agrees with the scan list. The base name changes from "BeeCounter" to the product's own name in the same move; the former was a leftover from the easy-bee-counter days. Nothing on the wire keys off either: HiveHub connects by the MAC paired in its portal and never matches on the name, the measurement document is untouched, and the protocol revision does not move. The service UUID and the beecounter_proto namespace keep their names, being wire identifiers rather than display text. The string itself lives in a new Arduino-free include/device_name.h, pinned by test/test_device_name/ on a host compiler, because every way of getting it wrong is quiet: a reversed suffix, a dropped leading zero or a truncation all produce a name that still looks like a name while pointing at the wrong device, and noticing on hardware requires already knowing the address you were looking for. The header static_asserts its longest form against the 31-byte legacy scan response, which the name now fills 19 of. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VXfRikN5G4jyYqkSLeo9nf
The name builder used a `static const char HEX[]` lookup table, and Print.h defines `HEX` as 16. Every host check passed and the firmware build failed with "expected unqualified-id before numeric constant" — the same collision class this repo already hit once, where an enumerator named DISABLED met esp32-hal-gpio.h's `#define DISABLED 0x00`. The table is now `hex_digits`. Lower case is the actual fix: Arduino's macros are all-caps, so a lower-case identifier cannot collide with one no matter which of its few hundred macros a future header pulls in. test/test_device_name/ grows the macro block test_idle_state.cpp already carries, extended with the number-base macros (DEC/HEX/OCT/BIN) that are the ones to bite a header doing string formatting. With them defined ahead of the include, this exact failure now surfaces on a host compiler in under a second instead of two and a half minutes into a firmware build. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01VXfRikN5G4jyYqkSLeo9nf
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Counters now advertise as
HiveTraffic-AB:12instead ofBeeCounter, where the suffix is the last two bytes of the counter's own BLE address. This makes multiple counters in range distinguishable in a scan list without requiring users to open detail views to match physical devices to scan entries.Key Changes
New header
include/device_name.h: Pure C++ header that builds the advertised BLE name by appending the last two bytes of the device's address (in NimBLE little-endian format) to the product name. Includes comprehensive documentation on byte order, address selection, and failure modes.Comprehensive test suite
test/test_device_name/test_device_name.cpp: 8 test cases covering byte order correctness, leading zero preservation, uppercase hex rendering, all 65536 possible suffix values, fallback behavior when no address is available, buffer overflow protection, capacity validation, and uniqueness across devices.Updated
src/ble_link.cpp:BLE_DEVICE_NAMEwith dynamicdeviceNamebuffer built from the controller's addressbuildDeviceName()function that runs afterNimBLEDevice::init()to construct the suffixed nameHiveTrafficif address cannot be readDocumentation updates:
docs/ble-mode.md: Explains the new naming scheme, address suffix format, and how it survives reboots/updatesFirmware/README.md: Documents the test coverage and design rationaleREADME.md: Updated user-facing description of BLE advertisementTest infrastructure: Updated
test/run_tests.shto build and run the new device_name testsVersion bump: 0.3.0 → 0.3.1
Implementation Details
https://claude.ai/code/session_01VXfRikN5G4jyYqkSLeo9nf