企业官网建设流程全解析

前阵子接了个批量验收蓝牙手环的项目，两百多台设备要在几天内完成信号测试和数据回传。最开始我天真地以为用手机一台台去点配对就行，结果第一天点了四十台眼睛就花了，更别提中间还有十几台因为蓝牙地址重叠根本连不上。后来我索性把影刀RPA搭起来，配合PC蓝牙栈做了套半自动巡检脚本，才算把这事儿啃下来。也是在这个过程里，我把BLE地址那套机制翻来覆去研究了个透——如果你要拿RPA去操控BLE设备，地址这关绕不过去。

这篇东西我会把两件事揉在一起讲透：第一，BLE的蓝牙地址到底有哪几种、每种是怎么回事、为什么有些设备换个地址你就连不上了；第二，RPA在BLE自动化场景里怎么落地、会遇到哪些坑、怎么排。内容面向的是正在做蓝牙设备产测、自动化巡检、或者想用RPA工具替代重复蓝牙操作的朋友，懂一点Python更容易跟上，不懂也能看懂原理。

1. 先把连接这件事拆开：广播、扫描、发起连接

聊地址之前，得先搞清楚地址在BLE连接过程里是干嘛用的。很多人把蓝牙连接想象成手机之间互加微信——知道ID就能发消息——但实际上BLE更像是在人群里喊话：广播、听到、走过去搭话、建立稳定对话。

整个过程分四步：

1. 广播：外设周期性把自己的存在感发出去，广播包里除了设备名称、服务UUID，还必带一个关键字段——自己的蓝牙地址。
2. 扫描：主机（手机、PC、RPA控制的蓝牙适配器）在广播信道上监听，把收到的广播包连同地址、RSSI信号强度一起报上来。
3. 发起连接：主机挑一个目标地址，发连接请求，双方在数据信道上以约定的连接参数通信。
4. 配对绑定：如果需要加密，再走配对流程，之后双方各存一份长期密钥，下次见面直接认出彼此。

蓝牙地址在整个流程里承担的是“身份标识”的角色，但它这个身份标识跟IP不一样——IP地址在网络里也是可变的，但好歹有个DHCP租约概念；BLE地址更灵活，有些地址变起来比换衣服还勤快。

还有个常见误区：蓝牙地址和Wi-Fi MAC地址虽然都长成XX:XX:XX:XX:XX:XX这个格式，但它俩不是一回事。BLE的地址分公开地址和随机地址两大类，随机地址里又分三种，每种的行为逻辑都不一样。很多RPA脚本连不上设备，问题就出在地址类型上——你以为设备地址是固定的，结果它每隔几分钟换一次，你的脚本傻乎乎地拿着旧地址去连，当然失败。

BLE工作在全球通用的2.4GHz ISM频段，具体是2400MHz到2483.5MHz，分成了40个信道，其中37/38/39这三个信道专门做广播，其余37个信道做数据传输。广播信道上挤满了各种设备的“叫卖声”，扫描方就是靠地址字段区分谁是谁的。

1.1 地址在连接参数里的“隐形作用”

除了身份标识，地址还会影响连接参数的协商过程。发起连接时，主机发的CONNECT_REQ包里除了目标地址，还带了一堆参数：连接间隔（connection interval）、从机延迟（slave latency）、超时时间（supervision timeout）。从机收到后如果地址对得上、参数能接受，就进入连接状态。

这里有个很实际的经验：用RPA做批量连接测试时，连接间隔别设太短。我看到有人把连接间隔设成7.5ms（BLE允许的最小值），结果RPA脚本里还没来得及处理上一批数据，下一批就来了，整个流程卡死。我自己的经验是连接间隔设在30ms到50ms之间，配合slave latency设为4到8，稳定性和功耗平衡得比较好。在自动化场景里，稳定压倒一切，极限参数留给实验室去跑。

2. 蓝牙地址的四种身份：从公开地址到私密地址

BLE地址总共四大类，下面这张表可以先存下来，后面所有排查都靠它。

2.1 公开地址：蓝牙世界的“实名制门牌号”

公开地址是唯一需要花钱去IEEE申请前缀的，格式上有个标志位区分。前24位是公司标识符（OUI），后24位是厂商自己分配的序号。这种地址出厂时烧死，不能改，就像门牌号一样——好处是稳定、好追查，坏处是一旦泄露，设备到哪儿都能被认出，隐私性为零。

