Find Hub Locator Ringing: Turn Sound Commands into a Verifiable OEM Test Plan | Find Hub 定位器响铃：把声音指令转化为可验证的 OEM 测试计划

ENGLISH ARTICLE

Find Hub Locator Ringing: Turn Sound Commands into a Verifiable OEM Test Plan

A locator that can be requested to ring needs more than a sound sample. Separate command handling, ringing-state feedback, connection loss, user stop controls and acoustic evidence before turning a Find Hub-oriented concept into an OEM product requirement.

1. Treat ringing as a state machine, not a sound clip

Google's Find Hub Network accessory specification describes ringing as a request with components, timing and a returned state. That is a useful product-planning distinction: the requirement is not simply that a buzzer makes noise, but that the product handles a command, enters an observable state and terminates in an explainable way. The specification uses a 0x05 data ID for ringing notifications and defines states such as Started, stopped by timeout, stopped by button press and stopped by a GATT request. [1]

For an OEM brief, draw the expected transitions before selecting a sounder. Define what happens when ringing starts, when it is already active, when a stop request arrives and when the requested component is out of range. A tone that sounds once during a bench demo is not evidence that the complete command path is reliable.

2. Separate command delivery from ringing feedback

The same specification provides a way to query a beacon's ringing state using data ID 0x06. The returned data identifies the actively ringing components and the remaining time in deciseconds; when the device is not ringing, the remaining time should be 0x0000. This creates a testable feedback path rather than leaving the owner to infer state from a delayed sound or a changing screen. [1]

A validation record should therefore capture at least the request time, the requested component, the returned state, the reported remaining time and the physical sound observation. If the command is received but the sounder is silent, the failure should identify whether the issue is authentication, range, firmware state, power, transducer drive or the acoustic path. Do not collapse all of these into a single pass/fail label.

3. Test connection loss and physical stop controls

Google's guidance says the Provider should continue ringing regardless of the connection status of the Seeker that requested ringing. The reason is practical: if a client moves away and the connection drops, stopping immediately can make the item harder to find. A project test should intentionally move the requesting phone out of range and record whether the locator follows the documented ringing and timeout behaviour. [1]

The same guidance says that, where a physical button or enabled touch sensing exists, pressing it should stop active ringing. Test this control under the actual enclosure, button force and user-access conditions. Also distinguish stopping the sound from stopping advertising: the locator-tag guidance separately requires a mechanism to temporarily stop advertising without a factory reset. These are different user and privacy functions. [2]

4. Build acoustic evidence without overclaiming

The published Find Hub accessory material includes acoustic and anti-unwanted-tracking guidance, including a sounder requirement and a peak loudness reference under the DULT specification. Treat that as a platform-related requirement to be checked against the applicable implementation and test method, not as permission to advertise one universal loudness result for every enclosure. [2]

For internal validation, document the sounder part, drive waveform, enclosure, battery condition, measurement equipment, position, environment and software or firmware build. Repeat measurements across representative units and record failed units. A maximum reading from one open prototype cannot replace an auditable test method for the finished enclosure.

5. Put the evidence into the OEM handoff

Stellarrisetech publicly describes ready-to-brand OEM trackers, custom ODM development and embedded tracking solutions. That product route is a practical context for aligning enclosure, firmware, sounder, controls, test fixtures and production records; it does not by itself prove that a particular model has completed Google validation or obtained certification. [3]

Before release, agree on the supported ecosystem, requested ringing components, timeout behaviour, connection-loss scenario, user stop method, advertising stop method and acoustic evidence package. Keep the same definitions in the product brief, firmware test report, packaging instructions and support replies. Clear evidence is more valuable than a broad claim that a locator will always ring or can always be found.

中文文章

Find Hub 定位器响铃：把声音指令转化为可验证的 OEM 测试计划

能够被请求响铃的定位器，不应只提供一段声音样本。将 Find Hub 相关方案转化为 OEM 产品需求前，应分别验证指令处理、响铃状态反馈、连接中断、用户停止控制和声学证据。

