# Descoberta

> Deixar um driver varrer atrás de dispositivos ou pontos, o que cada varredura recebe e devolve, o progresso e o cancelamento, adicionar resultados, descobrir pela própria página de um dispositivo as tags que faltam a ele e parear um dispositivo Matter por Bluetooth.

Nos drivers cujo protocolo suporta uma varredura de verdade, o **Descobrir** acha dispositivos ou pontos para você em vez de exigir que você os digite. Ele fica na barra de comandos de um nó de driver (e, no Modbus RTU, no cartão Descobrir unidades da página de uma linha serial, e no MQTT, no cartão Descobrir dispositivos da página de um broker), enquanto tudo que a varredura recebe fica no cartão Escopo da varredura da página do driver: a barra leva o comando, o cartão leva o escopo dele. Tudo isso exige Configurar Connector: um papel sem o bit não recebe nem o cartão de escopo nem o botão. Uma varredura recusa enquanto uma execução segura a estação ou o runtime está parado. Quando uma varredura não devolve nada, isso é um resultado de varredura, não um recurso ausente: o botão aparece só onde uma varredura pode produzir resultados. Um dispositivo que você já tem acha pela própria página os pontos que ainda faltam a ele, com **Descobrir tags** no cabeçalho do cartão **Tags** dele (veja [Descobrir as tags de um dispositivo](#discovering-a-devices-tags)).

## Quais drivers varrem {#which-drivers-scan}

| Driver | O que a varredura faz | Precisa de |
| --- | --- | --- |
| Simulated | Lista o catálogo de modelos de dispositivo simulado, uma instância pronta para uso de cada, com os canais deles. | Nada. |
| Modbus TCP | Envia Read Device Identification (função 43/14) a hosts e unit ids explícitos; uma exceção Modbus validada prova a unidade sem nomeá-la. Devolve o endpoint e nenhuma tag. | O cartão Escopo da varredura. |
| Modbus RTU | Sonda sequencialmente uma faixa inclusiva de unit ids pela tupla salva de uma linha, com a mesma requisição e sem acesso a registrador. | Uma linha, desabilitada ou sem dispositivos habilitados, e uma faixa de unit ids. |
| OPC UA | Consulta um servidor pelos endpoints que ele anuncia e depois navega o espaço de endereços de cada endpoint atrás de pontos. | O endereço do servidor, no cartão Escopo da varredura da página do driver ("Endereço do servidor OPC UA, por exemplo opc.tcp://plc-host:4840"). Sem ele, ou com um endereço que não seja um, o Descobrir esmaece e diz o que é esperado. |
| Rockwell EtherNet/IP | Faz difusão de ListIdentity e navega as tags de cada controlador; um controlador Omron que responde fica para o driver Omron. | Nada. |
| BACnet | Faz difusão de Who-Is e escuta as respostas I-Am, com cada dispositivo aparecendo no instante em que responde. Devolve o endereço, a porta e a instância do dispositivo, e nenhuma tag. | Nada; a rede a varrer, no cartão Escopo da varredura da página do driver, é opcional: vazia, o Who-Is sai por todas as redes deste computador. |
| Redfish | Lê o endereço de serviço que recebe e percorre o primeiro sistema, gerenciador e chassi dele. Devolve o serviço e os pontos dele. | O cartão Escopo da varredura. |
| AVEVA PI | Percorre o elemento AF que recebe e tudo que está abaixo dele. Devolve o serviço e um ponto por atributo. | O cartão Escopo da varredura. |
| OCPP | Lista os pontos de recarga conectados a esta estação no momento. | Nada. |
| Matter | Lista os nós já comissionados na Fabric desta estação, cada um com os valores que publica. | Nada. |
| MQTT | Escuta um broker por um tempo: todo nó de borda e dispositivo Sparkplug B que se anuncia, com as métricas dele como tags, e os tópicos simples ouvidos sob um filtro, como tags de um dispositivo. Veja [MQTT](driver-mqtt#the-discover-devices-card). | Um broker com o host salvo, e o tempo de escuta e o filtro de tópicos do cartão Descobrir dispositivos dele. |
| Omron | Com o endereço de um CLP, pede a esse CLP que se identifique por FINS; em todo caso, faz broadcast da requisição de identidade EtherNet/IP para controladores NJ, NX e NY. Devolve os endpoints e nenhuma tag. Veja [Omron](driver-omron#discovery). | Nada; o endereço do CLP para uma sondagem FINS, no cartão Escopo da varredura da página do driver, é opcional. |
| Siemens S7 | Pede a uma CPU, lida por nome por S7CommPlus, as variáveis dela: as que a CPU marca como acessíveis e visíveis da HMI, oferecidas como uma árvore pelo caminho de cada nome (bloco de dados, struct ou UDT, array), em que marcar um ramo alcança tudo o que está abaixo dele, cada uma pelo trecho final mais curto do nome que nenhuma outra variável compartilha, e uma DTL como uma tag só. Devolve a CPU como um dispositivo lido por nome. Veja [Siemens S7](driver-siemens-s7#discovery). | O cartão Escopo da varredura da página do driver: um dispositivo Siemens lido por nome, varrido no host dele e acessado com a senha dele, ou o endereço de uma CPU digitado. Uma CPU digitada que um dispositivo desta estação já lê por nome é acessada com a senha desse dispositivo. |
| SCPI instruments | Pede a cada recurso de instrumento que o VISA lista (USB, GPIB, rede; as portas seriais dele ficam de fora) que se identifique com `*IDN?` e, com um endereço, pergunta o mesmo a esse host por TCP. Devolve os endpoints e nenhuma tag. Veja [SCPI instruments](driver-scpi#discovery). | Nada; o endereço do instrumento para uma sondagem TCP, no cartão Escopo da varredura da página do driver, é opcional. Sem VISA neste computador, só esse endereço é consultado. |
| NI-DAQmx | Lista todo dispositivo que o NI MAX conhece, os simulados dele incluídos, cada um com os canais físicos como tags nos padrões da sua medição; nada é enviado ao hardware. Veja [NI-DAQmx](driver-ni-daqmx#discovery). | Nada além do NI-DAQmx instalado neste computador; sem ele a varredura não lista nada e diz por quê. |
| SNMP | Percorre as subárvores padrão de um agente (sistema, interfaces, nobreak e sensores, recursos do host a pedido) e mais uma subárvore nomeada; devolve o agente com os objetos encontrados como tags, os que o driver conhece pelo nome com o nome e os outros pelo número. Veja [SNMP](driver-snmp#discovery). | O cartão Escopo da varredura da página do driver: um dispositivo do driver, ou um endereço digitado com uma community SNMPv1 ou SNMPv2c. Um agente SNMPv3 é varrido pelo seu dispositivo. |
| File | Lê um arquivo (o mais novo de uma pasta de entrada, que ele não move) e o devolve com uma tag por coluna (CSV) ou por valor (JSON, XML), ou a última linha (texto livre), e os dados do arquivo, todas somente leitura. Veja [File](driver-file#discovery). | O cartão Escopo da varredura da página do driver: um dispositivo do driver, ou uma pasta, um arquivo e um formato digitados, com toda configuração de texto lida do arquivo. |
| Database | Entra no banco de dados de um dispositivo configurado e devolve esse dispositivo com uma tag por coluna das tabelas e views dele, na linha mais recente ou na linha da menor chave, todas somente leitura. Veja [Database](driver-database#discovery). | O cartão Escopo da varredura da página do driver: um dispositivo do driver e, opcionalmente, as tabelas, por um nome ou um padrão. |

Beckhoff ADS, Mitsubishi MC, LoRaWAN, HTTP e Generic serial and TCP não têm varredura e não mostram botão. O botão aparece só depois que o Connector está no ar, porque é o registro de drivers do Connector que responde se uma varredura pode rodar, e ele aparece só para os drivers que esta versão instala: se o registro responder com um assembly que a aplicação não reconhece, o botão fica de fora e a página Eventos registra que o driver instalado não é o que esta versão entrega.

## Modbus TCP: o cartão Escopo da varredura {#modbus-tcp-the-scan-scope-card}

O cartão aparece na página do driver Modbus TCP: "Identificação de dispositivo somente leitura; os registradores são configurados depois de Acrescentar dispositivo."

| Campo | Valores / padrão | Efeito |
| --- | --- | --- |
| **Host IPv4 ou CIDR** | Um endereço, ou um CIDR de /24 a /32; a aplicação nunca deduz a sub-rede local. | Todo endereço de host da faixa, excluídos o de rede e o de difusão. |
| **Porta** | De 1 a 65535; 502. | A porta em que todo host é chamado. |
| **Unit ids** | Valores, listas separadas por vírgula ou faixas crescentes, de 0 a 255 ("1, 3, 8-16"); "1". | Cada host é perguntado por cada id. |
| **Enquadramento** | MBAP, RTU; MBAP. | O quadro em que cada sondagem é enviada. Um conversor serial-Ethernet em modo transparente só responde a quadros RTU, então varra-o em RTU; ali uma resposta só conta quando o Unit ID confere e o CRC é válido. Uma unidade encontrada mantém o enquadramento da varredura quando você a acrescenta. |
| **Intervalo mínimo entre transações (ms)** | De 0 a 1000; 0. | Silêncio entre sondagens concluídas no mesmo host; os hosts são ritmados de forma independente. Vale só para a varredura: ele não é gravado nos dispositivos que você adiciona. |

A frase abaixo dos campos é o orçamento: "2 endereços × 3 unit ids = 6 sondagens · limite 256", com "· 100 ms de silêncio por endereço." quando definido. Uma varredura pode enviar no máximo 256 sondagens; acima do orçamento a frase fica vermelha ("Esta varredura enviaria 512 sondagens; reduza a faixa de rede ou de unit ids para 256 ou menos.") e o Descobrir esmaece. Entrada inválida é nomeada do mesmo jeito ("'10.0.0' não é um endereço IPv4 válido de quatro octetos.", "O prefixo CIDR deve ficar entre /24 e /32.", "Digite pelo menos um unit id (0-255).", "A faixa de unit ids '9-3' deve ser crescente."). Alterar qualquer campo do escopo descarta os resultados da varredura anterior, porque eles descreviam outro escopo. No máximo quatro hosts são varridos ao mesmo tempo, uma conexão por host.

## Modbus RTU {#modbus-rtu}

A varredura fica na página da linha, não na do driver: **Unit id inicial** e **Unit id final** (de 1 a 247, crescentes, de 1 a 32 por padrão) e um botão Descobrir próprio, com uma estimativa do pior caso ("32 sondagens · até cerca de 32,1 s, incluindo 4,011 ms de silêncio antes de cada sondagem."). A varredura abre a porta uma vez com as definições salvas da linha, sonda cada unidade por vez, e recusa uma linha ativa em vez de interrompê-la: "Esta linha está em uso. Desabilite-a antes da descoberta; o Ganter Lab não interrompe nem reabilita o barramento automaticamente." Uma edição pendente na linha é salva antes de a varredura começar; se não puder ser, a varredura não começa ("A descoberta não começou porque a edição da linha serial não pôde ser salva."). A página [Linhas seriais](connector-lines) cobre o resto daquele cartão.

## Redfish e AVEVA PI: o serviço que a varredura lê {#redfish-and-aveva-pi-the-service-the-scan-reads}

Nem um serviço Redfish nem um PI System se anunciam numa rede que esta estação consiga escutar, então essas duas varreduras leem o único serviço para o qual você as aponta, no cartão Escopo da varredura da página do driver. O Redfish recebe o endereço do serviço (`https://bmc-host`, ou `https://bmc-host:8443` onde ele responde em outro lugar) e sempre o lê por HTTPS, porque as credenciais do dispositivo viajam em toda requisição; um endereço que pede o transporte em claro é recusado onde é digitado. O AVEVA PI recebe o endereço do serviço e, depois de um `#`, o elemento AF de onde a caminhada começa: `https://pi-host/piwebapi#\\AF-SRV\Plant\Line 3`. Sem esse elemento não há o que percorrer, então o Descobrir esmaece e diz o que é esperado.

As duas varreduras leem o serviço sem credenciais, porque rodam antes de existir o dispositivo que as guardaria. Um serviço que autentica toda requisição, portanto, não responde nada, e a varredura não acha nada: adicione aquele serviço à mão. Depois, um dispositivo Redfish acha os pontos dele com **Descobrir tags** na própria página, que entra como o dispositivo entra; os pontos de um dispositivo AVEVA PI são adicionados à mão.

## Rodar uma varredura {#running-a-scan}

Enquanto a varredura roda, a página do driver imprime uma linha de status e o Descobrir da barra vira **Cancelar**. O status vem de dois estágios independentes, a descoberta de endpoints e a navegação de canais: "Varrendo os endpoints…", "Inspecionando o endpoint 2…", "Lendo os canais de opc.tcp://plc:4840…", e então "3 dispositivos encontrados."; um driver que roda uma varredura própria informa até onde chegou e a página conta, "Andamento da descoberta: 1 de 2…", enquanto as duas varreduras Modbus escrevem a linha inteira, porque a porta, o endereço e o unit id são o que quem acompanha uma delas lê: "Varrendo COM7 · 32 sondagens…", "Sondando a unidade 5 (5 de 32)…", "Sondagem 5 de 32; unidade 5 verificada.", "Varredura concluída: 32 sondagens." numa linha serial, e "Varrendo 2 endereços × 3 unit ids…", "Sondando 192.168.0.10:502 · unidade 3…", "Endereço inacessível 192.168.0.11:502 ignorado." numa rede; a varredura Rockwell nomeia as redes por onde a difusão saiu, "Procurando controladores Rockwell em 192.168.0.255, 10.0.0.255…", então um resultado zero diz para onde a pergunta foi. Uma varredura que para num erro do driver guarda o que achou e diz isso: "A varredura parou com um erro depois de encontrar 1 dispositivo. A lista pode estar incompleta." Um endpoint cujos canais não puderam ser lidos ainda é listado, com zero tags.

A varredura é dona do driver enquanto roda: você não consegue selecionar outro nó ("Cancele a descoberta antes de sair deste driver."), adicionar um dispositivo ou uma linha, habilitar ou desabilitar linhas, nem usar as ações de linha até ela terminar. Os resultados pertencem à janela que iniciou a varredura: outra aba de navegador na mesma estação não os enxerga.

### Cancelar {#cancelling}

**Cancelar** ("Cancelando…" depois de pressionado) para os dois estágios. Candidatos totalmente preparados antes do cancelamento continuam listados; o endpoint cujos canais ainda estavam sendo lidos é descartado. O status mostra "Descoberta cancelada." e o feed "Descoberta cancelada para OPC UA; 2 resultados concluídos mantidos." A varredura continua ocupada até o soquete, o cliente ou a sessão temporária do driver terem fechado; depois de dois segundos o status diz "Esperando o driver liberar os recursos da descoberta…", em vez de fingir que a varredura já parou, porque um driver nem sempre solta no instante em que é pedido.

## Os resultados {#the-results}

O cartão **Dispositivos descobertos** (numa linha, **Unidades descobertas**) lista um cartão por candidato: um **nome** editável, o **endpoint** e "2 de 5 tags selecionadas". Abaixo dele, uma grade compacta das tags candidatas com uma marca **Adicionar** (ligada por padrão), **Tag**, **Tipo** e **Acesso**; sem nenhuma, "Nenhuma tag informada. Acrescente o dispositivo para configurar as tags no editor dele." Onde o driver dá a uma tag um nome mais curto que o lugar em que achou o canal, a célula **Tag** mostra esse lugar numa segunda linha abaixo do nome: no OPC UA, o caminho inteiro do nó (veja [OPC UA](driver-opc-ua#discovery)). Nada é persistido até você pressionar **Acrescentar dispositivo** num cartão ("Acrescentando…" enquanto roda): o dispositivo é criado com um nome único no driver e exatamente as tags marcadas, o cartão sai da lista, o dispositivo novo fica destacado na tabela Dispositivos da página em que a varredura rodou, que continua na tela, e o feed mostra "'Pump' acrescentado com 3 tags." As tags descobertas chegam somente leitura ou graváveis conforme o driver as relatou, com o tipo delas e com a cadeia padrão; nada mais é deduzido.

Um candidato que corresponde a um dispositivo que você já tem é marcado como **Já configurado** e oferece **Abrir** no lugar do Adicionar, então uma varredura nunca cria uma duplicata acidental. Só identidades estáveis são correspondidas: uma unidade Modbus RTU na mesma linha, um nó de borda ou dispositivo Sparkplug B no mesmo broker, um instrumento SCPI no mesmo recurso VISA, um dispositivo NI-DAQmx com o mesmo nome do NI MAX, um agente SNMP varrido pelo seu dispositivo ou no mesmo host e porta, um arquivo lido da mesma pasta, com o mesmo nome e do mesmo jeito por um dispositivo File, um banco de dados varrido pelo próprio dispositivo Database dele, uma CPU Siemens no mesmo host de um dispositivo que a lê por nome, e um node id Matter. Os outros drivers não correspondem a nada, porque um endpoint alcançável não é prova de que seja o mesmo equipamento. Um dispositivo Matter, um agente SNMP, um dispositivo File, um dispositivo Database ou um dispositivo Siemens lido por nome configurado ainda recebe algo: o cartão dele lista, marcados, os valores que o dispositivo publica e para os quais ainda não tem tag, e **Acrescentar tags**, antes de **Abrir**, acrescenta os marcados a esse dispositivo (veja [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) e [Siemens S7](driver-siemens-s7#discovery)).

**Dispensar** limpa a lista, e espera pela varredura: enquanto uma roda ele fica esmaecido, porque
limpar a lista no meio da varredura também a cancela e joga fora tudo que já tinha respondido.
Selecionar outro driver, ou mudar o escopo, também limpa. Enquanto uma varredura roda, excluir um
dispositivo ou uma tag e mover um dispositivo para uma pasta ficam esmaecidos pelo mesmo motivo: a
varredura segura o driver, e o comando teria falhado depois de você confirmá-lo. No Modbus RTU, o unit id é uma coluna própria, e um id já configurado na linha é recusado ao ser adicionado: "A unidade 5 já está configurada em 'Linha 1'."

## Descobrir as tags de um dispositivo {#discovering-a-devices-tags}

Um dispositivo que você já tem lê mais pontos dele sem voltar à página do driver: o cabeçalho do cartão **Tags** dele traz **Descobrir tags** ao lado de **Acrescentar tag**, sempre que o driver dele consegue ler os pontos de um dispositivo só. A varredura lê só aquele dispositivo, como ele está salvo (uma edição que ainda espera ser salva é salva antes), e lista só os valores que ele publica e para os quais ainda não tem tag, comparados pelo ponto que cada um lê e nunca pelo nome: um valor que o dispositivo já lê com outro nome não é oferecido de novo.

| Driver | Como o dispositivo é lido |
| --- | --- |
| OPC DA, NI-DAQmx, OCPP, um dispositivo Simulated adicionado pelo catálogo | O driver percorre o próprio endereço do dispositivo, como a varredura dele percorre cada endpoint que acha. |
| OPC UA, Redfish | O mesmo percurso, entrando como o dispositivo entra, então um servidor ou um serviço que só responde a um cliente autenticado também lista os pontos dele. |
| Rockwell EtherNet/IP | A lista de tags do controlador, num controlador Logix ou Micro800. Um PLC-5, um SLC 500 ou um MicroLogix não publica nenhuma, e a página dele não mostra Descobrir tags. |
| Matter | Os valores que o nó comissionado dele publica. |
| SNMP | Uma caminhada pelo agente dele com as próprias configurações e credenciais, pelas subárvores padrão e pelo ramo do fabricante que as tags dele já leem. |
| File, Database | A varredura do driver pelo dispositivo, como o cartão Escopo da varredura varre um dispositivo do driver. |
| MQTT | Uma escuta de 10 s no broker dele: o próprio nó de borda de um dispositivo Sparkplug B, a quem se pede o nascimento enquanto nada é pedido a nenhum outro nó de borda; os tópicos de um dispositivo simples abaixo dos níveis que as tags dele compartilham, e todos os tópicos do broker quando elas não compartilham nenhum. |
| Siemens S7 | As variáveis da CPU dele, num dispositivo lido por nome, acessada como o dispositivo acessa, na mesma árvore da varredura do driver. Um dispositivo lido por endereço não publica nomes, e a página dele não mostra Descobrir tags. |

O AVEVA PI não mostra Descobrir tags: a caminhada dele começa num elemento AF, que nenhum dispositivo guarda, então os pontos dele vêm do Descobrir do driver ou são adicionados à mão. Modbus, BACnet, Omron, SCPI e os drivers sem varredura não acham pontos e também não mostram.

Enquanto a varredura roda, Descobrir tags vira **Cancelar**, uma linha de status fica acima do cartão Tags, e a varredura segura o driver exatamente como o próprio Descobrir do driver: os comandos que precisam do driver continuam desenhados, esmaecidos, e dizem por quê. Descobrir tags fica esmaecido também enquanto a estação não aceita mudanças, enquanto outra varredura ou um pareamento segura o driver ("Há uma varredura de descoberta rodando neste driver. Espere ela terminar.") e enquanto o dispositivo ainda espera o endereço dele ou tem um campo que o salvamento recusa. Exige Configurar Connector: um papel sem o bit não recebe o botão.

O que a varredura achou aparece num cartão **Tags descobertas** logo acima do cartão Tags, com cada valor marcado, com **Tag**, **Tipo** e **Acesso** e, abaixo de um nome, o lugar mais longo em que o driver achou o ponto, como nos cartões da página do driver. **Acrescentar tags**, no cabeçalho do cartão, acrescenta os valores marcados ao dispositivo, cada um uma vez, numerado onde uma tag do dispositivo já tem o nome dele, e salva o dispositivo; as tags novas ficam destacadas na tabela do cartão Tags, que continua na tela, e o feed mostra "2 tags acrescentadas a 'Line PLC'." O que sobra continua oferecido, e **Dispensar** limpa o cartão. Um dispositivo que já tem uma tag para cada valor que publica fica sabendo disso ("'Line PLC' já tem uma tag para cada valor que publica."), e um do qual a varredura não leu nada também ("A varredura não achou nenhum valor em 'Line PLC'. Confira se ele responde e rode Descobrir tags de novo."). Sair do driver limpa o cartão, como limpa os resultados do driver.

O próprio Descobrir do driver continua achando os dispositivos que você ainda não tem, e o cartão Dispositivos descobertos dele não muda.

## Parear um dispositivo Matter {#pairing-a-matter-device}

O Matter comissiona o dispositivo físico por Bluetooth antes de ele existir aqui, então o primeiro verbo do driver Matter é **Parear dispositivo**, não Acrescentar dispositivo, e ele abre um formulário na página do driver (o menu Novo… e o menu de contexto do driver oferecem o mesmo). O pareamento exige Configurar Connector, um rádio Bluetooth LE utilizável neste computador e a rede em que o dispositivo vai entrar, cadastrada antes no cartão **Redes** do driver: um nome de Wi-Fi e a senha dele, ou uma rede Thread e o dataset dela (veja [Redes](driver-matter#networks)). Enquanto nenhuma rede ali serve, o Parear dispositivo fica esmaecido com a dica "Acrescente primeiro a rede em que o dispositivo vai entrar." O formulário diz: "Coloque o dispositivo físico em modo de pareamento antes de continuar. O pareamento usa o Bluetooth deste computador."

| Campo | O que é |
| --- | --- |
| **Nome do dispositivo** | O nome editável que o dispositivo terá no Connector; "Dispositivo Matter" por padrão, com "Luz da cozinha" como texto de exemplo. |
| **Código de configuração Matter** | O código manual oficial de 11 ou 21 dígitos impresso no dispositivo, ou o payload QR completo começando com `MT:`. Escondido enquanto é digitado; **Mostrar o código de configuração** o revela. |
| **Rede** | A rede em que o dispositivo vai entrar, uma das redes que servem no cartão Redes. Com uma só, o formulário a nomeia numa linha, com o tipo dela, e não há nada para escolher; com várias, é uma lista de escolha. Embaixo: "O próprio dispositivo diz se entra por Wi-Fi ou por Thread. Uma rede do outro tipo é recusada antes de qualquer coisa ser gravada no dispositivo." |
| **Pasta de destino** | Só quando o **Novo dispositivo** de uma pasta abriu o formulário (na tabela Dispositivos da pasta, no menu de contexto dela ou em **Novo…** > Matter > `<Pasta>` > **Novo dispositivo**): a pasta em que o dispositivo pareado é arquivado, com "O dispositivo pareado entra na pasta de onde este pareamento foi aberto." embaixo. Aberto pelo Parear dispositivo, o formulário não tem essa linha e o dispositivo fica no nível do próprio driver. |

**Parear dispositivo** fica habilitado assim que o nome e o código estão preenchidos, alguma rede serve e a estação aceita mudanças. O formulário então percorre cinco passos, **Validar**, **Encontrar**, **Parear**, **Entrar na rede** e **Salvar**, com uma linha de status abaixo deles: "Validando o código de configuração e a rede…", "Procurando o dispositivo por Bluetooth…", "Autenticando e pareando o dispositivo…", depois, numa rede Wi-Fi, "Enviando ao dispositivo o nome e a senha da rede Wi-Fi…" e "Esperando o dispositivo entrar na rede Wi-Fi…" (numa rede Thread, "Enviando a configuração da rede Thread existente…" e "Esperando o dispositivo entrar na rede Thread…"), "Salvando o nó comissionado no Fabric local…", "Pareamento concluído." O **Cancelar** só é aceito até o anúncio correspondente ser selecionado ("Parar antes de o dispositivo ser alterado"); daí em diante o botão passa a dizer "Terminando com segurança…", porque o dispositivo foi alterado e a estação precisa registrar o nó mesmo que você saia. **Fechar** dispensa o formulário enquanto nada roda.

Quando dá certo, o dispositivo é criado com o node id como identidade e com o nome da rede em que entrou no campo Rede dele, só de leitura, e o feed mostra "Dispositivo Matter 'Luz da cozinha' pareado." A página então abre no driver Matter, com o dispositivo novo destacado na tabela Dispositivos dele, e varre só esse dispositivo: o cartão dele lista, marcados, os valores que ele publica, ao lado de **Acrescentar tags**, e a varredura termina com "Marque os valores de 'Luz da cozinha' que vão virar tags e clique em Acrescentar tags." O que o dispositivo oferece, e o que cada valor faz, está em [Matter](driver-matter#tags). O código de configuração nunca é guardado, registrado nem mostrado de novo; a senha ou o dataset da rede fica no cartão Redes, guardado criptografado para este usuário do Windows, e nunca chega ao dispositivo, ao endereço dele nem ao diário. Se o nó foi comissionado mas o dispositivo dele não pôde ser criado, o feed diz isso e o Descobrir é o caminho de recuperação. As falhas são ditas com clareza e o formulário fica aberto para nova tentativa: um código inválido, uma rede cujo nome, senha ou dataset não é válido, nenhum adaptador Bluetooth utilizável, Bluetooth negado ou desligado, nenhum dispositivo correspondente ("Coloque-o em modo de pareamento, mantenha-o por perto e tente de novo."), um código de configuração rejeitado, um dispositivo que entra pelo outro tipo de rede ou por cabo (nada é gravado nele), um dispositivo que respondeu que não conseguiu entrar na rede (um nome de Wi-Fi que ele não achou, uma senha recusada ou outra recusa: ele não guarda nada e volta ao modo de pareamento, então corrija a rede e pareie de novo), um dispositivo que não deu resposta e nunca apareceu na rede local (o nó dele fica na Fabric e pode ser recuperado com o Descobrir), uma Fabric que não pôde ser salva (quando o dispositivo já tinha sido comissionado: "Não reinicie o dispositivo até o problema de armazenamento da Fabric ser resolvido."), ou outro pareamento já rodando. O que cada falha deixa no dispositivo está em [Quando o pareamento falha](driver-matter#when-pairing-fails). Um pareamento roda por vez; enquanto ele roda, você não consegue sair do driver ("Espere o pareamento Matter terminar antes de sair deste driver.").

## O que a descoberta não faz {#what-discovery-does-not-do}

Uma varredura nunca persiste nada sozinha, nunca altera um dispositivo existente e nunca roda de novo por conta própria. Ela não deduz sub-redes, mapas de registrador nem definições seriais, não habilita nem desabilita uma linha ou um broker, e não remove do equipamento os candidatos dispensados. Ela é recusada num driver que o pacote não carrega. O que os resultados de cada driver contêm está na página daquele driver, em [Drivers](drivers).