实际产品里用公开地址的不多，主要是成本问题。IEEE的OUI不是白给的，小厂商不愿意花这个钱。而且工业场景里如果设备要出口，公开地址还要走合规流程，周期长。所以市面上绝大多数BLE设备用的是下面几种随机地址。

2.2 静态随机地址：消费级设备的“大众选择”

静态随机地址虽然名字带“随机”，但它其实没那么爱变。设备第一次上电时生成一个48位随机数（最高两位设为1b表示静态随机类型），然后把它存在非易失存储里，之后每次开机都用同一个地址，直到恢复出厂设置才会重新生成。

这就好比你在小区里租了个固定停车位，车牌号是随机选的，但只要不搬家就一直是它。我手上的小米手环、某品牌的体脂秤，用的都是静态随机地址。对RPA脚本来说，这种地址最友好——设备重启后地址不变，脚本里缓存一份地址就能长期复用。

但要注意一个特殊场景：有些设备做了“恢复出厂设置后地址重新随机”的逻辑，如果RPA脚本批量测试时恰好有一台设备被人为重置过，它的地址就变了，脚本如果按旧地址去找必然扑空。所以在写RPA的时候，建议不要只依赖地址过滤，还要带上设备名称或者服务UUID双重校验。

2.3 可解析私有地址：手机和耳机的“隐私保护伞”

可解析私有地址（Resolvable Private Address）是苹果、安卓手机和TWS耳机最常用的地址类型，也是最让RPA头疼的一种。

它的机制是这样的：设备双方在绑定时交换一个叫IRK（Identity Resolving Key，身份解析密钥）的东西。之后设备每次广播或扫描，都用这个IRK加上一个随机数算出一个新的地址，隔一段时间就换一个。但换了又怎样？持有对方IRK的设备，收到地址后可以做一次“数学运算”把地址“解”开，看是不是自己认识的那台设备。这就是“可解析”的含义——对认识你的人来说，你换了马甲我也认得出；对不认识你的人来说，你每次都是个陌生人。

用生活比喻就是：你有个专属暗号，你的朋友听到暗号就知道是你，路人听到只觉得是噪音。

RPA如果要连这类设备，最正规的办法是先完成配对绑定拿到IRK，之后无论地址怎么轮换，系统蓝牙栈会自动识别。在Windows或者Linux上，这个IRK存储在蓝牙协议栈里，调用API连设备时不需要手动处理地址。如果你在RPA脚本里绕过系统蓝牙栈，直接用hcitool这类底层工具去连，拿到一个私有地址大概率会连失败——因为那个地址几秒钟后就失效了。

2.4 不可解析私有地址：彻底“匿名”的广播者

NRPA这类地址最特殊：它是随机生成的，没有任何密钥能反推出设备身份，而且可以频繁更换，甚至每次广播都换一个地址。这等于一个人每次都戴着完全不同的面具上街，连朋友都认不出来。

它的用途通常是纯广播类的场景，比如防追踪信标，或者设备只想单向发数据、不想被别人连接。但RPA如果碰到用NRPA的设备，几乎没办法稳定地去连接它——因为目标地址一直在变。这种场景下只能换个思路：让广播包里带设备名称或其他标识，RPA通过广播数据里的服务数据字段来识别目标，而不是通过地址。

3. 从设备上拿到真实地址：日志、抓包和API返回

讲完理论，上实操。实际做RPA自动化时，你得知道从哪儿拿到设备地址，以及拿到的地址是不是能用来连接。

3.1 Android和iOS：隐私限制下的“变形地址”

Android从6.0开始对蓝牙API做了隐私保护，应用层在大多数情况下拿不到真实MAC地址，BluetoothDevice.getAddress()返回的是固定的伪造地址02:00:00:00:00:00。你有BLUETOOTH_CONNECT权限也不行，那是系统层面的限制。如果RPA跑在Android设备上，别指望应用层能读到真实地址，除非你的App是系统签名，或者通过反射调用隐藏API（Android 8.0之后这条路也基本堵死了）。

实际可行的方案是用广播包里的RSSI和服务UUID来做匹配，或者先触发配对流程，在配对记录里通过系统数据库读到地址。

