设备发现
让一个驱动去扫描设备或点、每一种扫描需要什么又返回什么、进度和取消的行为、把结果加进来，以及通过蓝牙配对一台 Matter 设备。
对协议支持真扫描的那些驱动，发现设备替你把设备或点找出来，省得你一个个打字。它住在驱动节点的命令栏上（Modbus RTU 则在一条串行线路页面的“发现从站”卡片里），而扫描要用的一切住在驱动页面的“扫描范围”卡片里：命令栏拿着命令，卡片拿着它的范围。这一整套都需要“配置 Connector”：没有这个权限位的角色既看不到范围卡片，也看不到按钮。有运行占住工作站或运行时已停止时，扫描被拒绝。一次扫描什么都没找到，那就是扫描的结果，而不是功能缺失：按钮只出现在扫描能产出结果的地方。
哪些驱动会扫描
| 驱动 | 扫描做什么 | 需要什么 |
|---|---|---|
| Simulated | 列出它那份仿真设备型号目录，每一种给一个可直接使用的实例，连同它们的通道。 | 什么都不需要。 |
| Modbus TCP | 向明确指定的主机和从站 ID 发送“读设备识别”（功能码 43/14）；一次校验通过的 Modbus 异常也能证明有这台从站，只是说不出它的名字。返回端点，不返回点位。 | “扫描范围”卡片。 |
| Modbus RTU | 用一条线路已保存的参数组，按顺序探测一段闭区间的从站 ID，用同一个请求，不访问任何寄存器。 | 一条已禁用的或者没有已启用设备的线路，以及一段从站 ID 范围。 |
| OPC UA | 向一台服务器查询它公布的端点，然后浏览每个端点的地址空间找点。 | 驱动页面“扫描范围”卡片里的服务器地址（“OPC UA 服务器地址，例如 opc.tcp://plc-host:4840”）。没填，或者填的不是一个地址时，“发现设备”置灰并说明期望的是什么。 |
| Rockwell EtherNet/IP | 广播 ListIdentity，然后浏览每台控制器的标签。 | 什么都不需要。 |
| BACnet | 广播 Who-Is 并等 I-Am 的回答，每台设备一回答就出现。返回地址、端口和设备实例号，不返回点位。 | 什么都不需要。 |
| Redfish | 读你给它的那个服务地址，并走一遍它的第一个 system、manager 和 chassis。返回这个服务和它的那些点。 | “扫描范围”卡片。 |
| AVEVA PI | 走一遍你给它的那个 AF 元素以及它下面的一切。返回这个服务，并为每个属性给一个点。 | “扫描范围”卡片。 |
| OCPP | 列出此刻连在本工作站上的那些充电桩。 | 什么都不需要。 |
| Matter | 列出已经调试进本工作站 Fabric 的那些节点。 | 什么都不需要。 |
Siemens S7、Beckhoff ADS、Mitsubishi MC、IEC 61850、LoRaWAN 和 HTTP 没有扫描，也不显示按钮。按钮只在内置服务器跑起来之后才出现，因为回答“能不能扫描”的正是服务器的驱动清单；而且它只对这个版本装进去的那些驱动出现：如果清单回答的是应用不认得的某个程序集，按钮就不出现，事件页面会记下所装驱动不是这个版本随附的那一个。
Modbus TCP：“扫描范围”卡片
这张卡片出现在 Modbus TCP 驱动的页面上：“只读的设备识别；寄存器在“添加”之后再配置。”
| 字段 | 取值 / 默认值 | 影响 |
|---|---|---|
| IPv4 主机或 CIDR | 一个地址，或者一段 /24 到 /32 的 CIDR；应用从不去推断本地子网。 | 这段范围里的每一个主机地址，网络地址和广播地址除外。 |
| 端口 | 1 到 65535；默认 502。 | 每台主机被拨号连接的那个端口。 |
| 从站 ID | 单个值、逗号分隔的列表或者递增的区间，0 到 255（“1, 3, 8-16”）；默认“1”。 | 每台主机都被问一遍每一个 id。 |
| 最小事务间隔（毫秒） | 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
这个扫描在线路的页面上，不在驱动的页面上：起始从站 ID 和结束从站 ID（1 到 247，递增，默认 1 到 32）以及它们自己的“发现设备”按钮，配一个最坏情况的估算（“32 次探测 · 最长约 32.1 秒，含每次探测前 4.011 毫秒的静默。”）。扫描用线路已保存的设置把端口打开一次，逐台探测每一个从站，并且宁可拒绝一条正在用的线路，也不去打断它：“这条线路正在使用中。请先禁用它再做设备发现；Ganter Lab 不会自动中断总线，也不会自动把它重新启用。”线路上还没保存的编辑会在扫描开始前先保存；如果保存不了，扫描就不开始（“设备发现没有启动，因为串行线路的编辑保存不了。”）。那张卡片的其余部分由串行线路页面讲。
Redfish 和 AVEVA PI：扫描读的那个服务
Redfish 服务和 PI System 都不会在本工作站听得到的网络上自报家门，所以这两种扫描读的是你指给它的那一个服务，指定的地方是驱动页面的“扫描范围”卡片。Redfish 接收服务地址（https://bmc-host，或者在它应答于别处时 https://bmc-host:8443），并且总是走 HTTPS 去读它，因为设备的凭据搭在每一次请求上；一个要求明文传输的地址在打字的地方就被拒绝。AVEVA PI 接收服务地址，并在一个 # 之后接上这次遍历从哪个 AF 元素开始：https://pi-host/piwebapi#\\AF-SRV\Plant\Line 3。没有那个元素就没有东西可走，所以“发现设备”置灰并说明期望的是什么。
这两种扫描都不带凭据去读服务，因为它们跑的时候，那台该拿着凭据的设备还不存在。因此，一个对每次请求都要求认证的服务什么都不会回答，扫描也就什么都找不到：这种服务连同它的点，请手工添加。
跑一次扫描
扫描期间，驱动页面打出一行状态，命令栏上的“发现设备”变成取消。状态来自两个互不相干的阶段，端点发现和通道浏览：“正在扫描端点…”“正在检查第 2 个端点…”“正在从 opc.tcp://plc:4840 读取通道…”，然后是“找到 3 台设备。”；会自己报告进度的那些驱动则写“正在向 OPC UA 服务器 …… 查询公布的端点…”和“找到 2 个端点。”“正在搜索 Rockwell 控制器…”“正在扫描 BACnet 设备…”“正在检查已调试的 Matter 节点，第 1 个，共 2 个…”“正在扫描 2 台主机 × 3 个从站 ID…”或“正在探测从站 5（第 5 个，共 32 个）…”。因驱动报错而停下的扫描会保留已经找到的东西，并说出来：“扫描在找到 1 台设备之后因错误停止。这份列表可能不完整。”通道读不出来的端点照样列出来，点位数为零。
扫描期间它独占这个驱动：在它结束之前，你不能选中别的节点（“请先取消设备发现，再离开这个驱动。”），不能添加设备或线路，不能启用或禁用线路，也不能用行内操作。结果属于发起这次扫描的那个窗口：同一工作站上的另一个浏览器标签页看不到它们。
取消
取消（按下之后写“正在取消…”）把两个阶段都停掉。在取消之前已经完全备好的候选项留在列表里；正在读通道的那个端点被丢掉。状态读作“设备发现已取消。”，记录条写“已取消 OPC UA 的设备发现；保留 2 条已完成的结果。”扫描会一直占着，直到驱动的临时套接字、客户端或会话关掉为止；两秒之后状态写“正在等待驱动释放它的设备发现资源…”，而不是假装扫描已经停了，因为驱动并不总是一被叫停就立刻撒手。
结果
已发现的设备卡片（在线路上叫已发现的从站）为每个候选项列一张小卡：一个可编辑的名称、端点，以及“已选中 5 个点位中的 2 个”。下面是一张候选点位的紧凑表格，带一个添加勾选框（默认打开）、点位、类型和读写；一个都没有时写“没有报告任何点位。把设备添加进来，再在它的编辑器里配置点位。”在你按下某张小卡上的添加设备（执行期间写“正在添加…”）之前，什么都不会被存下来：设备以一个在这个驱动上唯一的名字被创建出来，带着恰好是你勾选的那些点位，这张小卡离开列表，页面在新设备上打开，记录条写“已添加‘Pump’，带 3 个点位。”发现到的点位按驱动报告的样子进来，是只读还是可写照报告的来，带着它们的类型和默认的转换链；别的一概不推断。
一个和你已经有的设备对得上的候选项会被标为已经配置过，并提供打开而不是“添加”，这样一次扫描绝不会造出一台意外的重复设备。只有稳定的身份才拿来比对：同一条线路上的一个 Modbus RTU 从站，以及一个 Matter 节点 id。别的驱动什么都不比对，因为一个够得着的端点并不能证明它就是同一台设备。
关闭清空这份列表，而且要等扫描：有扫描跑着的时候它置灰，因为扫描途中清空列表等于把扫描也取消掉，并把已经答复过的东西全扔了。选中另一个驱动，或者改动范围，同样会清空它。扫描期间，删除一台设备或一个点位、以及把设备搬进文件夹，都以同一个原因置灰：扫描占着这个驱动，那条命令会在你确认之后才失败。在 Modbus RTU 上，从站 ID 自成一列，而一个在这条线路上已经配置过的 id 在添加时会被拒绝：“从站 5 在‘线路 1’上已经配置过了。”
配对一台 Matter 设备
Matter 是在物理设备还没出现在这里之前，就通过蓝牙把它调试进来的，所以 Matter 驱动排在最前的命令是配对设备，不是“添加设备”，而且它在驱动页面上打开一个表单（“新建…”菜单和驱动的右键菜单提供的是同一项）。配对需要“配置 Connector”，需要本机上一个能用的蓝牙 LE 射频，还需要一个已经存在、并且你有权取得其数据集的 Thread 网络。表单就是这么说的：“继续之前，请先让物理设备进入配对模式。配对使用本机的蓝牙。”
| 字段 | 它是什么 |
|---|---|
| 设备名称 | 这台设备将来在 Connector 里的名字，可编辑；默认是“Matter 设备”，占位提示是“厨房灯”。 |
| Matter 配网码 | 设备上印着的那串官方的 11 位或 21 位手工输入码，或者以 MT: 开头的完整 QR 载荷。打字时隐藏；显示配网码把它显出来。 |
| Thread 运行数据集 | 那个 Thread 网络完整的活动数据集，十六进制，来自网络管理员或者边界路由器；“Ganter Lab 编不出一个已有网络的凭据。”打字时隐藏；显示数据集把它显出来。 |
三项都填好、并且工作站接受改动之后，配对设备可用。表单随后走五步：校验、查找、配对、加入 Thread 和保存，下面配一行状态：“正在校验配网码和 Thread 数据集…”“正在通过蓝牙搜索设备…”“正在认证并配对设备…”“正在发送已有的 Thread 网络配置…”“正在等待设备加入 Thread 网络…”“正在把已调试的节点保存进本地 Fabric…”“配对完成。”取消只在选中匹配的广播之前才被接受（“在设备被改动之前停下”）；从那之后按钮读作“正在安全收尾…”，因为设备已经被改动，即使你走开，工作站也必须把这个节点记下来。什么都没在跑的时候，关闭把表单收起来。
成功之后，设备被创建出来，身份里只有节点 id（配网码和数据集从不存下来、从不写进日志、也从不再显示一次），页面在它上面打开，记录条写“已配对 Matter 设备‘厨房灯’。”如果节点已经调试好但它的设备没能创建出来，记录条会说出来，这时“发现设备”就是补救的路子。失败都直说，表单也留着让你重试：配网码或数据集无效、没有能用的蓝牙适配器、蓝牙被拒绝或被关掉、没有匹配的设备（“请让它进入配对模式，靠近一些再试一次。”）、配网码被驳回、设备没有加入 Thread 网络（它的节点留在 Fabric 里，可以用“发现设备”找回来）、Fabric 保存不了（设备已经被调试过时：“在 Fabric 存储问题解决之前，不要复位设备。”），或者已经有另一次配对在跑。一次只跑一次配对；配对期间你不能离开这个驱动（“请等 Matter 配对结束，再离开这个驱动。”）。
设备发现不做什么
一次扫描本身从不存下任何东西，从不改动已有的设备，也从不自己重跑。它不推断子网、不推断寄存器映射、不推断串口设置，不启用也不禁用线路，也不会把被丢弃的候选项从现场设备上抹掉。本安装包没带的驱动会拒绝它。每个驱动的结果里有什么，在驱动下面那个驱动自己的页面上讲。