1. 把响铃看成状态机，而不是一段声音

Google 的 Find Hub 网络配件规范将响铃描述为包含组件、时间和返回状态的请求。这一思路对产品规划很有帮助：需求不只是蜂鸣器能够发声，还包括产品能处理指令、进入可观察状态，并以可解释的方式结束响铃。该规范使用 0x05 数据 ID 发送响铃状态通知，并定义了已开始、超时停止、按键停止和 GATT 请求停止等状态。[1]

对于 OEM 需求，应在选定发声器之前先画出预期状态转换。明确响铃开始、已经处于响铃状态、收到停止请求，以及请求的组件超出范围时分别应如何处理。台架演示中响一次，并不能证明完整的指令链路可靠。

2. 区分指令送达与响铃反馈

同一份规范还提供了通过 0x06 数据 ID查询信标响铃状态的方法。返回数据会标识正在响铃的组件，以及以十分之一秒为单位的剩余时间；设备不响铃时，剩余时间应返回 0x0000。这样就形成了可测试的反馈路径，而不是让用户根据延迟的声音或变化中的界面自行猜测状态。[1]

因此，验证记录至少应包含请求时间、请求的组件、返回状态、报告的剩余时间和实际听到的声音。如果指令已收到但发声器无声，应进一步区分认证、距离、固件状态、电源、换能器驱动或声学路径问题，不要把这些问题都压缩成一个简单的通过或失败标签。

3. 测试连接中断与实体停止控制

Google 的指引指出，无论发起响铃请求的 Seeker 连接状态如何，Provider 都应继续响铃。原因很实际：如果手机离开后连接中断，设备立即停止响铃，反而可能更难找回。项目测试应主动让发起请求的手机离开有效距离，并记录定位器是否按照规定的响铃和超时行为继续工作。[1]

同一指引还说明，如果产品配有实体按键或启用了触摸感应，响铃期间按下该控制应停止响铃。应在实际外壳、按键力度和用户可操作条件下测试这一控制。同时要区分停止声音与停止广播：定位器标签指引另行要求提供无需恢复出厂设置即可暂时停止广播的机制。这是不同的用户功能和隐私功能。[2]

4. 建立声学证据，但不要过度承诺

已公开的 Find Hub 配件资料包含与声学及防止不必要追踪相关的指引，其中包括发声器要求以及 DULT 规范下的峰值响度参考。应将其作为需要结合适用实现和测试方法核对的平台相关要求，而不是据此宣传所有外壳都能得到同一个通用响度结果。[2]

内部验证应记录发声器型号、驱动波形、外壳、电池状态、测量设备、摆放位置、环境以及软件或固件版本。应在有代表性的多个样品上重复测量并保留失败样品。开放式样机的一次最大读数，不能替代针对成品外壳的可审计测试方法。

5. 把证据写进 OEM 交接文件

Stellarrisetech 官网公开介绍了可定牌 OEM 防丢器、ODM 定制开发和嵌入式追踪方案。这一产品路线适合用于统一外壳、固件、发声器、控制方式、测试工装和生产记录；但这些服务介绍本身并不能证明某一型号已经完成 Google 验证或获得认证。[3]

产品放行前，应约定受支持的生态、请求响铃的组件、超时行为、连接中断场景、用户停止方式、停止广播方式，以及声学证据包。产品需求、固件测试报告、包装说明和客服答复应使用相同定义。清楚的证据，比笼统宣称定位器始终会响或始终都能找到更有价值。

Public sources / 公开资料

1. Google for Developers — Find Hub Network accessory specification
2. Google for Developers — Find Hub accessory specification: locator tags and unwanted tracking prevention
3. Stellarrisetech — Bluetooth tracker OEM, ODM and embedded solutions

Public documentation checked on 16 October 2026. Independently written guidance; internal test suggestions are not platform certification requirements. No model-specific performance or certification is claimed.
公开资料核对日期：2026 年 10 月 16 日。本文独立撰写；内部测试建议并非平台认证要求，未宣称任何具体型号的性能或认证状态。