Skip to content

Retail beacons: Target and Acuity/Atrius

Reviewed 2026-10-02, against source commit 640f13ec1215cce486987e60d279f27c16774cdb. This research supports roadmap item 10. It adds no detection rules: the reviewed baseline was 67 rules / 19 categories. No ATG2 or Target-store radio capture has been collected or validated for this project.

Decision

Acuity/Atrius is a useful passive BLE research candidate, but a production asset-tag alert is not ready. Public sources establish the hardware family, its purpose and a registered company identifier. They do not establish the normal advertisement layout, a Target-specific identifier or a validated discriminator between an asset tag and other Acuity equipment.

The next coding task should be a bounded, opt-in research capture facility using existing hardware. Keep prospective rules out of the production catalog until labeled positive and negative captures establish a matcher. No new hardware purchase is justified by this research alone.

What the evidence establishes

Evidence Established fact Limit
Target privacy policy, updated August 15, 2026 [T1] Describes in-store location using Bluetooth and LED-light technologies, and cameras for traffic analysis Does not enumerate each store's hardware or its on-air identifiers
Acuity announcement, March 10, 2020 [A1] Documents a renewed Target agreement for Atrius services and connected lighting supporting indoor location Historical supplier evidence; not proof of current nationwide deployment of any particular tag
Acuity ATG2 manufacturer manual, filed May 18, 2020 [F1] Battery-powered BLE beacon for Atrius Assets, with no end-user interface Does not disclose advertisement bytes, an advertised name, service UUID or a Target-only variant
ATG2 regulatory test report ISL-20LR097FC, printed pp.6 and 10 [F2] Identifies product revision 2, Bluetooth 4.2, GFSK and 2402–2480 MHz operation; laboratory tests use controlled transmit modes RF compliance tests are not normal-operation packet captures. Firmware identification is listed as unavailable
Atrius Assets architecture/specification, revision November 12, 2018 [A2] Describes BLE tags, proprietary protocols, receiving luminaires, gateways and cloud processing An architecture diagram does not provide a decoder or identify the installation in a particular store
Bluetooth SIG Assigned Numbers, September 23, 2026, printed pp.241 and 334 [B1] Assigns company ID 0x0346 to Acuity Brands Lighting, Inc A company assignment does not prove ATG2 uses that ID in its advertisements

Source access: the ATG2 manual and test-report PDFs were retrieved in full from a filing mirror. The manufacturer-hosted Atrius Assets PDF returned HTTP 403 on direct retrieval; its indexed text was available, so its architecture is corroborating evidence rather than a packet specification. No public advertisement-format document or validated capture was established in the reviewed manufacturer pages, filing exhibits and protocol searches. The ATG2 filing index lists the operational description, schematics and block diagram as metadata-only exhibits [F3]; do not treat inaccessible content as reviewed.

The manual download has SHA-256 801151470573f3a1e0549030cd4ab46435e3a03e34166f1f1e47fd378069fb46. The test-report download has SHA-256 aad86270c4a414ffe2718ad494521ff26355dd68329b5a75a68a66b26fcb9d2b. These identify research documents, not radio fixtures. Neither PDF is bundled with Hound.

Separate the device roles

Role Potential Hound observation Interpretation
Asset tag attached to an item Its BLE advertisements, if compatible with the current receiver An asset-location transmitter; not automatically a personal tracker
Lighting-integrated beacon Its own advertisements, if emitted and recognizable Indoor-location or building infrastructure
Luminaire acting only as a receiver No required identifiable advertisement Hound cannot infer a silent listener's presence
Gateway A supported identifying broadcast, if one exists No known universal Atrius Wi-Fi name was established
Optical positioning or cameras No direct observation through the BLE/Wi-Fi receivers A radio clue cannot reveal optical sensing or camera analytics

An architectural inference: a tagged cart can be located independently of a shopper's phone. Switching off the phone does not switch off the cart's tag. Linking a cart route to a named shopper is a separate backend operation that Hound cannot establish. The reviewed primary sources do not prove that a given Target basket carries an ATG2, or that a particular store is collecting an identified shopper's route.

Candidate fields, not enabled signatures

Company identifier

The Bluetooth manufacturer-specific AD structure uses type 0xFF and starts its data with a company identifier [B2]. If a received structure carries Acuity's registered ID in the representation expected by Hound, the illustrative form is:

AD length | FF | 46 03 | vendor-defined bytes, if present

This is an illustration of field placement, not a captured ATG2 packet. Validate the AD length and the enclosing advertisement before interpreting bytes. The ID belongs at the start of manufacturer data; do not search the whole packet for 46 03. It is not a MAC prefix, service UUID or proof of vendor authenticity.

The existing Kind::Company matcher interprets the first two manufacturer bytes as little-endian; a future company matcher would use the value string 0346. A literal manufacturer-payload prefix would begin 4603. Neither form is approved as an asset-tag rule. An Acuity device may omit manufacturer data, use another protocol identifier, or share an identifier with unrelated Acuity products. Seeing the ID warrants at most an informational “Acuity-associated broadcast” clue until the device role is established.

Names, services and structure

  • ATG2, Atrius, Target: no default advertised name was established. Model/brand names printed in documents are not BLE local names.
  • iBeacon: Hound already recognizes the generic format. No public Target-specific proximity UUID or ATG2 iBeacon layout was verified. Do not change the generic iBeacon label to a retailer name.
  • Service UUIDs: no ATG2-specific advertised service was established. A service available only after connecting would not satisfy passive discovery.
  • Subtype/version/length: unknown for normal ATG2 manufacturer or service data. These are the likely prerequisites for a useful product discriminator after captures.
  • Timing, RSSI and addresses: useful context for comparing observations, but insufficient for model attribution, distance measurement or joining rotating identities.

