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 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), 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.

Quais drivers varrem

Siemens S7, Beckhoff ADS, Mitsubishi MC, IEC 61850, LoRaWAN e HTTP não têm varredura e não mostram botão. O botão aparece só depois que o servidor embutido está no ar, porque é o registro de drivers do servidor 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

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

A frase abaixo dos campos é o orçamento: "2 hosts × 3 unit IDs = 6 sondagens · limite 256", com "· 100 ms de silêncio por host." 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

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é ~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 foi iniciada porque a edição da linha serial não pôde ser salva."). A página Linhas seriais cobre o resto daquele cartão.

Redfish e AVEVA PI: o serviço que a varredura lê

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, e os pontos dele junto.

Rodar uma varredura

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 endpoints…", "Inspecionando o endpoint 2…", "Lendo canais de opc.tcp://plc:4840…", e então "3 dispositivo(s) encontrado(s)."; os drivers que relatam o próprio progresso dizem "Consultando o servidor OPC UA … pelos endpoints anunciados…" e "2 endpoints encontrados.", "Procurando controladores Rockwell…", "Varrendo dispositivos BACnet…", "Inspecionando o nó Matter comissionado 1 de 2…", "Varrendo 2 hosts × 3 unit IDs…" ou "Sondando a unidade 5 (5 de 32)…". Uma varredura que para num erro do driver guarda o que achou e diz isso: "A varredura parou com um erro depois de achar 1 dispositivo(s). 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

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 no OPC UA; 2 resultado(s) concluído(s) mantido(s)." 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 "Aguardando 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

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 relatada. Adicione o dispositivo para configurar tags no editor dele." Nada é persistido até você pressionar Adicionar dispositivo num cartão ("Adicionando…" enquanto roda): o dispositivo é criado com um nome único no driver e exatamente as tags marcadas, o cartão sai da lista, a página abre no dispositivo novo, e o feed mostra "'Pump' adicionado com 3 tag(s)." 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, 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.

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'."

Parear um dispositivo Matter

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 Adicionar 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 uma rede Thread existente cujo dataset você tenha permissão de obter. O formulário diz isso: "Coloque o dispositivo físico em modo de pareamento antes de continuar. O pareamento usa o Bluetooth deste computador."

Parear dispositivo fica habilitado assim que os três estão preenchidos e a estação aceita mudanças. O formulário então percorre cinco passos, Validar, Encontrar, Parear, Entrar na Thread e Salvar, com uma linha de status abaixo deles: "Validando o código de configuração e o dataset Thread…", "Procurando o dispositivo por Bluetooth…", "Autenticando e pareando o dispositivo…", "Enviando a configuração da rede Thread existente…", "Aguardando o dispositivo entrar na rede Thread…", "Salvando o nó comissionado na 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 "Finalizando 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 única identidade (o código de configuração e o dataset nunca são guardados, registrados nem mostrados de novo), a página abre nele, e o feed mostra "Dispositivo Matter 'Luz da cozinha' pareado." 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 ou dataset invá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 não entrou na rede Thread (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. 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

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, 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.