# 機器検出

> ドライバーに機器や点を探させること、それぞれのスキャンが何を必要として何を返すか、進行と取りやめの振る舞い、結果の追加、機器に足りないタグをその機器のページから検出すること、そして Bluetooth 越しの Matter の機器のペアリング。

プロトコルが本当のスキャンに対応しているドライバーでは、**機器検出**が機器や点を探してくれるので、自分で入力する必要はありません。検出はドライバーのノードのコマンドバーにあり（Modbus RTU ではシリアル回線のページの「ユニットを検出」のカードに、MQTT ではブローカーのページの「機器を検出」のカードにあります）、スキャンが取るものはドライバーのページの「スキャンの範囲」のカードにあります。バーがコマンドを持ち、カードがその範囲を持つわけです。すべてに Connector の構成が必要で、そのビットのないロールには範囲のカードもボタンも描かれません。実行がステーションを占有しているあいだ、またはランタイムが停止しているあいだ、スキャンは拒否されます。スキャンが何も返さなかったとき、それは機能の欠落ではなくスキャンの結果です。ボタンは、スキャンが結果を出せるところにだけ出るからです。すでにある機器は、まだ足りない点をその機器自身のページから、「タグ」のカードの見出しにある**タグ検出**で見つけます（[機器のタグを検出する](#discovering-a-devices-tags)を参照）。

## どのドライバーがスキャンするか {#which-drivers-scan}

| ドライバー | スキャンが何をするか | 必要なもの |
| --- | --- | --- |
| Simulated | 模擬機器のモデルのカタログを、すぐ使える実体 1 つずつ、チャネルとともに並べます。 | ありません。 |
| Modbus TCP | 明示したホストとユニット ID に対して Read Device Identification（機能コード 43/14）を送ります。妥当な Modbus の例外応答は、名前は分からなくてもそのユニットの存在を示します。接続先を返し、タグは返しません。 | 「スキャンの範囲」のカード。 |
| Modbus RTU | 回線の保存済みの組を使って、閉じたユニット ID の範囲を順に探索します。要求は同じで、レジスターには触れません。 | 無効か、有効な機器のない回線と、ユニット ID の範囲。 |
| OPC UA | 1 つのサーバーに、公開している endpoint を問い合わせ、続けて各 endpoint のアドレス空間を巡って点を探します。 | サーバーのアドレス。ドライバーのページの「スキャンの範囲」のカードに入れます（「OPC UA サーバーのアドレス（例：opc.tcp://plc-host:4840）」）。入っていないとき、またはアドレスになっていないとき、検出は灰色になり、何が要るかを伝えます。 |
| Rockwell EtherNet/IP | ListIdentity を同報し、各コントローラーのタグを巡ります。応答した Omron のコントローラーは Omron のドライバーに任せます。 | ありません。 |
| BACnet | Who-Is を同報して I-Am の答えを聞き、機器は答えた瞬間に現れます。アドレス、ポート、デバイスインスタンスを返し、タグは返しません。 | ありません。スキャンするネットワークは、ドライバーのページのスキャンの範囲のカードにあり、任意です。空欄なら Who-Is はこのコンピューターのすべてのネットワークへ出ます。 |
| Redfish | 与えられたサービスのアドレスを読み、その最初のシステム、マネージャー、シャーシを巡ります。サービスとその点を返します。 | 「スキャンの範囲」のカード。 |
| AVEVA PI | 与えられた AF の要素とその下のすべてを巡ります。サービスと、属性ごとに 1 つの点を返します。 | 「スキャンの範囲」のカード。 |
| OCPP | 現在このステーションに接続している充電ポイントを並べます。 | ありません。 |
| Matter | このステーションの Fabric にすでに参加しているノードを、それぞれが公開する値とともに並べます。 | ありません。 |
| MQTT | 1 つのブローカーでしばらく受信します。名乗り出た Sparkplug B のエッジノードと機器をそれぞれメトリックをタグとして、またフィルターの下で聞こえた通常のトピックを 1 台の機器のタグとして集めます。[MQTT](driver-mqtt#the-discover-devices-card)を参照してください。 | ホストが保存されたブローカーと、その「機器を検出」のカードの受信時間とトピックフィルター。 |
| Omron | PLC のアドレスがあれば、その PLC に FINS で識別情報を問い合わせます。どの場合も、NJ、NX、NY のコントローラーを探す EtherNet/IP の識別要求を同報します。接続先を返し、タグは返しません。[Omron](driver-omron#discovery)を参照してください。 | ありません。FINS で問い合わせる PLC のアドレスは、ドライバーのページのスキャンの範囲のカードにあり、任意です。 |
| Siemens S7 | S7CommPlus で名前で読む CPU 1 台に、その変数を尋ねます。出るのは CPU が HMI からアクセスでき見えると印を付けた変数で、名前のパスによるツリー（データブロック、構造体または UDT、配列）として出て、枝のチェックはその下のすべてに及びます。それぞれほかの変数と重ならない名前のいちばん短い末尾で名付けられます。DTL は 1 つのタグです。CPU を、名前で読む機器として返します。[Siemens S7](driver-siemens-s7#discovery) を参照。 | ドライバーのページのスキャンの範囲のカード。名前で読む Siemens の機器（そのホストでスキャンし、そのパスワードでサインインします）か、入力した CPU のアドレスです。このステーションの機器がすでに名前で読んでいる CPU を入力したときは、その機器のパスワードでサインインします。 |
| SCPI instruments | VISA が一覧する測定器のリソースすべて（USB、GPIB、ネットワーク。シリアルポートは除きます）に `*IDN?` で識別情報を問い合わせ、アドレスがあればそのホストにも TCP で同じことを問い合わせます。接続先を返し、タグは返しません。[SCPI instruments](driver-scpi#discovery)を参照してください。 | ありません。TCP で問い合わせる測定器のアドレスは、ドライバーのページのスキャンの範囲のカードにあり、任意です。このコンピューターに VISA がなければ、そのアドレスだけに問い合わせます。 |
| NI-DAQmx | NI MAX が知っているすべての機器を、シミュレートされた機器も含めて一覧し、それぞれの物理チャネルを測定の既定値のままタグとして返します。ハードウェアには何も送りません。[NI-DAQmx](driver-ni-daqmx#discovery)を参照してください。 | このコンピューターにインストールされた NI-DAQmx のほかは何も要りません。ないときは、スキャンは何も一覧せず、その理由を示します。 |
| SNMP | 1 つのエージェントの標準サブツリー（システム、インターフェース、UPS とセンサー、求めに応じてホストのリソース）と、指定したもう 1 つのサブツリーをたどります。エージェントを、見つけたオブジェクトをタグとして返し、ドライバーが名前を知っているものは名前で、それ以外は数字で示します。[SNMP](driver-snmp#discovery)を参照してください。 | ドライバーのページのスキャンの範囲のカード：このドライバーの機器、または SNMPv1 か SNMPv2c の community を添えて入力したアドレス。SNMPv3 エージェントは機器を通してスキャンします。 |
| File | 1 つのファイル（受信フォルダーなら最も新しいファイルで、移動しません）を読み、列ごと（CSV）または値ごと（JSON、XML）のタグ、または最後の行（自由形式のテキスト）と、ファイルの情報を付けて返します。どれも読み取りのみです。[File](driver-file#discovery)を参照してください。 | ドライバーのページのスキャンの範囲のカード：このドライバーの機器、または入力したフォルダー、ファイル、書式。テキストの設定はすべてファイルから読み取ります。 |
| Database | 設定済みの機器のデータベースにサインインし、その機器を、テーブルとビューの列ごとのタグ（最新の行、またはキーが最小の行）とともに返します。タグはすべて読み取りのみです。[Database](driver-database#discovery)を参照してください。 | ドライバーのページのスキャンの範囲のカード：このドライバーの機器と、省略可能なテーブル（名前かパターン）。 |

Beckhoff ADS、Mitsubishi MC、LoRaWAN、HTTP、Generic serial and TCP にはスキャンがなく、ボタンも出ません。ボタンは Connector が動き出してから初めて出ます。スキャンが走れるかどうかに答えるのは、Connector のドライバーの一覧だからです。そして、このバージョンが導入するドライバーにだけ出ます。一覧がアプリケーションの知らないアセンブリで答えた場合、ボタンは出ず、導入されているドライバーがこのバージョンの出荷したものではないことが Events のページに記録されます。

## Modbus TCP：「スキャンの範囲」のカード {#modbus-tcp-the-scan-scope-card}

このカードは Modbus TCP のドライバーのページに出ます：「機器の識別だけを読み取ります。レジスターは追加のあとで設定します。」

| 項目 | 値と既定 | 効果 |
| --- | --- | --- |
| **IPv4 のホストまたは CIDR** | アドレス 1 つ、または /24 から /32 までの CIDR。アプリケーションがローカルのサブネットを推測することはありません。 | その範囲のすべてのホストアドレスから、ネットワークアドレスとブロードキャストアドレスを除いたもの。 |
| **ポート** | 1 から 65535。502。 | すべてのホストで呼び出すポート。 |
| **ユニット ID** | 値、カンマ区切りの並び、または昇順の範囲。0 から 255（「1, 3, 8-16」）。「1」。 | 各ホストに、各 ID を尋ねます。 |
| **フレーム形式** | MBAP、RTU。MBAP。 | 各探索を送るフレームです。透過モードのシリアル-Ethernet 変換器は RTU のフレームにしか応答しないので、RTU でスキャンしてください。その場合、ユニット ID が一致して CRC が合う応答だけを数えます。見つかったユニットは、追加するときにスキャンのフレーム形式を引き継ぎます。 |
| **通信の最小間隔（ms）** | 0 から 1000。0。 | 同じホストで探索が終わってから次までの休止で、ホストごとに独立して間隔が取られます。スキャンの中だけの値で、追加した機器に書き込まれることはありません。 |

項目の下の行は見積もりです：「ホスト 2 件 × ユニット ID 3 件 = 探索 6 回 · 上限 256。」で、設定していれば「· ホストごとに 100 ms の休止。」が付きます。1 回のスキャンが送れる探索は最大で 256 回です。上限を超えると行は赤くなり（「このスキャンは探索を 512 回送ります。ネットワークかユニット ID の範囲を 256 回以下に減らしてください。」）、検出が灰色になります。入力の誤りも同じように名指しされます（「「10.0.0」は正しい 4 オクテットの IPv4 アドレスではありません。」「CIDR の接頭長は /24 から /32 のあいだである必要があります。」「ユニット ID を 1 つ以上入力してください（0〜255）。」「ユニット ID の範囲「9-3」は昇順である必要があります。」）。範囲の項目を変えると、前のスキャンの結果は捨てられます。それは別の範囲を説明していたものだからです。同時にスキャンするホストは最大 4 つ、ホストごとに接続 1 つです。

## 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 も、このステーションが聞き取れるネットワーク上で自分を知らせないので、この 2 つのスキャンは、ドライバーのページの「スキャンの範囲」のカードで指し示した 1 つのサービスを読みます。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}

スキャンが動いているあいだ、ドライバーのページは状態の行を書き、バーの検出は**キャンセル**に変わります。状態は互いに独立した 2 つの段階、つまり接続先の検出とチャネルの巡回から来ます：「endpoint をスキャンしています…」「endpoint 2 を調べています…」「opc.tcp://plc:4840 からチャネルを読み取っています…」、そして「機器を 3 台見つけました。」。自分でスキャンを行うドライバーはどこまで進んだかだけを伝え、ページが数えます。「機器検出の進み具合：2 件中 1 件…」。Modbus の 2 つのスキャンだけは行全体を書きます。ポート、ホスト、ユニット ID こそが見守る人の読むものだからです：シリアルの回線では「COM7 をスキャンしています · 探索 32 回…」「ユニット 5 を探索しています（32 件中 5 件目）…」「32 件中 5 件を探索しました。ユニット 5 を確認しました。」「探索 32 回を終えました。」、ネットワークでは「ホスト 2 件 × ユニット ID 3 件 をスキャンしています…」「192.168.0.10:502 · ユニット 3 を探索しています…」「つながらないホスト 192.168.0.11:502 を飛ばしました。」と伝えます。Rockwell のスキャンは同報を出したネットワークを名乗ります。「192.168.0.255, 10.0.0.255 で Rockwell のコントローラーを探しています…」ですので、結果が 0 件でも問いがどこへ行ったかが分かります。ドライバーのエラーで止まったスキャンは、見つけたものを保ってそう伝えます：「機器を 1 台見つけたところで、エラーによりスキャンが止まりました。一覧は不完全かもしれません。」チャネルを読めなかった接続先も、タグ 0 件として並びます。

スキャンは、動いているあいだそのドライバーを占有します。終わるまで、別のノードを選ぶこと（「このドライバーを離れる前に、機器検出を中止してください。」）、機器や回線を追加すること、回線を有効または無効にすること、行の操作を使うことはできません。結果は、そのスキャンを始めたウィンドウのものです。同じステーションの別のブラウザーのタブからは見えません。

### 取りやめる {#cancelling}

**キャンセル**（押すと「中止しています…」）は、両方の段階を止めます。取りやめの前に完全に用意できた候補は並んだまま残り、チャネルをまだ読んでいた接続先は捨てられます。状態には「機器検出を中止しました。」、操作ログ帯には「OPC UA の機器検出を中止しました。完了した結果 2 件は残しています。」と出ます。スキャンは、ドライバーの一時的なソケット、クライアント、セッションが閉じるまで占有したままです。2 秒たつと、状態は「ドライバーが機器検出の資源を解放するのを待っています…」と伝えます。すでに止まったふりをしないためです。ドライバーは、頼まれた瞬間に必ず手放すとは限らないからです。

## 結果 {#the-results}

**検出した機器**のカード（回線では**検出したユニット**）は、候補ごとに 1 枚のカードを並べます。編集できる**名前**、**Endpoint**、そして「タグ 5 件中 2 件を選択中」です。その下に候補のタグの小さなグリッドがあり、**追加**のチェック（既定はオン）、**タグ**、**型**、**アクセス**が並びます。ひとつもなければ「タグの報告はありませんでした。機器を追加してから、その編集画面でタグを設定してください。」と出ます。ドライバーが、チャネルを見つけた場所より短い名前をタグに付けたときは、**タグ**のセルが名前の下の 2 行目にその場所を示します。OPC UA では、ノードの経路の全体です（[OPC UA](driver-opc-ua#discovery) を参照）。カードの**機器を追加**を押すまで（実行中は「追加しています…」）、何も保存されません。押すと、ドライバーの中で一意な名前で、チェックの入ったタグだけを持つ機器が作られ、カードは一覧から消え、新しい機器はスキャンを行ったページの機器の表で強調表示され、そのページは画面に残り、操作ログ帯には「「Pump」をタグ 3 件とともに追加しました。」と出ます。検出されたタグは、ドライバーが報告したとおりに読み取り専用か書き込み可能で届き、その型と既定の変換経路を持ちます。ほかに推測されるものはありません。

すでに持っている機器と一致する候補は**設定済み**と示され、追加の代わりに**開く**を出すので、スキャンがうっかり重複を作ることはありません。一致を見るのは安定した識別名だけ、つまり同じ回線上の Modbus RTU のユニット、同じブローカー上の Sparkplug B のエッジノードか機器、同じ VISA リソースの SCPI 測定器、NI MAX の同じ名前の NI-DAQmx 機器、機器を通して、または同じホストとポートでスキャンした SNMP エージェント、File の機器が同じフォルダーから同じ名前、同じ読み方で読むファイル、自身の Database の機器を通してスキャンしたデータベース、名前で読む機器と同じホストにある Siemens の CPU、Matter のノード ID です。ほかのドライバーは何とも一致させません。届く接続先があることは、それが同じ設備である証拠にならないからです。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 は「Line 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 | ブローカーで 10 秒間聞きます。Sparkplug B の機器では自分のエッジノードだけで、そのノードには誕生を求め、ほかのエッジノードには何も求めません。プレーンの機器では、タグが共有する階層の下のトピックで、共有する階層がなければブローカーのすべてのトピックです。 |
| Siemens S7 | 名前で読む機器で、その CPU の変数を、機器と同じようにサインインして読み、ドライバーのスキャンと同じツリーで出します。アドレスで指定の機器は名前を公開しないので、そのページにはタグ検出が出ません。 |

AVEVA PI にはタグ検出が出ません。巡回は AF 要素から始まり、その要素を機器は持っていないので、点はドライバーの機器検出から来るか、手で追加します。Modbus、BACnet、Omron、SCPI、それにスキャンのないドライバーは点を見つけないので、やはり出ません。

スキャンのあいだ、タグ検出は**キャンセル**に変わり、「タグ」のカードの上に状態の行が出て、スキャンはドライバー自身の機器検出とまったく同じようにドライバーを占有します。ドライバーを必要とするコマンドは描かれたまま灰色になり、理由を示します。タグ検出そのものも、ステーションが変更を受け付けないあいだ、別のスキャンやペアリングがドライバーを占有しているあいだ（「このドライバーで機器検出のスキャンが動いています。終わるまでお待ちください。」）、そして機器がまだアドレスを待っているか、保存が拒む項目を持っているあいだは灰色になります。Connector の構成が必要で、そのビットのないロールにはボタンが描かれません。

スキャンが見つけたものは、「タグ」のカードのすぐ上の**検出したタグ**のカードに出ます。どの値にもチェックが入り、**タグ**、**型**、**アクセス**が並び、名前の下には、ドライバーのページのカードと同じく、ドライバーが点を見つけたより長い場所が出ます。カードの見出しの**タグにして追加**は、チェックした値を機器に、それぞれ一度ずつ、機器のタグがすでにその名前を持っていれば番号を付けて加え、機器を保存します。新しいタグは画面に残る「タグ」のカードの表で強調表示され、操作ログ帯には「「Line PLC」にタグを 2 件追加しました。」と出ます。残った値は一覧に残り、**閉じる**でカードを空にします。公開するすべての値にタグがすでにある機器にはそう伝え（「「Line PLC」が公開するすべての値にタグがすでにあります。」）、スキャンが何も読めなかった機器にも伝えます（「スキャンで「Line PLC」の値が見つかりませんでした。機器が応答するか確認してから、もう一度タグ検出を実行してください。」）。ドライバーを離れると、ドライバーの結果と同じくカードも空になります。

ドライバー自身の機器検出は、まだない機器をこれまでどおり見つけ、その「検出した機器」のカードも変わりません。

## Matter の機器をペアリングする {#pairing-a-matter-device}

Matter は、ここに機器が存在するより前に、実機を Bluetooth 越しに参加させます。そのため Matter のドライバーの最初のコマンドは機器を追加ではなく**機器をペアリング**で、ドライバーのページ上にフォームを開きます（新規…のメニューとドライバーの右クリックメニューにも同じものが出ます）。ペアリングには、Connector の構成、このコンピューターで使える Bluetooth LE の無線、そして機器が参加するネットワークが必要です。ネットワークは、先にドライバーの**ネットワーク**カードに登録しておきます。Wi-Fi の名前とそのパスワード、または Thread ネットワークとそのデータセットです（[ネットワーク](driver-matter#networks)を参照）。そこに使えるネットワークがないあいだ、機器をペアリングは淡色のままで、ツールチップは「先に、機器が参加するネットワークを追加してください。」です。フォームは次のように伝えます：「続ける前に、物理的な機器をペアリングモードにしてください。ペアリングには、このコンピューターの Bluetooth を使います。」

| 項目 | 何であるか |
| --- | --- |
| **機器の名前** | Connector でその機器が持つことになる、編集できる名前です。既定は「Matter 機器」で、プレースホルダーは「キッチンの照明」です。 |
| **Matter のセットアップコード** | 機器に印刷されている公式の 11 桁または 21 桁の手入力コード、または `MT:` で始まる QR のペイロード全体です。入力すると伏せられ、**セットアップコードを表示**で見えます。 |
| **ネットワーク** | 機器が参加するネットワークで、ネットワークカードの使えるネットワークのどれかです。1 つだけならフォームがその名前と種類を 1 行で示し、選ぶものはありません。2 つ以上なら選択欄になります。その下には「Wi-Fi と Thread のどちらで参加するかは、機器自身が示します。種類の違うネットワークは、機器に何かを書き込む前に拒否されます。」と出ます。 |
| **入れるフォルダー** | フォルダーの**新しい機器**がフォームを開いたときだけ（フォルダーの機器の表、その右クリックメニュー、または**新規…** > Matter > `<Folder>` > **新しい機器**）。ペアリングした機器が入るフォルダーで、下に「ペアリングした機器は、このペアリングを開いたフォルダーに入ります。」と出ます。機器をペアリングで開いたときはこの行がなく、機器はドライバー自身の階層に入ります。 |

**機器をペアリング**は、名前とコードが埋まり、使えるネットワークがあり、ステーションが変更を受け付けるようになると押せます。フォームはそこから**確認**、**探索**、**ペアリング**、**ネットワークに参加**、**保存**の 5 段階を進み、その下に状態の行が出ます：「セットアップコードとネットワークを確認しています…」「Bluetooth で機器を探しています…」「機器を認証してペアリングしています…」、続いて Wi-Fi ネットワークなら「Wi-Fi ネットワークの名前とパスワードを機器に送っています…」「機器が Wi-Fi ネットワークに参加するのを待っています…」（Thread ネットワークなら「既存の Thread ネットワークの設定を送っています…」「機器が Thread ネットワークに参加するのを待っています…」）、「コミッショニングしたノードを、ローカルの Fabric に保存しています…」「ペアリングが完了しました。」**キャンセル**が受け付けられるのは、一致する広告が選ばれるまでです（「機器が変更される前に止めます」）。そこから先、ボタンは「安全に終了しています…」となります。機器がすでに変更されており、途中で離れてもステーションはそのノードを記録しなければならないからです。**閉じる**は、何も動いていないときにフォームを閉じます。

成功すると、機器はノード ID を識別として、参加したネットワークの名前を読み取り専用のネットワークの欄に入れて作られ、操作ログ帯には「Matter 機器「キッチンの照明」をペアリングしました。」と出ます。続いてページは Matter のドライバーに開き、新しい機器を機器の表で強調表示して、その機器だけをスキャンします。そのカードには機器が公開する値がチェック付きで**タグにして追加**の横に並び、スキャンは「「キッチンの照明」でタグにする値にチェックを入れてから、「タグにして追加」を押してください。」で終わります。機器が何を出し、それぞれの値が何をするかは[Matter](driver-matter#tags)にあります。セットアップコードは保存も記録もされず、二度と表示されません。ネットワークのパスワードやデータセットはネットワークカードに残り、この Windows ユーザー用に暗号化して保存され、機器にも、そのアドレスにも、ログにも届きません。ノードは参加したのに機器を作れなかったときは、操作ログ帯がそう伝え、検出が立て直しの道になります。失敗ははっきりと伝えられ、やり直せるようにフォームは開いたままになります。コードが正しくない、ネットワークの名前やパスワードやデータセットが正しくない、使える Bluetooth のアダプターがない、Bluetooth が拒否されたか切られている、一致する機器がない（「ペアリングモードにして、近くに置いてやり直してください。」）、セットアップコードが拒否された、機器がもう一方の種類のネットワークかケーブルで参加する（機器には何も書き込まれません）、機器がネットワークに参加できなかったと応えた（見つからない Wi-Fi の名前、拒否されたパスワード、そのほかの拒否。機器は何も残さずペアリングモードに戻るので、ネットワークを直してペアリングし直します）、機器が応えずローカルのネットワークにも現れなかった（そのノードは Fabric に残り、検出で取り戻せます）、Fabric を保存できなかった（機器はすでに参加処理を終えている場合：「Fabric の保存の問題が解決するまで、機器をリセットしないでください。」）、またはほかのペアリングがすでに動いている、といった場合です。それぞれの失敗が機器に何を残すかは[ペアリングが失敗したとき](driver-matter#when-pairing-fails)にあります。ペアリングは一度に 1 つだけです。動いているあいだ、そのドライバーを離れることはできません（「このドライバーを離れる前に、Matter のペアリングが終わるのをお待ちください。」）。

## 機器検出がしないこと {#what-discovery-does-not-do}

スキャンがそれ自体で何かを保存することは決してなく、既存の機器を変えることも、自分でもう一度走ることもありません。サブネット、レジスターの割り付け、シリアルの設定を推測せず、回線やブローカーを有効にも無効にもせず、一覧から消した候補を現場設備から取り除きもしません。パッケージが持たないドライバーでは拒否されます。それぞれのドライバーの結果に何が入るかは、[ドライバー](drivers)の下にあるそのドライバーのページにあります。