iOS更绝，CoreBluetooth根本不暴露MAC地址，所有设备只有一个系统内部生成的UUID（identifierForVendor之类）。这个UUID每台手机每次都不一样，而且是加密哈希出来的，不是蓝牙地址。很多做uni-app开发的朋友问“iOS能不能根据蓝牙deviceid建立连接”——答案是可以建立连接，但那个deviceid是iOS系统对BLE设备的抽象标识，不是传统意义上的蓝牙MAC，它只在当前设备上有效。同一台BLE设备，在不同iPhone上看到的deviceid是不同字符串。

安卓的情况又好一点，OEM厂商的实现不完全一样，有些国产ROM通过系统接口能拿到真实地址。不过在写RPA脚本时，我建议按“拿不到真实MAC”来做设计，能拿到算惊喜，拿不到也不至于整个流程崩掉。

下面表格总结了各平台情况：

3.2 Linux下用hcitool和btmon抓真实地址

Linux是做RPA+BLE自动化的最佳平台，没有之一。原因很简单：bluez协议栈对底层工具的访问几乎没有限制，你可以看得清清楚楚。

扫描周围设备：

sudo hcitool lescan

输出类似：

LE Scan Report from: 00:1A:7D:DA:71:13 (public) Device: F4:5C:89:93:53:24 (random) Device: C4:7C:8D:6B:1A:02 (random) ...

注意后面括号里的(public)和(random)，这个信息太重要了——它直接告诉你目标设备用的是公开地址还是随机地址。如果是随机地址，还可以继续分析是静态随机还是可解析私有地址。hcitool lescan在低功耗蓝牙上是扫描模式，能看到广播包里的完整信息，对于产测来说够用了。

想看更细的广播数据和地址类型，用btmon：

sudo btmon & sudo hcitool lescan

btmon会把HCI层的所有事件打出来，包括广播包的 AdvA（广播地址）、AdvData（广播数据）、RSSI等字段。我排查一个凌晨两点断连的问题时，就是靠btmon抓到的广播包，发现设备在某个固件版本上把地址类型从静态随机切成了NRPA，导致主机侧一直认为“设备消失了”。

还有hcidump老一些但也能用，以及bluetoothctl：

bluetoothctl [bluetooth]# scan on [bluetooth]# devices

3.3 抓包工具和App辅助定位

nRF Connect这个App（Android/iOS都有）是排查BLE问题的一把好手，扫描页面会直接显示设备的地址类型和广播数据。我习惯用它在现场快速确认设备当前广播的是什么类型的地址，然后再回到RPA脚本里去对齐逻辑。

PC端还有Wireshark配合蓝牙适配器做被动嗅探，但操作成本高，一般产线不太用。日常RPA调试，nRF Connect + Linux命令行基本能覆盖90%的场景。

4. ESP32轻度睡眠下的地址行为与低功耗权衡

聊完怎么拿地址，再看设备端。ESP32是RPA自动化里最常见的被测设备之一，它的BLE实现在低功耗模式下的地址行为，对自动化测试脚本的影响很大。

ESP32轻度睡眠（light sleep）模式下，CPU暂停但BLE外设可以继续工作，广播和连接扫描都还能维持。此时地址的行为取决于固件里配置的地址类型：

• 使用静态随机地址：从轻度睡眠唤醒后地址不变，RPA脚本重连成功率极高，但设备长期用一个地址，有被跟踪的风险。
• 使用可解析私有地址或NRPA：设备每次广播周期都可能换地址，功耗理论上更优（隐私增强，没有一成不变的身份暴露），但RPA脚本如果按地址缓存去重连，就会扑空。

实测了一个场景：某款ESP32传感器用静态随机地址，广播间隔100ms，轻度睡眠下平均电流约120μA；如果改成每10分钟轮换一次NRPA，平均电流几乎没变化，但RPA侧识别设备的逻辑必须从“按地址过滤”改成“按名称+服务UUID过滤”。换句话说，隐私和功耗换来的是自动化的“模糊”——你要用更复杂的匹配逻辑去补偿。

另外很多网友问“魔方蓝牙MAC地址怎么设置”，实际上指的就是在ESP32或者类似模组固件里配置own_addr_type：