Fit with the current receiver

The code review found the following constraints:

Source Current behavior Research consequence
components/radio/radio.cpp Passive NimBLE discovery; rejects data over 31 bytes; alternates BLE and Wi-Fi windows Establish that useful identifying data is in legacy advertisements. Scan-response-only names, connected traffic and extended advertising are not a supported fallback
components/sniffer_core/parsers.cpp Bounded AD parsing; retains one manufacturer block and one 16-bit service-data block; rejects duplicate blocks of those types Record raw AD structure before assuming the current parsed observation is complete; include duplicate/malformed structures in later tests
components/sniffer_core/engine.cpp Company/prefix/protocol matchers already exist; generic iBeacon detection is separate Vendor matching is small, but a product-specific parser depends on evidence
Settings, game and collection paths There are 19 persisted categories and independent alert, feeding and discovery paths A low score alone is not a complete informational policy; prevent incidental rewards and Travel Watch enrollment explicitly

Normal detection history and its exports are not a substitute for raw advertisement fixtures. A useful capture facility must be designed and tested; none is added by this document. Keep passive operation intact rather than enabling active scans to obtain additional fields. A phone-scanner result that combines advertisements and scan responses cannot by itself prove Hound will receive the same fields.

Capture plan using existing hardware

Start with the existing ESP32 receiver or spare ESP32-C3. Confirm the software records passive legacy advertisements before attributing a missing field to a device. A new receiver or analyzer is a later option only if a specific missing capability is demonstrated.

  1. Create ground truth. Record a visible model/FCC label where available, device role, test state and firmware if known. Do not turn an ambient strong signal into a labeled ATG2 sample. A controlled owned or authorized unit provides stronger attribution than co-location in a store.
  2. Bound each session. Proposed starting limits: two minutes, 64 distinct advertiser slots and 512 samples, all configurable only in a research build. Track dropped observations and complete BLE listening time. These are engineering proposals, not measured requirements.
  3. Record the necessary fields. Monotonic time, RSSI, address type, a session-local pseudonym, advertisement event type when available, AD length, and exact AD bytes for selected candidates. Start with the Acuity company-ID filter, but report clearly that it can miss devices using other identifiers. A short explicitly enabled broader discovery sample may be needed to investigate that gap.
  4. Collect positives and controls. Compare at least two independently identified tags, repeated sessions, stationary/moving states and receiving infrastructure nearby/absent where practical. Include non-tag Acuity lighting/control devices, other-brand beacons and a busy retail environment. “No match” during a short scan is not evidence that the equipment is absent.
  5. Separate identity from format. Determine which bytes are constant, counters, telemetry, identifiers or unknown. Test unrelated units before assigning any field a model meaning. Do not assume address rotation cadence or merge by RSSI.
  6. Publish synthetic fixtures. Keep raw captures private and short-lived; minimize bystander data. Session pseudonyms do not anonymize identifiers embedded in AD bytes. Review those fields before sharing, and construct independent synthetic positive/negative fixtures under the existing fixture policy.

Capture output must use bounded queues and deferred writes, with explicit start/stop and visible dropped-sample counts. Check heap, radio loss, SD backlog and UI responsiveness. Never stream verbose serial output from the radio callback or silently store raw packets during ordinary use.

Coding order and acceptance gates

Order Proposed work Gate before proceeding
1 Research capture/inspection mode Legacy passive reception verified; bounded storage and explicit privacy controls
2 Optional vendor-only inventory clue Labeled capture confirms the field; separate informational behavior, quiet by default
3 Atrius asset-tag discriminator Stable structural evidence from independently identified units and non-tag Acuity controls
4 Lighting-beacon discriminator Separate capture evidence for transmitter role and operating state

Suggested eventual labels are “Acuity-associated broadcast”, “Possible retail asset beacon”, or “Atrius asset beacon” only at the corresponding evidence level. These are proposed labels, not current detections. Do not claim retailer ownership, shopper identification, active analytics or malicious following from a broadcast.

Before enabling a rule, cover malformed/truncated ADs, swapped identifier bytes, the ID appearing at the wrong offset, unknown versions, unsupported lengths, unrelated devices sharing the vendor, and iBeacon/asset-rule overlap. Repeated packets must not inflate confidence or device counts. Synthetic samples that mimic the exact bytes must retain the same unauthenticated-evidence limitation.

Retail inventory should be quiet by default, with an explicit opt-in for notifications. Preserve Ignore/Snooze and scan controls, and define log/discovery behavior separately. Exclude retail asset and fixed-location beacons from Travel Watch by default: a cart accompanying a shopper inside a store is expected behavior. No meals, XP, outfit unlocks, screen wake, sound or vibration should result from informational clues alone. Design any category/state migration before implementation; do not reuse AirTag, Samsung or iBeacon categories merely for their existing animations.

Sources

All sources were checked on October 2, 2026. A filing mirror hosts the manufacturer's/laboratory's primary documents; the mirror's summaries are not a packet specification.

The later October 3 signature expansion enables informational Eddystone/Estimote/Kontakt clues. The separate Target-associated iBeacon candidate stays disabled pending independent captures; this research does not validate that UUID or establish active customer tracking.