做BLE调试的人十有八九都在“蓝牙地址”这四个字上栽过跟头。同样是扫出来的一串MAC有时能用、有时连不上同一个设备Android手机和iOS手机上显示的地址完全不一样到了RPA自动录入场景Excel里留着的那串地址又可能因为大小写、横线、冒号格式不同让整套流程直接崩掉。这篇内容我想把BLE的蓝牙地址机制、连接过程以及RPA在处理这类设备数据时的实战写法放在一起讲清楚适合正在做蓝牙产品调试、测试自动化或者想把设备信息从Excel搬到后台系统的RPA工程师参考。读完你至少能搞明白四件事BLE地址有哪些类型、连接过程里地址怎么变化、ESP32和Mesh场景下的地址问题以及用影刀这种RPA工具做设备数据录入时怎么避免踩坑。1. 先看全局BLE地址、连接过程与RPA的关联在哪很多教程喜欢一上来就列协议栈结果读者看完只知道“BLE很省电”到了实际项目里照样看不懂日志。我个人的经验是先想清楚一个问题你手里拿到的“蓝牙地址”到底是从哪个环节拿到的它是不是当前连接过程真正会用到的那一列数据。1.1 蓝牙地址到底是什么为什么RPA要关心它BLE全称Bluetooth Low Energy蓝牙低功耗工作在2.4GHz频段。它把80MHz带宽切成了40个信道其中3个是广播信道37个是数据信道。设备一开机就在广播信道上发广播包手机或网关扫描到之后如果满足条件就发起连接双方再跳到数据信道上通信。这个“跳到哪个信道、用哪个地址回应”都由链路层按固定规则决定而链路层数据包最前面那一长串身份标识就是蓝牙地址。做RPA的人通常不会写蓝牙协议栈但只要你做过硬件测试自动化多半会遇到这样的场景测试结果Excel里有一列“MAC地址”后台管理系统里也有一个“蓝牙地址”输入框RPA要做的就是把这一列数据一个一个填到网页上。如果不懂BLE地址的分类和格式你很可能会把“扫描到的随机地址”当成固定MAC存进数据库结果第二天设备重启之后地址变了系统里同一台设备就出现了两条重复记录后面的盘点、远程升级、售后查询全部对不上。1.2 地址在BLE协议栈里的位置BLE协议从下往上大概可以分成物理层、链路层、HCI、L2CAP、ATT/GATT和GAP。蓝牙地址主要出现在链路层它解决的是“这一个包是发给谁的、来自谁”的问题。到了应用层iPhone、Android App经常拿到的是GATT服务、特征值、设备名称和系统分配的UUID不一定直接暴露链路层MAC。所以你会发现一个奇怪现象用nRF Connect这类工具能看到设备的MAC地址但用uniapp写App时拿到的deviceId经常是一串UUIDWindows设备管理器里的“蓝牙地址”有时和手机扫描到的还不一样。这不是设备坏了而是不同系统出于隐私保护把底层地址包装成了另一层标识或者用了可轮换的随机地址。搞明白这个区别才能在RPA自动录入时选择正确的字段。2. 蓝牙地址的四种类型与识别方法BLE规范的蓝牙地址一共分成四种不夸张地说一半的“连不上”问题都是因为把四种地址混为一谈。2.1 四种地址类型速查地址类型英文特点常见场景公共设备地址Public Device Address厂商标配全球唯一相当于设备真正的MAC老式蓝牙模块、部分PC网卡静态随机地址Static Random Address启动时随机生成之后基本不变断电重启也可能保持ESP32等开发板默认地址不可解析私有地址Non-resolvable Private Address会周期性变化无法跟踪主要用来防追踪广告广播、低安全性场景可解析私有地址Resolvable Private Address用配对时交换的IRK密钥生成配对过的设备可以解析iPhone、Android默认会使用重点说一下第二类和第四类。ESP32这类开发板默认生成的地址看起来像固定MAC但你千万别当成产品唯一标识。它每次烧录固件后可能都一样但换一个板子可能生成出完全不同的值。如果想做成产品最好在出厂时把地址写入NVS或efuse并在RPA流程里同时记录设备SN用“SNBLE地址”双字段去后台比对不然返修回来刷一次固件地址就变了。2.2 “魔方蓝牙MAC地址怎么设置”到底怎么答有相当多人搜“魔方蓝牙MAC地址怎么设置”其实问的是开发板或者量产模块能不能自定义MAC。这个问题要分两层看如果产品用的是ESP32、nRF52这类可编程芯片厂家可以在项目里调用底层驱动接口设置MAC。例如在ESP32上可以在初始化蓝牙前调用esp_base_mac_addr_set()传入自定义地址然后重启蓝牙控制器。要注意这个接口必须在射频初始化之前调用而且设置完后要确认返回值否则可能会设置失败但不报错。如果产品是量产智能硬件尤其像智能魔方、智能锁这种消费级设备MAC地址一般出厂就烧写好了用户和普通开发人员改不了。通过App看到的那串地址也不一定等于芯片底层MAC可能只是厂商定义的“设备标识”。所以网上教程再怎么讲“设置MAC”都绕不开一个问题你的芯片和固件到底允不允许改。以ESP32为例设置地址的代码很简单但验证环节经常被人忽略#include esp_bt.h esp_bd_addr_t new_addr {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF}; esp_err_t err esp_base_mac_addr_set(new_addr); if (err ESP_OK) { // 重启后生效 esp_restart(); } else { // 通常是ESP_ERR_INVALID_ARG或ESP_ERR_INVALID_VERSION ESP_LOGE(demo, set mac failed: %s, esp_err_to_name(err)); }从RPA或自动化测试的角度看我更建议你在Excel里多留一列“是否自定义地址”。如果设备允许自定义测试脚本还能通过发送AT指令或调用调试接口把地址改成不易冲突的固定值方便仓库管理。否则就老老实实以扫码或App读取的结果为准。2.3 iPhone 13、iOS与uni-app里的deviceId问题每次有人问“iPhone 13为什么扫描不到BLE设备的MAC地址”我都要重复一遍iOS从CoreBluetooth层面开始就不开放底层MAC任何第三方App都拿不到。系统返回的peripheral.identifier是一个UUID它由系统生成、通常不会变但和蓝牙链路层地址是两回事。在uni-app里也是一样。uni.getBluetoothDevices返回的deviceId在iOS上是UUID在Android上很多是MAC地址但官方文档明确要求开发者把它当成“当前平台的设备标识”不要试图解析成MAC。如果有人在问“uni-app ble iOS 可以根据蓝牙的deviceid建立连接吗”答案是可以用而且就应该这样用。连接时直接把这个deviceId传给uni.connectBLEDevice不需要自己拼MAC。uni.openBluetoothAdapter({ success() { uni.startBluetoothDevicesDiscovery({ success() { uni.onBluetoothDeviceFound((devices) { const device devices[0]; console.log(device.deviceId, device.name); // iOSdeviceId是UUID直接连 // Android常见为MAC也不要手动改格式 uni.connectBLEDevice({ deviceId: device.deviceId, success() { console.log(连接成功); }, fail(err) { console.error(连接失败, err); } }); }); } }); } });这个结论对RPA测试特别重要真机自动化里千万不要用字符串拼接的方式去构造iOS的deviceId也不要让RPA脚本把Excel里的MAC地址强行填到iOS自动连接步骤里。跨平台方案只能是“把设备名称、广播服务UUID、deviceId三者一起做匹配”。3. BLE连接过程拆解广播、扫描、连接和地址变化RPA工程师写测试用例时经常要把“扫描设备、发起连接、检查连接结果”整个流程自动化。如果你不了解BLE连接过程脚本写出来往往是“扫描三秒就连”结果偶尔成功偶尔失败还查不出原因。3.1 一次标准BLE连接过程一次完整连接大概分五步广播设备按广播间隔如100ms在37、38、39三个信道上轮流发广播包包里带有设备地址、设备名称可选、服务UUID可选。扫描设备扫描到广播包后可以选择发送扫描请求广播设备再回复扫描响应携带额外信息。连接发起方根据广播包里的地址和通道信息发送连接请求双方进入连接状态。连接建立后双方按协商的connection interval在数据信道上通信此时地址可能变成连接中使用的身份地址。如果需要安全通信再做配对和绑定交换密钥。绑定后有些设备会改用可解析私有地址。你会发现地址在不同阶段可能不固定。广播阶段用的是“广播地址”连接阶段可能用“身份地址”绑定后还可能轮换成可解析私有地址。所以RPA脚本在做地址比对时不能假设Excel里的地址等于实时广播地址更可靠的办法是连上之后再读设备信息服务里的“设备名”或“模块序列号”用第二层字段做最终确认。3.2 ESP32轻度睡眠下怎么保住BLE连接低功耗蓝牙产品经常会遇到一个问题设备进入轻睡眠后蓝牙连接掉了。ESP32上打开轻度睡眠如果蓝牙射频进入睡眠模式连接间隔又太长对端设备就会认为连接超时。常见做法是在初始化时调用蓝牙睡眠使能并配合合适的唤醒源esp_bt_controller_init(); esp_bt_controller_enable(ESP_BT_MODE_BTDM); esp_bt_sleep_enable(); // 配置唤醒源例如定时器或GPIO esp_sleep_enable_timer_wakeup(10 * 1000); // 10ms但这里有个坑不同版本的ESP-IDFAPI名称可能不同有的需要配置esp_pm电源管理不能照抄老代码。而且如果BLE和Wi-Fi同时工作睡眠策略会更复杂。经验是如果设备在睡眠期间还要能被远程唤醒最好把连接间隔短一些比如30ms到50ms如果只是定时上报数据干脆设计成“睡一段时间→唤醒→快速连上→发完再睡”比硬抗睡眠断连要稳定得多。从RPA测试的角度自动化用例不要只测“连接成功”也要测“设备睡眠过程中连接是否断、断后能否自动重连”。把这类用例交给影刀或自定义脚本定时跑能省下大量手工测试时间。3.3 BLE Mesh Remote Provisioning 与地址编排BLE Mesh适合大规模设备组网它和普通BLE最大的区别之一就是引入了“节点地址”的概念。Mesh网络里的设备不再依赖传统的蓝牙MAC作为唯一标识而是由Provisioner给每个节点分配一个16位单播地址。另一个重点就是Remote Provisioning即“远程配网”当一个未配网设备离Provisioner太远或者藏在金属箱里无法直接通信时已经入网的节点可以作为中继转发配网包完成远程入网。这个场景对RPA非常有价值大规模Mesh设备入网时运维人员不可能拿着一台手机挨个到设备旁边点配网常见方案是写一个后台脚本配合RPA操作配网工具批量读取未配网设备列表分配节点地址再记录到Excel。Excel里至少要有三列设备MAC/DeviceUUID、Mesh单播地址、入网时间。后续RPA巡检时就按单播地址去查在线状态而不是傻傻地去匹配合成MAC。4. RPA实战从Excel里的蓝牙地址到自动化操作RPA工具很多常见的有影刀RPA、金智维、Ui.Vision它们解决的核心问题都是“让软件机器人代替人反复操作网页、Excel和桌面软件”。放到BLE硬件场景里RPA最常做的就是三件事读取测试数据、录入后台、生成报告。4.1 什么样的RPA流程会用到蓝牙地址最典型的是设备信息录入。产线测试完一批蓝牙模块会导出一张Excel表里面有设备SN、蓝牙名称、MAC地址、信号强度、固件版本。后台上货系统需要一个一个录入如果纯手工点键盘都能点出火星子。用RPA可以这样设计打开Excel读取指定Sheet里的数据行。把蓝牙地址统一格式化为大写、去掉分隔符方便后台识别。打开后台设备管理页面循环填入设备名、蓝牙地址、备注。每次保存后截图并把“已录入”状态回写到Excel避免重复提交。遇到失败时记录错误原因最后汇总一份失败清单。影刀RPA里组件非常多这个流程基本不需要写复杂代码只需要“打开Excel”“读取区域”“循环”“填表”“点击”“截图”这些基础组件就够了。如果你更习惯代码化实现也可以导入pandas去清洗Excel地址列但要注意影刀在读取大量数据时要提前把Excel文件关闭否则会提示文件占用。4.2 用影刀RPA写一个“Excel读取→网页录入”的最小流程下面是我在实际项目中落地过的一套简化流程组件顺序可以供参考1. 打开Excel文件D:\test_result.xlsx 2. 从“Sheet1”读取A2:C100存为“表格数据” 3. 对于每一行数据 a. 格式化地址 去空格去掉冒号/横线转大写 b. 打开网页https://console.example.com/devices/add c. 等待“设备名称”输入框出现 d. 填入设备名称、蓝牙地址、备注 e. 点击“保存” f. 等待保存成功提示 g. 在表格数据里标记“成功” 4. 最后把结果写回新的Excel文件很多人第一次写RPA会把网页自动化想得太复杂其实核心只有三步打开、填、点。难点在元素识别和等待。影刀的“网页元素”可以自动抓取但要是抓错了常见原因是元素没有唯一id或者页面有iframe。这时就要改用CSS选择器或XPath。另外一定要加“等待元素出现”不要用固定sleep网络抖动一下脚本就崩了。关于“影刀RPA拼多多自动上架教学”里的套路其实和上面的流程一样。如果把“设备信息”换成“商品标题、价格、库存”把“蓝牙地址”换成“商品编码”你已经会拼多多自动上架了。真正决定项目成败的往往不是RPA工具本身而是Excel数据清洗和网页元素定位的稳定性。4.3 RPA手机真机的BLE连接测试怎么搭如果你想更进一步把“手机扫蓝牙并连接”也自动化可以分成两种做法。一种是手机端做UI自动化用Appium或AirTest控制测试App输入设备地址、点击扫描、点击连接、读取结果。这种方案适合在真实系统环境里验证App交互但维护成本高。另一种是PC端RPA加ADB命令协同。先把手机用USB连到电脑RPA通过ADB启动测试App再用adb input输入MAC地址最后抓取App日志确认连接状态。举例adb shell am start -n com.example.bletest/.MainActivity adb shell input text 01:23:45:67:89:AB adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png ./logs/screen.png这种方式不是传统意义上的RPA但很多RPA工程师都在用。它的好处是可以把“硬件设备准备”“App操作”“Web后台录入”放在同一条流水线上做到真正意义上的产测自动化。注意每次连接前要清理手机蓝牙缓存否则手机可能错误地连接旧设备。5. 调试与落地中的常见问题速查实际项目中无论是BLE代码调试还是RPA流程落地问题都集中在下面几张表里。我按“症状—原因—解法”整理了一下方便你直接排查。症状可能原因解决方法Android扫描不到设备设备使用可解析私有地址且未广播完整名称或广播间隔太长开启allowDuplicatesKey扫描时间延长到10秒以上iOS扫描不到设备iOS对蓝牙权限要求严格或设备广播数据未包含可识别服务UUID检查Info.plist蓝牙权限描述服务UUID必须写进广播包能扫描到但连不上地址类型理解错误后台/App保存的是旧地址重新扫描核对Excel里的地址是否当前真实地址RPA填完MAC提交失败Excel里的MAC有横线、小写或全角字符用文本处理组件统一为“大写/无分隔符”格式ESP32轻睡眠后掉线射频睡眠时间过长对端判定连接超时调短连接间隔或者启用连接事件唤醒影刀等RPA找不到网页元素元素在iframe里或页面是动态渲染切换到iframe再定位或使用等待元素出现组件另外还有一个很容易踩的坑RPA循环录入大量设备时网页后台如果响应太慢脚本会连续点击导致重复提交。我习惯在保存成功提示出现后才标记“成功”并且给每次点击加一个1到2秒的“防抖”延时。宁慢勿错否则数据库里一堆重复设备后面清理更麻烦。6. 关于BLE设备自动化的几点个人体会最后再说几个我踩过坑之后才形成的习惯不算标准答案但对大多数人应该有用。第一Excel里的“MAC地址”列一定要在进入RPA流程前清洗完不要指望RPA脚本里做复杂判断。用Excel公式或Python把这列转成统一格式RPA只负责搬运复杂逻辑越少越稳定。第二iOS设备身份字段不要死记硬背。不管是uniapp还是原生开发deviceId就按iOS给的UUID用Android按平台给的地址用两边都别强行“归一化”。系统层的隐私保护你是绕不过去的绕过之后App上架审核也有风险。第三做BLE连接测试自动化别只盯着连接成功概率。把“连接失败时RPA怎么处理”设计好比成功路径更重要。我通常会在流程里加一个“失败重试两次第三次记录日志并截图”这样第二天看结果时根本不用翻一堆截图只要看错误码汇总就行。第四如果你们业务里既有硬件测试又有电商上架完全可以共用一套RPA模板。你给拼多多后台填商品参数和给设备管理系统填蓝牙MAC地址本质上都是“读Excel—填网页—保存”。先把一个流程跑通再复制给另一个场景RPA工程师的成长速度会快很多。按照这套思路我已经把“Excel设备名单—移动端BLE连接测试—Web后台录入”整条链路在影刀RPA里跑通单台设备录入时间从人工的一分半钟降到了十几秒而且全程有截图和日志。做这类项目真正值钱的不是那几行RPA配置而是你对BLE地址机制的理解以及出了问题之后能快速定位是系统隐私限制、设备地址轮换还是网页元素变化的判断力。
做BLE调试的人十有八九都在“蓝牙地址”这四个字上栽过跟头。同样是扫出来的一串MAC有时能用、有时连不上同一个设备Android手机和iOS手机上显示的地址完全不一样到了RPA自动录入场景Excel里留着的那串地址又可能因为大小写、横线、冒号格式不同让整套流程直接崩掉。这篇内容我想把BLE的蓝牙地址机制、连接过程以及RPA在处理这类设备数据时的实战写法放在一起讲清楚适合正在做蓝牙产品调试、测试自动化或者想把设备信息从Excel搬到后台系统的RPA工程师参考。读完你至少能搞明白四件事BLE地址有哪些类型、连接过程里地址怎么变化、ESP32和Mesh场景下的地址问题以及用影刀这种RPA工具做设备数据录入时怎么避免踩坑。1. 先看全局BLE地址、连接过程与RPA的关联在哪很多教程喜欢一上来就列协议栈结果读者看完只知道“BLE很省电”到了实际项目里照样看不懂日志。我个人的经验是先想清楚一个问题你手里拿到的“蓝牙地址”到底是从哪个环节拿到的它是不是当前连接过程真正会用到的那一列数据。1.1 蓝牙地址到底是什么为什么RPA要关心它BLE全称Bluetooth Low Energy蓝牙低功耗工作在2.4GHz频段。它把80MHz带宽切成了40个信道其中3个是广播信道37个是数据信道。设备一开机就在广播信道上发广播包手机或网关扫描到之后如果满足条件就发起连接双方再跳到数据信道上通信。这个“跳到哪个信道、用哪个地址回应”都由链路层按固定规则决定而链路层数据包最前面那一长串身份标识就是蓝牙地址。做RPA的人通常不会写蓝牙协议栈但只要你做过硬件测试自动化多半会遇到这样的场景测试结果Excel里有一列“MAC地址”后台管理系统里也有一个“蓝牙地址”输入框RPA要做的就是把这一列数据一个一个填到网页上。如果不懂BLE地址的分类和格式你很可能会把“扫描到的随机地址”当成固定MAC存进数据库结果第二天设备重启之后地址变了系统里同一台设备就出现了两条重复记录后面的盘点、远程升级、售后查询全部对不上。1.2 地址在BLE协议栈里的位置BLE协议从下往上大概可以分成物理层、链路层、HCI、L2CAP、ATT/GATT和GAP。蓝牙地址主要出现在链路层它解决的是“这一个包是发给谁的、来自谁”的问题。到了应用层iPhone、Android App经常拿到的是GATT服务、特征值、设备名称和系统分配的UUID不一定直接暴露链路层MAC。所以你会发现一个奇怪现象用nRF Connect这类工具能看到设备的MAC地址但用uniapp写App时拿到的deviceId经常是一串UUIDWindows设备管理器里的“蓝牙地址”有时和手机扫描到的还不一样。这不是设备坏了而是不同系统出于隐私保护把底层地址包装成了另一层标识或者用了可轮换的随机地址。搞明白这个区别才能在RPA自动录入时选择正确的字段。2. 蓝牙地址的四种类型与识别方法BLE规范的蓝牙地址一共分成四种不夸张地说一半的“连不上”问题都是因为把四种地址混为一谈。2.1 四种地址类型速查地址类型英文特点常见场景公共设备地址Public Device Address厂商标配全球唯一相当于设备真正的MAC老式蓝牙模块、部分PC网卡静态随机地址Static Random Address启动时随机生成之后基本不变断电重启也可能保持ESP32等开发板默认地址不可解析私有地址Non-resolvable Private Address会周期性变化无法跟踪主要用来防追踪广告广播、低安全性场景可解析私有地址Resolvable Private Address用配对时交换的IRK密钥生成配对过的设备可以解析iPhone、Android默认会使用重点说一下第二类和第四类。ESP32这类开发板默认生成的地址看起来像固定MAC但你千万别当成产品唯一标识。它每次烧录固件后可能都一样但换一个板子可能生成出完全不同的值。如果想做成产品最好在出厂时把地址写入NVS或efuse并在RPA流程里同时记录设备SN用“SNBLE地址”双字段去后台比对不然返修回来刷一次固件地址就变了。2.2 “魔方蓝牙MAC地址怎么设置”到底怎么答有相当多人搜“魔方蓝牙MAC地址怎么设置”其实问的是开发板或者量产模块能不能自定义MAC。这个问题要分两层看如果产品用的是ESP32、nRF52这类可编程芯片厂家可以在项目里调用底层驱动接口设置MAC。例如在ESP32上可以在初始化蓝牙前调用esp_base_mac_addr_set()传入自定义地址然后重启蓝牙控制器。要注意这个接口必须在射频初始化之前调用而且设置完后要确认返回值否则可能会设置失败但不报错。如果产品是量产智能硬件尤其像智能魔方、智能锁这种消费级设备MAC地址一般出厂就烧写好了用户和普通开发人员改不了。通过App看到的那串地址也不一定等于芯片底层MAC可能只是厂商定义的“设备标识”。所以网上教程再怎么讲“设置MAC”都绕不开一个问题你的芯片和固件到底允不允许改。以ESP32为例设置地址的代码很简单但验证环节经常被人忽略#include esp_bt.h esp_bd_addr_t new_addr {0xAA, 0xBB, 0xCC, 0xDD, 0xEE, 0xFF}; esp_err_t err esp_base_mac_addr_set(new_addr); if (err ESP_OK) { // 重启后生效 esp_restart(); } else { // 通常是ESP_ERR_INVALID_ARG或ESP_ERR_INVALID_VERSION ESP_LOGE(demo, set mac failed: %s, esp_err_to_name(err)); }从RPA或自动化测试的角度看我更建议你在Excel里多留一列“是否自定义地址”。如果设备允许自定义测试脚本还能通过发送AT指令或调用调试接口把地址改成不易冲突的固定值方便仓库管理。否则就老老实实以扫码或App读取的结果为准。2.3 iPhone 13、iOS与uni-app里的deviceId问题每次有人问“iPhone 13为什么扫描不到BLE设备的MAC地址”我都要重复一遍iOS从CoreBluetooth层面开始就不开放底层MAC任何第三方App都拿不到。系统返回的peripheral.identifier是一个UUID它由系统生成、通常不会变但和蓝牙链路层地址是两回事。在uni-app里也是一样。uni.getBluetoothDevices返回的deviceId在iOS上是UUID在Android上很多是MAC地址但官方文档明确要求开发者把它当成“当前平台的设备标识”不要试图解析成MAC。如果有人在问“uni-app ble iOS 可以根据蓝牙的deviceid建立连接吗”答案是可以用而且就应该这样用。连接时直接把这个deviceId传给uni.connectBLEDevice不需要自己拼MAC。uni.openBluetoothAdapter({ success() { uni.startBluetoothDevicesDiscovery({ success() { uni.onBluetoothDeviceFound((devices) { const device devices[0]; console.log(device.deviceId, device.name); // iOSdeviceId是UUID直接连 // Android常见为MAC也不要手动改格式 uni.connectBLEDevice({ deviceId: device.deviceId, success() { console.log(连接成功); }, fail(err) { console.error(连接失败, err); } }); }); } }); } });这个结论对RPA测试特别重要真机自动化里千万不要用字符串拼接的方式去构造iOS的deviceId也不要让RPA脚本把Excel里的MAC地址强行填到iOS自动连接步骤里。跨平台方案只能是“把设备名称、广播服务UUID、deviceId三者一起做匹配”。3. BLE连接过程拆解广播、扫描、连接和地址变化RPA工程师写测试用例时经常要把“扫描设备、发起连接、检查连接结果”整个流程自动化。如果你不了解BLE连接过程脚本写出来往往是“扫描三秒就连”结果偶尔成功偶尔失败还查不出原因。3.1 一次标准BLE连接过程一次完整连接大概分五步广播设备按广播间隔如100ms在37、38、39三个信道上轮流发广播包包里带有设备地址、设备名称可选、服务UUID可选。扫描设备扫描到广播包后可以选择发送扫描请求广播设备再回复扫描响应携带额外信息。连接发起方根据广播包里的地址和通道信息发送连接请求双方进入连接状态。连接建立后双方按协商的connection interval在数据信道上通信此时地址可能变成连接中使用的身份地址。如果需要安全通信再做配对和绑定交换密钥。绑定后有些设备会改用可解析私有地址。你会发现地址在不同阶段可能不固定。广播阶段用的是“广播地址”连接阶段可能用“身份地址”绑定后还可能轮换成可解析私有地址。所以RPA脚本在做地址比对时不能假设Excel里的地址等于实时广播地址更可靠的办法是连上之后再读设备信息服务里的“设备名”或“模块序列号”用第二层字段做最终确认。3.2 ESP32轻度睡眠下怎么保住BLE连接低功耗蓝牙产品经常会遇到一个问题设备进入轻睡眠后蓝牙连接掉了。ESP32上打开轻度睡眠如果蓝牙射频进入睡眠模式连接间隔又太长对端设备就会认为连接超时。常见做法是在初始化时调用蓝牙睡眠使能并配合合适的唤醒源esp_bt_controller_init(); esp_bt_controller_enable(ESP_BT_MODE_BTDM); esp_bt_sleep_enable(); // 配置唤醒源例如定时器或GPIO esp_sleep_enable_timer_wakeup(10 * 1000); // 10ms但这里有个坑不同版本的ESP-IDFAPI名称可能不同有的需要配置esp_pm电源管理不能照抄老代码。而且如果BLE和Wi-Fi同时工作睡眠策略会更复杂。经验是如果设备在睡眠期间还要能被远程唤醒最好把连接间隔短一些比如30ms到50ms如果只是定时上报数据干脆设计成“睡一段时间→唤醒→快速连上→发完再睡”比硬抗睡眠断连要稳定得多。从RPA测试的角度自动化用例不要只测“连接成功”也要测“设备睡眠过程中连接是否断、断后能否自动重连”。把这类用例交给影刀或自定义脚本定时跑能省下大量手工测试时间。3.3 BLE Mesh Remote Provisioning 与地址编排BLE Mesh适合大规模设备组网它和普通BLE最大的区别之一就是引入了“节点地址”的概念。Mesh网络里的设备不再依赖传统的蓝牙MAC作为唯一标识而是由Provisioner给每个节点分配一个16位单播地址。另一个重点就是Remote Provisioning即“远程配网”当一个未配网设备离Provisioner太远或者藏在金属箱里无法直接通信时已经入网的节点可以作为中继转发配网包完成远程入网。这个场景对RPA非常有价值大规模Mesh设备入网时运维人员不可能拿着一台手机挨个到设备旁边点配网常见方案是写一个后台脚本配合RPA操作配网工具批量读取未配网设备列表分配节点地址再记录到Excel。Excel里至少要有三列设备MAC/DeviceUUID、Mesh单播地址、入网时间。后续RPA巡检时就按单播地址去查在线状态而不是傻傻地去匹配合成MAC。4. RPA实战从Excel里的蓝牙地址到自动化操作RPA工具很多常见的有影刀RPA、金智维、Ui.Vision它们解决的核心问题都是“让软件机器人代替人反复操作网页、Excel和桌面软件”。放到BLE硬件场景里RPA最常做的就是三件事读取测试数据、录入后台、生成报告。4.1 什么样的RPA流程会用到蓝牙地址最典型的是设备信息录入。产线测试完一批蓝牙模块会导出一张Excel表里面有设备SN、蓝牙名称、MAC地址、信号强度、固件版本。后台上货系统需要一个一个录入如果纯手工点键盘都能点出火星子。用RPA可以这样设计打开Excel读取指定Sheet里的数据行。把蓝牙地址统一格式化为大写、去掉分隔符方便后台识别。打开后台设备管理页面循环填入设备名、蓝牙地址、备注。每次保存后截图并把“已录入”状态回写到Excel避免重复提交。遇到失败时记录错误原因最后汇总一份失败清单。影刀RPA里组件非常多这个流程基本不需要写复杂代码只需要“打开Excel”“读取区域”“循环”“填表”“点击”“截图”这些基础组件就够了。如果你更习惯代码化实现也可以导入pandas去清洗Excel地址列但要注意影刀在读取大量数据时要提前把Excel文件关闭否则会提示文件占用。4.2 用影刀RPA写一个“Excel读取→网页录入”的最小流程下面是我在实际项目中落地过的一套简化流程组件顺序可以供参考1. 打开Excel文件D:\test_result.xlsx 2. 从“Sheet1”读取A2:C100存为“表格数据” 3. 对于每一行数据 a. 格式化地址 去空格去掉冒号/横线转大写 b. 打开网页https://console.example.com/devices/add c. 等待“设备名称”输入框出现 d. 填入设备名称、蓝牙地址、备注 e. 点击“保存” f. 等待保存成功提示 g. 在表格数据里标记“成功” 4. 最后把结果写回新的Excel文件很多人第一次写RPA会把网页自动化想得太复杂其实核心只有三步打开、填、点。难点在元素识别和等待。影刀的“网页元素”可以自动抓取但要是抓错了常见原因是元素没有唯一id或者页面有iframe。这时就要改用CSS选择器或XPath。另外一定要加“等待元素出现”不要用固定sleep网络抖动一下脚本就崩了。关于“影刀RPA拼多多自动上架教学”里的套路其实和上面的流程一样。如果把“设备信息”换成“商品标题、价格、库存”把“蓝牙地址”换成“商品编码”你已经会拼多多自动上架了。真正决定项目成败的往往不是RPA工具本身而是Excel数据清洗和网页元素定位的稳定性。4.3 RPA手机真机的BLE连接测试怎么搭如果你想更进一步把“手机扫蓝牙并连接”也自动化可以分成两种做法。一种是手机端做UI自动化用Appium或AirTest控制测试App输入设备地址、点击扫描、点击连接、读取结果。这种方案适合在真实系统环境里验证App交互但维护成本高。另一种是PC端RPA加ADB命令协同。先把手机用USB连到电脑RPA通过ADB启动测试App再用adb input输入MAC地址最后抓取App日志确认连接状态。举例adb shell am start -n com.example.bletest/.MainActivity adb shell input text 01:23:45:67:89:AB adb shell screencap -p /sdcard/screen.png adb pull /sdcard/screen.png ./logs/screen.png这种方式不是传统意义上的RPA但很多RPA工程师都在用。它的好处是可以把“硬件设备准备”“App操作”“Web后台录入”放在同一条流水线上做到真正意义上的产测自动化。注意每次连接前要清理手机蓝牙缓存否则手机可能错误地连接旧设备。5. 调试与落地中的常见问题速查实际项目中无论是BLE代码调试还是RPA流程落地问题都集中在下面几张表里。我按“症状—原因—解法”整理了一下方便你直接排查。症状可能原因解决方法Android扫描不到设备设备使用可解析私有地址且未广播完整名称或广播间隔太长开启allowDuplicatesKey扫描时间延长到10秒以上iOS扫描不到设备iOS对蓝牙权限要求严格或设备广播数据未包含可识别服务UUID检查Info.plist蓝牙权限描述服务UUID必须写进广播包能扫描到但连不上地址类型理解错误后台/App保存的是旧地址重新扫描核对Excel里的地址是否当前真实地址RPA填完MAC提交失败Excel里的MAC有横线、小写或全角字符用文本处理组件统一为“大写/无分隔符”格式ESP32轻睡眠后掉线射频睡眠时间过长对端判定连接超时调短连接间隔或者启用连接事件唤醒影刀等RPA找不到网页元素元素在iframe里或页面是动态渲染切换到iframe再定位或使用等待元素出现组件另外还有一个很容易踩的坑RPA循环录入大量设备时网页后台如果响应太慢脚本会连续点击导致重复提交。我习惯在保存成功提示出现后才标记“成功”并且给每次点击加一个1到2秒的“防抖”延时。宁慢勿错否则数据库里一堆重复设备后面清理更麻烦。6. 关于BLE设备自动化的几点个人体会最后再说几个我踩过坑之后才形成的习惯不算标准答案但对大多数人应该有用。第一Excel里的“MAC地址”列一定要在进入RPA流程前清洗完不要指望RPA脚本里做复杂判断。用Excel公式或Python把这列转成统一格式RPA只负责搬运复杂逻辑越少越稳定。第二iOS设备身份字段不要死记硬背。不管是uniapp还是原生开发deviceId就按iOS给的UUID用Android按平台给的地址用两边都别强行“归一化”。系统层的隐私保护你是绕不过去的绕过之后App上架审核也有风险。第三做BLE连接测试自动化别只盯着连接成功概率。把“连接失败时RPA怎么处理”设计好比成功路径更重要。我通常会在流程里加一个“失败重试两次第三次记录日志并截图”这样第二天看结果时根本不用翻一堆截图只要看错误码汇总就行。第四如果你们业务里既有硬件测试又有电商上架完全可以共用一套RPA模板。你给拼多多后台填商品参数和给设备管理系统填蓝牙MAC地址本质上都是“读Excel—填网页—保存”。先把一个流程跑通再复制给另一个场景RPA工程师的成长速度会快很多。按照这套思路我已经把“Excel设备名单—移动端BLE连接测试—Web后台录入”整条链路在影刀RPA里跑通单台设备录入时间从人工的一分半钟降到了十几秒而且全程有截图和日志。做这类项目真正值钱的不是那几行RPA配置而是你对BLE地址机制的理解以及出了问题之后能快速定位是系统隐私限制、设备地址轮换还是网页元素变化的判断力。