// 设置静态随机地址 esp_ble_gap_set_rand_addr(static_rand_addr); // 使用可解析私有地址 esp_ble_gap_config_privacy(true);

这个设置同时也决定了RPA侧要如何去寻址。如果你的自动化目标是长期稳定地连同一台设备，那就别开启隐私地址轮换；如果设备本身就是要匿名广播的，那就让RPA去广播包里找“人”，而不是找“门牌号”。

4.1 批量模拟多设备：让RPA测试更像“产线”

RPA做产测的时候有个需求：模拟几十个设备同时广播，看看主控能不能正确区分。我在ESP32上就是这么干的——让每个设备用不同的静态随机地址启动，启动时通过配置接口烧录一个带有“设备编号”的广播数据。

后面的RPA脚本按编号去匹配，而不是按MAC匹配，因为同一片模组重新刷固件后静态随机地址可能重新生成，但设备编号会一直保留在NVS里。这种设计能避免产线上“MAC地址漂移导致数据对不上”的悲剧。

5. RPA和BLE怎么才能真正打配合

前面铺垫了这么多地址的底层机制，现在说落地。RPA工具（我主要用影刀，金智维、Ui.Vision也试过）本身不能直接操作蓝牙协议栈，它靠的是“借壳生蛋”的思路。

5.1 三种落地架构

我常用的是第二种：RPA负责流程编排（Excel读取、判断、报告生成），Python脚本负责和蓝牙协议栈交互，RPA通过命令行调用Python脚本并读取输出。

5.2 一个典型的RPA+BLE流程

场景：批量读取50台设备的信号强度和设备信息，结果写入Excel并生成报告。

流程如下：

1. RPA从Excel读取待测设备清单（含设备编号和预期地址/名称）。
2. RPA调用Python脚本执行hcitool lescan，获取当前广播设备列表。
3. Python脚本把广播结果解析成JSON（设备地址、地址类型、RSSI、设备名称），输出到临时文件。
4. RPA读取JSON，与Excel清单按设备名称或编号做匹配，标记“发现/未发现”。
5. 对发现的设备，RPA再调用Python脚本发起连接测试，尝试读取GATT服务。
6. 结果回填Excel，异常设备单独标记，由人工复查。

下面是那个Python脚本的核心片段（我用的是bleak这个库，比传统的bluepy在Linux上部署省心）：

import asyncio from bleak import BleakScanner async def scan(): devices = {} def callback(device, adv_data): # device.address 就是蓝牙地址 # adv_data.local_name 是设备名称（可能为空） # adv_data.rssi 是信号强度 entry = { "address": device.address, "name": adv_data.local_name or "", "rssi": adv_data.rssi, "service_uuids": [str(u) for u in adv_data.service_uuids] } devices[device.address] = entry scanner = BleakScanner(detection_callback=callback) await scanner.start() await asyncio.sleep(5) # 扫描5秒 await scanner.stop() return list(devices.values()) if __name__ == "__main__": result = asyncio.run(scan()) import json print(json.dumps(result, ensure_ascii=False))

RPA那边就很简单了——用“执行命令行”组件跑这个脚本，再读取标准输出里打印的JSON。用影刀的话，可以直接用“Python脚本”组件，也可以把脚本做成exe后调用，看个人习惯。

选型理由：为什么选bleak而不是bluepy？主要是Python3.10以上版本的兼容性，bluepy依赖BlueZ的旧接口，在某些新内核上编译报错；bleak是纯Python封装、跨平台，Windows/Linux/macOS都能跑。如果你的环境是Ubuntu 20.04 + Python3.8，bluepy还能凑合用，但现在新项目我不推荐了。

5.3 RPA脚本的“万能胶”设计

RPA和脚本之间的数据对接是门学问。我的经验是：所有中间数据一律走JSON，并且打印到标准输出，RPA从标准输出读取，不要让Python脚本自己去写数据库或者发微信——那会让整个流程不好排查。影刀读取命令行输出没问题，金智维也支持类似机制。如果数据量大，可以写成临时CSV/JSON文件，RPA再去读文件，流程更清晰。

这个“万能胶”设计还有个好处：换RPA工具的时候，只需要改一小段调用组件的配置，核心蓝牙逻辑完全不用动。

6. 实际跑自动化时最容易翻车的三个坑

6.1 系统蓝牙栈“记住”了过期地址

