# 设备发现

> 让一个驱动去扫描设备或点、每一种扫描需要什么又返回什么、进度和取消的行为、把结果加进来、在设备自己的页面上发现它还缺的点位，以及通过蓝牙配对一台 Matter 设备。

对协议支持真扫描的那些驱动，**发现设备**替你把设备或点找出来，省得你一个个打字。它住在驱动节点的命令栏上（Modbus RTU 则在一条串行线路页面的“发现从站”卡片里，MQTT 则在一个 Broker 页面的“发现设备”卡片里），而扫描要用的一切住在驱动页面的“扫描范围”卡片里：命令栏拿着命令，卡片拿着它的范围。这一整套都需要“配置 Connector”：没有这个权限位的角色既看不到范围卡片，也看不到按钮。有运行占住工作站或运行时已停止时，扫描被拒绝。一次扫描什么都没找到，那就是扫描的结果，而不是功能缺失：按钮只出现在扫描能产出结果的地方。已经有的设备，在它自己的页面上用“点位”卡片标题栏里的**发现点位**找出它还缺的点（见[发现一台设备的点位](#discovering-a-devices-tags)）。

## 哪些驱动会扫描 {#which-drivers-scan}

| 驱动 | 扫描做什么 | 需要什么 |
| --- | --- | --- |
| Simulated | 列出它那份仿真设备型号目录，每一种给一个可直接使用的实例，连同它们的通道。 | 什么都不需要。 |
| Modbus TCP | 向明确指定的主机和单元 ID 发送“读设备识别”（功能码 43/14）；一次校验通过的 Modbus 异常也能证明有这台从站，只是说不出它的名字。返回 endpoint，不返回点位。 | “扫描范围”卡片。 |
| Modbus RTU | 用一条线路已保存的参数组，按顺序探测一段闭区间的单元 ID，用同一个请求，不访问任何寄存器。 | 一条已禁用的或者没有已启用设备的线路，以及一段单元 ID 范围。 |
| OPC UA | 向一台服务器查询它公布的 endpoint，然后浏览每个 endpoint 的地址空间找点。 | 驱动页面“扫描范围”卡片里的服务器地址（“OPC UA 服务器地址，例如 opc.tcp://plc-host:4840”）。没填，或者填的不是一个地址时，“发现设备”置灰并说明期望的是什么。 |
| Rockwell EtherNet/IP | 广播 ListIdentity，然后浏览每台控制器的标签；应答的 Omron 控制器留给 Omron 驱动。 | 什么都不需要。 |
| BACnet | 广播 Who-Is 并等 I-Am 的回答，每台设备一回答就出现。返回地址、端口和设备实例号，不返回点位。 | 什么都不需要；要扫描的网络在驱动页面的“扫描范围”卡片里，是可选的：留空时 Who-Is 从这台计算机的所有网络发出。 |
| Redfish | 读你给它的那个服务地址，并走一遍它的第一个 system、manager 和 chassis。返回这个服务和它的那些点。 | “扫描范围”卡片。 |
| AVEVA PI | 走一遍你给它的那个 AF 元素以及它下面的一切。返回这个服务，并为每个属性给一个点。 | “扫描范围”卡片。 |
| OCPP | 列出此刻连在本工作站上的那些充电桩。 | 什么都不需要。 |
| Matter | 列出已经调试进本工作站 Fabric 的那些节点，连同每个节点公开的值。 | 什么都不需要。 |
| MQTT | 在一个 Broker 上监听一段时间：每个自行宣告的 Sparkplug B 边缘节点和设备，连同它的指标作为点位；以及在过滤器下听到的普通主题，作为一台设备的点位。见[MQTT](driver-mqtt#the-discover-devices-card)。 | 一个已保存主机的 Broker，以及它“发现设备”卡片上的监听时长和主题过滤器。 |
| Omron | 给了 PLC 地址时，通过 FINS 请那台 PLC 报告自身标识；无论如何都广播 EtherNet/IP 身份请求，查找 NJ、NX 和 NY 控制器。返回 endpoint，不返回点位。见[Omron](driver-omron#discovery)。 | 什么都不需要；用于 FINS 探测的 PLC 地址在驱动页面的“扫描范围”卡片里，是可选的。 |
| Siemens S7 | 向一台通过 S7CommPlus 按名称读取的 CPU 询问它的变量：提供 CPU 标为可从 HMI 访问且可见的变量，按每个名称的路径排成树（数据块、结构体或 UDT、数组），勾选分支会作用到它下面的全部内容，每个变量以名称中不与其他变量重复的最短结尾命名；一个 DTL 就是一个点位。把 CPU 作为按名称读取的设备返回。见 [Siemens S7](driver-siemens-s7#discovery)。 | 驱动页面的“扫描范围”卡片：一台按名称读取的 Siemens 设备（在它的主机上扫描并用它的密码登录），或输入的 CPU 地址。输入的 CPU 若已有本站点的设备按名称读取，扫描用那台设备的密码登录。 |
| SCPI instruments | 用 `*IDN?` 请 VISA 列出的每个仪器资源（USB、GPIB、网络；不含其串口）报告自身标识；给了地址时，再通过 TCP 向那台主机问同样的问题。返回 endpoint，不返回点位。见[SCPI instruments](driver-scpi#discovery)。 | 什么都不需要；用于 TCP 探测的仪器地址在驱动页面的“扫描范围”卡片里，是可选的。本计算机没有 VISA 时，只询问这个地址。 |
| NI-DAQmx | 列出 NI MAX 认识的每一台设备，包括其仿真设备，每台设备的物理通道都作为点位，取其测量的默认值；不向硬件发送任何东西。见[NI-DAQmx](driver-ni-daqmx#discovery)。 | 除了本计算机上安装的 NI-DAQmx 之外什么都不需要；没有它时，扫描什么都不列出，并说明原因。 |
| SNMP | 遍历一个代理的标准子树（系统、接口、UPS 和传感器，按需加上主机资源）以及另外指定的一个子树；返回该代理，并把找到的对象作为点位，驱动认识名称的用名称，其余用数字。见 [SNMP](driver-snmp#discovery)。 | 驱动页面上的扫描范围卡片：本驱动的一台设备，或者输入的地址加上 SNMPv1 或 SNMPv2c 的 community。SNMPv3 代理通过其设备扫描。 |
| File | 读取一个文件（收件文件夹则读取其中最新的文件，扫描不移动它），返回它，并为每一列（CSV）或每个值（JSON、XML）提供一个点位，或提供最后一行（自由文本），再加上文件信息，全部为只读。见 [File](driver-file#discovery)。 | 驱动页面上的扫描范围卡片：本驱动的一台设备，或者输入的文件夹、文件和格式，所有文本设置都从文件中读出。 |
| Database | 登录已配置设备的数据库，返回该设备，并为其各表和视图的每一列提供一个点位，取最新一行或键最小的那一行，全部只读。见 [Database](driver-database#discovery)。 | 驱动页面的扫描范围卡片：此驱动的一台设备，以及可选的表（名称或模式）。 |

Beckhoff ADS、Mitsubishi MC、LoRaWAN、HTTP 和 Generic serial and TCP 没有扫描，也不显示按钮。按钮只在 Connector 跑起来之后才出现，因为回答“能不能扫描”的正是 Connector 的驱动清单；而且它只对这个版本装进去的那些驱动出现：如果清单回答的是应用不认得的某个程序集，按钮就不出现，事件页面会记下所装驱动不是这个版本随附的那一个。

## Modbus TCP：“扫描范围”卡片 {#modbus-tcp-the-scan-scope-card}

这张卡片出现在 Modbus TCP 驱动的页面上：“只读的设备识别；寄存器在“添加设备”之后再配置。”

| 字段 | 取值 / 默认值 | 影响 |
| --- | --- | --- |
| **IPv4 主机或 CIDR** | 一个地址，或者一段 /24 到 /32 的 CIDR；应用从不去推断本地子网。 | 这段范围里的每一个主机地址，网络地址和广播地址除外。 |
| **端口** | 1 到 65535；默认 502。 | 每台主机被拨号连接的那个端口。 |
| **单元 ID** | 单个值、逗号分隔的列表或者递增的区间，0 到 255（“1, 3, 8-16”）；默认“1”。 | 每台主机都被问一遍每一个 id。 |
| **帧格式** | MBAP、RTU；默认 MBAP。 | 每次探测所用的帧格式。透传模式的串口转以太网转换器只回应 RTU 帧，所以要用 RTU 扫描；这时只有单元 ID 对得上、CRC 校验通过的应答才算数。找到的从站在你添加时沿用这次扫描的帧格式。 |
| **最小事务间隔（ms）** | 0 到 1000；默认 0。 | 同一台主机上两次完成的探测之间的静默；各台主机各自计节奏。这个值只属于本次扫描：它不会被写进你添加的设备里。 |

字段下面那一行是预算：“2 台主机 × 3 个单元 ID = 6 次探测 · 上限 256”，设了间隔时还带“· 每台主机 100 毫秒静默。”一次扫描最多发 256 次探测；超出预算时这一行变红（“这次扫描会发 512 次探测；请把网段或单元 ID 范围缩到 256 次以内。”），“发现设备”置灰。填错了也是同样点名（“‘10.0.0’不是一个有效的四段 IPv4 地址。”“CIDR 前缀必须在 /24 到 /32 之间。”“请至少填一个单元 ID（0-255）。”“单元 ID 区间‘9-3’必须递增。”）。改动范围里任何一个字段都会丢掉上一次扫描的结果，因为那些结果描述的是另一个范围。同时最多扫四台主机，每台主机一条连接。

## Modbus RTU {#modbus-rtu}

这个扫描在线路的页面上，不在驱动的页面上：**起始单元 ID** 和**结束单元 ID**（1 到 247，递增，默认 1 到 32）以及它们自己的“发现设备”按钮，配一个最坏情况的估算（“32 次探测 · 最多约 32.1 秒，其中每次探测前静默 4.011 ms。”）。扫描用线路已保存的设置把端口打开一次，逐台探测每一个从站，并且宁可拒绝一条正在用的线路，也不去打断它：“这条线路正在使用中。请先禁用它再做设备发现；Ganter Lab 不会自动中断总线，也不会自动把它重新启用。”线路上还没保存的编辑会在扫描开始前先保存；如果保存不了，扫描就不开始（“设备发现没有开始，因为串行线路的修改无法保存。”）。那张卡片的其余部分由[串行线路](connector-lines)页面讲。

## Redfish 和 AVEVA PI：扫描读的那个服务 {#redfish-and-aveva-pi-the-service-the-scan-reads}

Redfish 服务和 PI System 都不会在本工作站听得到的网络上自报家门，所以这两种扫描读的是你指给它的那一个服务，指定的地方是驱动页面的“扫描范围”卡片。Redfish 接收服务地址（`https://bmc-host`，或者在它应答于别处时 `https://bmc-host:8443`），并且总是走 HTTPS 去读它，因为设备的凭据搭在每一次请求上；一个要求明文传输的地址在打字的地方就被拒绝。AVEVA PI 接收服务地址，并在一个 `#` 之后接上这次遍历从哪个 AF 元素开始：`https://pi-host/piwebapi#\\AF-SRV\Plant\Line 3`。没有那个元素就没有东西可走，所以“发现设备”置灰并说明期望的是什么。

这两种扫描都不带凭据去读服务，因为它们跑的时候，那台该拿着凭据的设备还不存在。因此，一个对每次请求都要求认证的服务什么都不会回答，扫描也就什么都找不到：这种服务请手工添加。之后，Redfish 设备在自己的页面上用**发现点位**找出它的点，这次扫描会像设备那样登录；AVEVA PI 设备的点请手工添加。

## 跑一次扫描 {#running-a-scan}

扫描期间，驱动页面打出一行状态，命令栏上的“发现设备”变成**取消**。状态来自两个互不相干的阶段，endpoint 发现和通道浏览：“正在扫描 endpoint…”“正在检查 endpoint 2…”“正在从 opc.tcp://plc:4840 读取通道…”，然后是“找到 3 台设备。”；自己跑一轮扫描的驱动只报到了哪一步，由页面来数，“设备发现进度：2 中的 1…”；两种 Modbus 扫描则写整行，因为端口、主机和单元 ID 正是盯着看的人要读的：串行线路上是“正在扫描 COM7 · 32 次探测…”“正在探测从站 5（第 5 次，共 32 次）…”“已完成 32 次中的第 5 次探测；已检查从站 5。”“扫描结束：32 次探测。”，网络上是“正在扫描 2 个主机 × 3 个单元 ID…”“正在探测 192.168.0.10:502 · 从站 3…”“跳过无法连接的主机 192.168.0.11:502。”；Rockwell 的扫描会说出广播发往哪几个网络，“正在 192.168.0.255, 10.0.0.255 上查找 Rockwell 控制器…”，所以结果为零时也知道问题发往了哪里。因驱动报错而停下的扫描会保留已经找到的东西，并说出来：“扫描在找到 1 台设备后因错误停止。列表可能不完整。”通道读不出来的 endpoint 照样列出来，点位数为零。

扫描期间它独占这个驱动：在它结束之前，你不能选中别的节点（“离开这个驱动之前，请先取消设备发现。”），不能添加设备或线路，不能启用或禁用线路，也不能用行内操作。结果属于发起这次扫描的那个窗口：同一工作站上的另一个浏览器标签页看不到它们。

### 取消 {#cancelling}

**取消**（按下之后写“正在取消…”）把两个阶段都停掉。在取消之前已经完全备好的候选项留在列表里；正在读通道的那个 endpoint 被丢掉。状态读作“设备发现已取消。”，记录条写“OPC UA 的设备发现已取消；保留了 2 条已完成的结果。”扫描会一直占着，直到驱动的临时套接字、客户端或会话关掉为止；两秒之后状态写“正在等待驱动释放它的设备发现资源…”，而不是假装扫描已经停了，因为驱动并不总是一被叫停就立刻撒手。

## 结果 {#the-results}

**发现的设备**卡片（在线路上叫**发现的从站**）为每个候选项列一张小卡：一个可编辑的**名称**、**Endpoint**，以及“已选中 5 个点位中的 2 个”。下面是一张候选点位的紧凑表格，带一个**添加**勾选框（默认打开）、**点位**、**类型**和**访问**；一个都没有时写“没有报告任何点位。把设备添加进来，再在它的编辑器里配置点位。”如果驱动给点位起的名字比它找到这个通道的位置短，**点位**这一格会在名字下面的第二行写出那个位置：在 OPC UA 上，就是节点完整的路径（见 [OPC UA](driver-opc-ua#discovery)）。在你按下某张小卡上的**添加设备**（执行期间写“正在添加…”）之前，什么都不会被存下来：设备以一个在这个驱动上唯一的名字被创建出来，带着恰好是你勾选的那些点位，这张小卡离开列表，新设备在扫描所在页面的“设备”表格里突出显示，那个页面留在画面上，记录条写“已添加“Pump”，带 3 个点位。”发现到的点位按驱动报告的样子进来，是只读还是可写照报告的来，带着它们的类型和默认的转换链；别的一概不推断。

一个和你已经有的设备对得上的候选项会被标为**已经配置过**，并提供**打开**而不是“添加”，这样一次扫描绝不会造出一台意外的重复设备。只有稳定的身份才拿来比对：同一条线路上的一个 Modbus RTU 从站、同一个 Broker 上的一个 Sparkplug B 边缘节点或设备、同一个 VISA 资源下的一台 SCPI 仪器、NI MAX 中同一名称下的一台 NI-DAQmx 设备、通过其设备或在同一主机和端口上扫描的一个 SNMP 代理、File 设备以同样方式从同一文件夹读取的同名文件、通过其自己的 Database 设备扫描的数据库、与按名称读取它的设备同一主机的一台 Siemens CPU，以及一个 Matter 节点 id。别的驱动什么都不比对，因为一个够得着的 endpoint 并不能证明它就是同一台设备。已经配置过的 Matter 设备、SNMP 代理、File 设备、Database 设备和按名称读取的 Siemens 设备在对上之后还能收下东西：它的卡片会列出设备公开、但还没有点位的那些值，默认勾选，而排在**打开**前面的**添加所选点位**会把勾选的值添加到这台设备上（见[Matter](driver-matter#tags)、[SNMP](driver-snmp#what-the-scan-offers)、[File](driver-file#what-the-scan-offers)、[Database](driver-database#what-the-scan-offers)和[Siemens S7](driver-siemens-s7#discovery)）。

**关闭**清空这份列表，而且要等扫描：有扫描跑着的时候它置灰，因为扫描途中清空列表等于把扫描也取消掉，并把已经答复过的东西全扔了。选中另一个驱动，或者改动范围，同样会清空它。扫描期间，删除一台设备或一个点位、以及把设备搬进文件夹，都以同一个原因置灰：扫描占着这个驱动，那条命令会在你确认之后才失败。在 Modbus RTU 上，单元 ID 自成一列，而一个在这条线路上已经配置过的 id 在添加时会被拒绝：“从站 5 已经配置在‘线路 1’上。”

## 发现一台设备的点位 {#discovering-a-devices-tags}

已经有的设备不用回到驱动页面，也能读到更多的点：只要它的驱动能读单台设备的点，它的“点位”卡片标题栏里就在**添加点位**旁边有**发现点位**。这次扫描只读这一台设备，按它保存的样子读（还在等待保存的修改会先保存），并且只列出它公开、但还没有点位的值；比较的是各自读的那个点，从不比较名称：设备已经用别的名称在读的值不会再次列出。

| 驱动 | 怎样读这台设备 |
| --- | --- |
| OPC DA、NI-DAQmx、OCPP、从目录添加的 Simulated 设备 | 驱动浏览设备自己的地址，就像它的扫描浏览找到的每个 endpoint 那样。 |
| OPC UA、Redfish | 同样的浏览，但像设备那样登录，所以只回答已登录客户端的服务器或服务也会列出它的点。 |
| Rockwell EtherNet/IP | Logix 或 Micro800 控制器的标签列表。PLC-5、SLC 500 和 MicroLogix 不公开这种列表，它们的页面上没有“发现点位”。 |
| Matter | 它已调试入网的节点公开的值。 |
| SNMP | 用设备自己的设置和凭据遍历它的代理，范围是标准子树和它的点位已经在读的厂商分支。 |
| File、Database | 驱动通过这台设备做的扫描，就像“扫描范围”卡片扫描驱动的一台设备那样。 |
| MQTT | 在它的 Broker 上监听 10 秒：Sparkplug B 设备只听它自己的边缘节点，并请这个节点重新发出出生消息，其他边缘节点一概不打扰；普通设备听它的点位共有的层级下面的主题，没有共有层级时就听 Broker 上的所有主题。 |
| Siemens S7 | 按名称读取的设备：它的 CPU 的变量，像设备那样登录读取，排成与驱动扫描相同的树。按地址读取的设备不公开名称，它的页面不显示“发现点位”。 |

AVEVA PI 没有“发现点位”：它的遍历从一个 AF 元素开始，而设备并不保存这个元素，所以它的点来自驱动的“发现设备”，或者手工添加。Modbus、BACnet、Omron、SCPI 和没有扫描的驱动找不到点，同样不显示这个按钮。

扫描进行时，“发现点位”变成**取消**，“点位”卡片上方出现一行状态，扫描像驱动自己的“发现设备”一样占住驱动：需要这个驱动的命令仍然画着，变灰，并说明原因。“发现点位”本身在工作站不接受更改时、另一次扫描或配对占住驱动时（“这个驱动上正在进行设备发现扫描。请等它结束。”）、以及设备还在等待地址或有一个保存会拒绝的字段时变灰。它需要“配置 Connector”：没有这个权限位的角色看不到这个按钮。

扫描找到的东西出现在“点位”卡片正上方的**发现的点位**卡片里，每个值都已勾选，列出**点位**、**类型**和**访问**，名称下面还有驱动找到这个点的那个更长的位置，和驱动页面的卡片一样。卡片标题栏里的**添加所选点位**把勾选的值加到设备上，每个只加一次，设备已有同名点位时加上编号，然后保存设备；新点位在仍留在屏幕上的“点位”卡片的表格里突出显示，记录条里写“已向“Line PLC”添加 2 个点位。”剩下的值仍然列着，**关闭**清空这张卡片。已经为它公开的每个值都有点位的设备会得到提示（““Line PLC”公开的每个值都已有点位。”），扫描什么都没读到的设备也会（“扫描在“Line PLC”上没有找到任何值。请确认它有应答，然后再运行一次“发现点位”。”）。离开这个驱动会清空这张卡片，就像会清空驱动的结果一样。

驱动自己的“发现设备”照旧找出你还没有的设备，它的“发现的设备”卡片不变。

## 配对一台 Matter 设备 {#pairing-a-matter-device}

Matter 是在物理设备还没出现在这里之前，就通过蓝牙把它调试进来的，所以 Matter 驱动排在最前的命令是**配对设备**，不是“添加设备”，而且它在驱动页面上打开一个表单（“新建…”菜单和驱动的右键菜单提供的是同一项）。配对需要“配置 Connector”，需要本机上一个能用的蓝牙 LE 射频，还需要设备要加入的网络，事先登记在驱动的**网络**卡片上：一个 Wi-Fi 名称和它的密码，或者一个 Thread 网络和它的数据集（见[网络](driver-matter#networks)）。那里还没有可用的网络时，“配对设备”呈灰色，提示是“请先添加设备要加入的网络。”表单上写着：“继续之前，请把物理设备切到配对模式。配对使用这台计算机上的蓝牙。”

| 字段 | 它是什么 |
| --- | --- |
| **设备名称** | 这台设备将来在 Connector 里的名字，可编辑；默认是“Matter 设备”，占位提示是“厨房灯”。 |
| **Matter 配对码** | 设备上印着的那串官方的 11 位或 21 位手工输入码，或者以 `MT:` 开头的完整 QR 载荷。打字时隐藏；**显示配对码**把它显出来。 |
| **网络** | 设备要加入的网络，是网络卡片上可用网络中的一个。只有一个时，表单用一行字写出它的名称和类型，没有什么可选的；有多个时，它是一个选择列表。下面写着：“设备会自己说明它通过 Wi-Fi 还是 Thread 加入。另一种类型的网络会在向设备写入任何内容之前被拒绝。” |
| **目标文件夹** | 只在某个文件夹的**新建设备**打开表单时出现（文件夹的“设备”表、它的右键菜单，或者**新建…** > Matter > `<Folder>` > **新建设备**）：配对的设备要归入的文件夹，下面写着“配对的设备会放入打开此配对的文件夹。”用“配对设备”打开时，表单没有这一行，设备落在驱动自己的层级。 |

名称和配对码填好、有可用的网络、并且工作站接受改动之后，**配对设备**可用。表单随后走五步：**校验**、**查找**、**配对**、**加入网络**和**保存**，下面配一行状态：“正在校验配对码和网络…”“正在通过蓝牙查找设备…”“正在认证并配对设备…”，然后对 Wi-Fi 网络是“正在把 Wi-Fi 网络的名称和密码发送给设备…”和“正在等待设备加入 Wi-Fi 网络…”（对 Thread 网络是“正在发送现有的 Thread 网络配置…”和“正在等待设备加入 Thread 网络…”），“正在把已调试的节点保存到本地 Fabric…”“配对完成。”**取消**只在选中匹配的广播之前才被接受（“在设备被改动之前停下”）；从那之后按钮读作“正在安全收尾…”，因为设备已经被改动，即使你走开，工作站也必须把这个节点记下来。什么都没在跑的时候，**关闭**把表单收起来。

成功之后，设备被创建出来，身份是节点 id，只读的网络字段里记着它加入的网络的名称，记录条写“已配对 Matter 设备‘厨房灯’。”随后页面在 Matter 驱动上打开，新设备在它的“设备”表格里突出显示，并只扫描这一台设备：它的卡片列出它公开的值，默认勾选，旁边是**添加所选点位**，扫描结束时写“勾选‘厨房灯’中要创建为点位的值，然后点‘添加所选点位’。”设备提供什么、每个值做什么，见[Matter](driver-matter#tags)。配网码从不存下来、从不写进日志、也从不再显示一次；网络的密码或数据集留在网络卡片上，为这个 Windows 用户加密保存，永远不会进入设备、设备地址或日志。如果节点已经调试好但它的设备没能创建出来，记录条会说出来，这时“发现设备”就是补救的路子。失败都直说，表单也留着让你重试：配网码无效、网络的名称、密码或数据集无效、没有能用的蓝牙适配器、蓝牙被拒绝或被关掉、没有匹配的设备（“请让它进入配对模式，靠近一些再试一次。”）、配网码被驳回、设备通过另一种网络或网线入网（什么都不会写进去）、设备回答说加入不了网络（找不到这个 Wi-Fi 名称、密码被拒绝或者别的拒绝：它什么都不保留并回到配对模式，所以改正网络后重新配对）、设备没有回答并且始终没有出现在局域网上（它的节点留在 Fabric 里，可以用“发现设备”找回来）、Fabric 保存不了（设备已经被调试过时：“在 Fabric 存储问题解决之前，不要复位设备。”），或者已经有另一次配对在跑。每种失败会在设备上留下什么，见[配对失败时](driver-matter#when-pairing-fails)。一次只跑一次配对；配对期间你不能离开这个驱动（“离开这个驱动之前，请等 Matter 配对结束。”）。

## 设备发现不做什么 {#what-discovery-does-not-do}

一次扫描本身从不存下任何东西，从不改动已有的设备，也从不自己重跑。它不推断子网、不推断寄存器映射、不推断串口设置，不启用也不禁用线路或 Broker，也不会把被丢弃的候选项从现场设备上抹掉。本安装包没带的驱动会拒绝它。每个驱动的结果里有什么，在[驱动](drivers)下面那个驱动自己的页面上讲。