这是最常见的翻车点。Windows或者Linux的蓝牙栈会自动缓存曾经连接过的设备，包括它们的地址、名称、IRK。当RPA脚本调用API去连接一个设备时，系统可能会返回缓存里的信息，而不是最新的广播地址。

我遇到过的情况是这样的：设备A原来用的是静态随机地址（比如F4:5C:89:93:53:24），后来固件升级改成NRPA轮换，系统缓存里还留着那个旧地址和旧配对信息。RPA脚本用名字过滤去连接设备，结果系统去连那个已经不存在的老地址，一直报错。

排查链路是：

1. 先手动跑hcitool lescan，发现设备A现在广播的地址已经变成了D3:21:5E:88:0A:77。
2. bluetoothctl devices看系统缓存，发现还是老地址。
3. 清缓存步骤：

bluetoothctl [bluetooth]# remove F4:5C:89:93:53:24 [bluetooth]# scan on

4. 重新扫描后缓存更新，RPA流程恢复正常。

在RPA流程里，建议每个测试周期开始前加一次“清缓存/重新扫描”的步骤，尤其是大批量产测的时候。用影刀的话，可以在流程里加一个“执行bat脚本”的组件，先把缓存清了再跑蓝牙脚本。

6.2 私有地址轮换导致白名单失效

有朋友做了一款儿童手表，手表端用的是可解析私有地址（RPA类型），MCU里配置了白名单过滤，只允许已知地址连接。原来用固定地址测试一切正常，改成RPA类型后，手机每次都连不上。

根因是：白名单过滤地址，但地址在轮换，白名单里的地址永远是旧的。正确做法是：先用IRK做身份解析，再决定是否允许连接——也就是“认人”而不是“认门牌号”。

RPA脚本侧对应的问题就是：你拿设备上次广播的地址去连接，但这次设备已经换了新地址，你的连接请求到达设备时，设备比对地址发现“我不认识你”。排查方法是看设备端日志，里面会打印“address resolution failed”之类的关键字，说明IRK对不上或者还没完成配对绑定。

解决办法：先走近配对流程，让双方完成IRK交换，之后所有地址轮换都由蓝牙栈自动处理。RPA脚本只需要保证在发起连接前，目标设备已经处于“已绑定”状态。

6.3 RPA脚本的等待时间不够 + 连接超时处理不当

BLE连接不是TCP那种“秒连”。广播间隔100ms、扫描窗口30ms的情况下，从发起扫描到发现目标设备，平均要花一两秒；连接建立过程还要再花几百毫秒到几秒。RPA流程如果沿用网页自动化里的“马上执行下一步”逻辑，几乎必挂。

我踩过最蠢的坑：脚本里连了5秒就报“未发现设备”，后来手动扫描时发现设备其实就在旁边，只是广播间隔被设置成了1000ms（为了省电），扫描周期不够长。

正确做法是在RPA流程里加入统一的重试机制：

FOR attempt IN 1..3: 执行扫描，等待N秒（N根据广播间隔动态调整，广播间隔100ms的等3秒，1000ms的等10秒） 如果发现目标设备： 执行连接请求 IF 连接状态 == 成功: 读取服务，退出循环 ELSE: 记录失败原因，等待2秒，继续下一次尝试 ELSE: 记录“未扫描到设备”，继续下一次尝试 END FOR

把这个逻辑用Python脚本实现，RPA只负责驱动，不要用RPA自身的“延时”组件去硬等，那样流程图会乱成一团。

6.4 完整排查链路案例

最后放一个完整的排查案例，方便你以后按这个路子走：

现象：RPA脚本批量巡检时，第13号设备在连续三轮巡检中，有一轮能连上、两轮连不上，日志里客户端报“GATT连接失败”。

排查步骤：

1. 手动打开nRF Connect扫描，观察13号设备广播，发现它的地址类型是resolvable private，地址每2分钟轮换一次。
2. 用btmon抓连接过程，发现RPA脚本发起连接用的地址是被缓存的旧地址，设备端返回连接拒绝。
3. 检查RPA脚本逻辑，发现里面写了“如果睡眠超过1分钟，使用上次缓存的地址重新连接”，而缓存地址在轮换后已经失效。
4. 修正：改为每次连接前重新扫描并实时获取最新地址；如设备已绑定，则让协议栈自行解析IRK。
5. 连续跑5轮，全部通过。

排查链路的核心一句话：先分清是“看不见”还是“连不上”。看不见是扫描/广播层问题，连不上是连接参数/地址/配对问题。分错方向，排查会绕很远。

7. BLE Mesh与RPA：地址从“点对点”走向“组网”

前面聊的都是单点连接。如果你碰到的是Mesh组网场景（智能灯、楼宇自动化），地址机制又会再加一层复杂度，同时RPA也能在配网和巡检上发挥大作用。

BLE Mesh里节点不再只有一个地址，而是有好几个：单播地址（unicast）、组播地址（group）、虚拟地址（virtual）。配网器（Provisioner）在给设备配网时，会从地址池里分配一个单播地址，同时可以订阅/发布到不同的组播地址上。Mesh里的单播地址是配网器给的，跟MAC没直接关系，但底层蓝牙连接还是得靠MAC地址来建链。

RPA可以做的是“批量配网自动化”：RPA控制主机的蓝牙栈扫描未配网设备，按设备编号分配地址、下发网络密钥、配置组播订阅。整个过程如果手工做，一台设备半分钟，一百台就得五十分钟；用RPA编排配网脚本，把每台设备的地址分配记录、网络密钥、订阅关系都写进Excel，整体时间能压到十分钟以内。

另外热词里提到的“ble mesh remote provisioning”，是Mesh 1.1规范里新增的远程配网能力——配网器可以不和设备直接建立蓝牙连接，而是通过一个已经在网的中继节点去给远处的新节点配网。这相当于“远程拉线”。对RPA的好处很明显：配网人员不用跑现场去靠近每一台设备，RPA只要控制一个中心节点，就能批量搞定一整片区域的新设备入网。

结合RPA实战时，一个简单的做法是让RPA定期触发远程配网请求，检查新节点的单播地址分配情况，再把新节点加入某个组播地址。比如每天凌晨3点执行一次“发现新节点→分配地址→加入会议室灯组→验证状态→写入台账”的流程，早上人来上班灯就能用。

Mesh场景下RPA脚本要注意的是：地址分配记录一定要持久化，否则配网器重启后可能重新分配地址，导致节点通信错乱。我在项目里有一个SQLite表专门存“设备编号 ↔ 单播地址 ↔ 组播地址 ↔ 网络密钥索引”，RPA每完成一轮配网就更新一次，再用Excel同步出来给人看。

8. 最后的一点经验

做RPA+BLE自动化的核心，不是学RPA组件怎么拖拽，而是先把蓝牙地址机制吃透。地址是设备和外界对话的“身份证明”，你在RPA里写的每一个过滤条件、每一次连接请求，都在跟这个身份证明打交道。不理解地址类型，你连设备偶尔连不上这种问题的排查方向都找不对。

有几条实在的经验，送给准备上手的人：

• 先小规模跑通，再放大。别一上来就搞两百台，先用五台设备把地址识别、连接、数据读取、异常重试整个链路跑通，再往大了扩。RPA脚本在高并发扫描的时候，PC蓝牙栈本身可能先撑不住（同一时间只能有一个进程用HCI），所以产线方案通常是用多台树莓派做分布式扫描，RPA统一调度。
• 测试前先手工记录一批设备的地址类型。用nRF Connect或者hcitool看一眼，知道目标设备用的是静态随机还是可解析私有地址，后面写RPA逻辑能少踩一半坑。
• 日志要打全。RPA脚本里每一步的输入输出都打印出来，尤其是扫描结果、连接状态、GATT读写返回。错误信息写明白，出问题十分钟就能定位；不写日志的话，光是复现问题就可能花一个下午。
• 给RPA脚本加“人味”：再自动化的流程也要保留人工介入的入口，比如异常设备单列、关键节点暂停确认、批次结果人工抽查。我在产测项目里都是让RPA跑完自动生成一份汇总表，然后我肉眼扫一眼再放行——省事的同时心里踏实。

最后分享个小技巧：BLE自动化的验收标准里加一个“地址轮换稳定性测试”，让设备在测试期间周期性更换地址，RPA脚本要保证每次都能通过IRK或名称正确识别并连接。这条通过了，你的RPA流程在真实世界里才站得住脚。