Discovery
Letting a driver scan for devices or points, what each scan needs and returns, the progress and cancel behavior, adding results, discovering the tags a device lacks from its own page, and pairing a Matter device over Bluetooth.
For drivers whose protocol supports a real scan, Discover finds devices or points for you instead of having you type them. It lives on a driver node's command bar (and, for Modbus RTU, in the Discover units card of a serial line's page, and for MQTT in the Discover devices card of a broker's page), while everything the scan takes lives in the driver page's Scan scope card: the bar carries the command, the card carries its scope. All of it needs Configure connector: a role without the bit is not drawn the scope card or the button. A scan refuses while a run holds the station or the runtime is stopped. When a scan returns nothing, that is a scan result, not a missing feature: the button appears only where a scan can produce results. A device you already have finds the points it still lacks from its own page, with Discover tags on the head of its Tags card (see Discovering a device's tags).
Which drivers scan
| Driver | What the scan does | Needs |
|---|---|---|
| Simulated | Lists its catalog of simulated device models, one ready-to-use instance each, with their channels. | Nothing. |
| Modbus TCP | Sends Read Device Identification (function 43/14) to explicit hosts and unit ids; a validated Modbus exception proves a unit without naming it. Returns the endpoint and no tags. | The Scan scope card. |
| Modbus RTU | Probes an inclusive unit-id range sequentially over a line's saved tuple, with the same request and no register access. | A line, disabled or without enabled devices, and a unit-id range. |
| OPC UA | Queries one server for its advertised endpoints, then browses each endpoint's address space for points. | The server address, in the driver page's Scan scope card ("OPC UA server address, e.g. opc.tcp://plc-host:4840"). Without it, or with an address that is not one, Discover greys and says what is expected. |
| Rockwell EtherNet/IP | Broadcasts ListIdentity and browses each controller's tags; an Omron controller that answers is left to the Omron driver. | Nothing. |
| BACnet | Broadcasts Who-Is and listens for I-Am answers, each device appearing the moment it replies. Returns the address, port and device instance, and no tags. | Nothing; the network to scan, in the driver page's Scan scope card, is optional: empty, the Who-Is goes out on every network of this computer. |
| Redfish | Reads the service address it is given and walks its first system, manager and chassis. Returns the service and its points. | The Scan scope card. |
| AVEVA PI | Walks the AF element it is given and everything under it. Returns the service and one point per attribute. | The Scan scope card. |
| OCPP | Lists the charge points currently connected to this station. | Nothing. |
| Matter | Lists the nodes already commissioned into this station's Fabric, each with the values it publishes. | Nothing. |
| MQTT | Listens on one broker for a while: every Sparkplug B edge node and device that announces itself, with its metrics as tags, and the plain topics heard under a filter, as tags of one device. See MQTT. | A broker whose host is stored, and the listening time and topic filter of its Discover devices card. |
| Omron | With a PLC address, asks that PLC to identify itself over FINS; in every case broadcasts the EtherNet/IP identity request for NJ, NX and NY controllers. Returns the endpoints and no tags. See Omron. | Nothing; the PLC address for a FINS probe, in the driver page's Scan scope card, is optional. |
| Siemens S7 | Asks one CPU, read by name over S7CommPlus, for its variables: those the CPU marks accessible and visible from HMI, offered as a tree by the path of each name (data block, struct or UDT, array), a branch's tick reaching everything under it, each variable under the shortest tail of its name that no other variable shares, and a DTL as one tag. Returns the CPU as a device read by name. See Siemens S7. | The driver page's Scan scope card: a Siemens device read by name, scanned at its host and signed in with its password, or a CPU's address typed. A typed CPU that a device of this station already reads by name is signed in to with that device's password. |
| SCPI instruments | Asks every instrument resource VISA lists (USB, GPIB, network; its serial ports left out) to identify itself with *IDN? and, with an address, asks that host the same over TCP. Returns the endpoints and no tags. See SCPI instruments. |
Nothing; the instrument address for a TCP probe, in the driver page's Scan scope card, is optional. Without VISA on this computer, only that address is asked. |
| NI-DAQmx | Lists every device NI MAX knows, its simulated devices included, each with its physical channels as tags at their measurement's defaults; nothing is sent to the hardware. See NI-DAQmx. | Nothing but NI-DAQmx installed on this computer; without it the scan lists nothing and says why. |
| SNMP | Walks one agent's standard subtrees (system, interfaces, UPS and sensors, host resources on request) and one more subtree named; returns the agent with the objects found as tags, those the driver knows by name under their name and the others by number. See SNMP. | The driver page's Scan scope card: a device of the driver, or an address typed with an SNMPv1 or SNMPv2c community. An SNMPv3 agent is scanned through its device. |
| File | Reads one file (an inbox folder's newest, which it does not move) and returns it with one tag per column (CSV) or per value (JSON, XML), or its last line (free text), and the facts of the file, every one read only. See File. | The driver page's Scan scope card: a device of the driver, or a folder, a file and a format typed, every text setting read off the file. |
| Database | Signs in to a configured device's database and returns that device with one tag per column of its tables and views, at the most recent row or at the row of the smallest key, every one read only. See Database. | The driver page's Scan scope card: a device of the driver, and optionally the tables, by a name or a pattern. |
Beckhoff ADS, Mitsubishi MC, LoRaWAN, HTTP and Generic serial and TCP have no scan and show no button. The button appears only once the Connector is running, because it is the Connector's driver registry that answers whether a scan can run, and it appears only for the drivers this version installs: if the registry answers with an assembly the application does not recognize, the button stays away and the Events page records that the installed driver is not the one this version ships.
Modbus TCP: the Scan scope card
The card appears on the Modbus TCP driver's page: "Read-only device identification; registers are configured after Add."
| Field | Values / default | Effect |
|---|---|---|
| IPv4 host or CIDR | One address, or a CIDR from /24 to /32; the app never infers the local subnet. | Every host address of the range, the network and broadcast addresses excluded. |
| Port | 1 to 65535; 502. | The port every host is dialed on. |
| Unit IDs | Values, comma-separated lists or ascending ranges, 0 to 255 ("1, 3, 8-16"); "1". | Each host is asked for each id. |
| Framing | MBAP, RTU; MBAP. | The frame every probe is sent in. A serial-to-Ethernet converter in transparent mode answers only RTU frames, so scan it in RTU; an answer counts there only when its unit ID matches and its CRC holds. A unit found keeps the framing of the scan when you add it. |
| Minimum transaction interval (ms) | 0 to 1000; 0. | Silence between completed probes on the same host; hosts are paced independently. Scan-local: it is not written into the devices you add. |
The line under the fields is the budget: "2 hosts × 3 unit IDs = 6 probes · limit 256", with "· 100 ms silence per host." when set. A scan may send at most 256 probes; over the budget the line turns red ("This scan would send 512 probes; reduce the network or unit-id range to 256 or fewer.") and Discover greys. Bad input is named the same way ("'10.0.0' is not a valid four-octet IPv4 address.", "The CIDR prefix must be between /24 and /32.", "Enter at least one unit id (0-255).", "Unit-id range '9-3' must be ascending."). Changing any scope field discards the results of the previous scan, because they described a different scope. At most four hosts are scanned at once, one connection per host.
Modbus RTU
The scan is on the line's page, not the driver's: Unit ID start and Unit ID end (1 to 247, ascending, 1 to 32 by default) and their own Discover button, with an estimate of the worst case ("32 probes · up to ~32.1 s, including 4.011 ms silence before each probe."). The scan opens the port once with the line's saved settings, probes each unit in turn, and refuses an active line rather than interrupting it: "This line is in use. Disable it before discovery; Ganter Lab will not interrupt or re-enable the bus automatically." A pending edit on the line is saved before the scan starts; if it cannot be, the scan does not start ("Discovery was not started because the serial-line edit could not be saved."). The Serial lines page covers the rest of that card.
Redfish and AVEVA PI: the service the scan reads
Neither a Redfish service nor a PI System announces itself on a network this station can listen to, so those two scans read the one service you point them at, in the driver page's Scan scope card. Redfish takes the service address (https://bmc-host, or https://bmc-host:8443 where it answers elsewhere) and always reads it over HTTPS, because the device's credentials ride on every request; an address that asks for the clear transport is refused where it is typed. AVEVA PI takes the service address and, after a #, the AF element the walk starts from: https://pi-host/piwebapi#\\AF-SRV\Plant\Line 3. Without that element there is nothing to walk, so Discover greys and says what is expected.
Both scans read the service without credentials, because they run before the device that would hold them exists. A service that authenticates every request therefore answers nothing and the scan finds nothing: add that service by hand. A Redfish device then finds its points with Discover tags on its own page, which signs in as the device does; an AVEVA PI device's points are added by hand.
Running a scan
While the scan runs the driver's page prints a status line and the bar's Discover turns into Cancel. The status comes from two independent stages, endpoint discovery and channel browsing: "Scanning endpoints…", "Inspecting endpoint 2…", "Reading channels from opc.tcp://plc:4840…", then "Found 3 devices."; a driver that runs a scan of its own reports how far it has gone and the page counts, "Discovery progress: 1 of 2…", while the two Modbus scans write the whole line, because the port, the host and the unit id are what somebody following one reads: "Scanning COM7 · 32 probes…", "Probing unit 5 (5 of 32)…", "Probed 5 of 32; checked unit 5.", "Completed 32 probes." on a serial line, and "Scanning 2 hosts × 3 unit IDs…", "Probing 192.168.0.10:502 · unit 3…", "Skipped unreachable host 192.168.0.11:502." on a network; the Rockwell scan names the networks its broadcast went out on, "Searching for Rockwell controllers on 192.168.0.255, 10.0.0.255…", so a result of zero says where the question went. A scan that stops on a driver error keeps what it found and says so: "The scan stopped with an error after finding 1 device. The list may be incomplete." An endpoint whose channels could not be read is still listed, with zero tags.
The scan owns the driver while it runs: you cannot select another node ("Cancel discovery before leaving this driver."), add a device or a line, enable or disable lines, or use row actions until it ends. Results belong to the window that started the scan: another browser tab on the same station does not see them.
Cancelling
Cancel ("Canceling…" once pressed) stops both stages. Candidates fully prepared before the cancel stay listed; the endpoint whose channels were still being read is discarded. The status reads "Discovery canceled." and the feed "Discovery canceled for OPC UA; 2 completed results retained." The scan stays occupied until the driver's temporary socket, client or session has closed; after two seconds the status says "Waiting for the driver to release its discovery resources…" rather than pretending the scan already stopped, because a driver does not always let go the instant it is asked to.
The results
The Discovered devices card (on a line, Discovered units) lists one card per candidate: an editable name, the endpoint, and "2 of 5 tags selected". Under it a compact grid of the candidate tags with an Add tick (on by default), Tag, Type and Access; with none, "No tags reported. Add the device to configure tags in its editor." Where the driver names a tag shorter than the place it found the point at, the Tag cell shows that place on a second line under the name: on OPC UA, the node's whole browse path (see OPC UA). Nothing is persisted until you press Add device on a card ("Adding…" while it runs): the device is created under a name unique on the driver with exactly the ticked tags, the card leaves the list, the new device is marked in the Devices table of the page the scan ran on, which stays on screen, and the feed reads "Added 'Pump' with 3 tags." Discovered tags arrive read-only or writable as the driver reported them, with their type, and with the default pipeline; nothing else is inferred.
A candidate that matches a device you already have is marked Already configured and offers Open instead of Add, so a scan never creates an accidental duplicate. Only stable identities are matched: a Modbus RTU unit on the same line, a Sparkplug B edge node or device on the same broker, a SCPI instrument under the same VISA resource, an NI-DAQmx device under the same name of NI MAX, an SNMP agent scanned through its device or at the same host and port, a file read from the same folder, under the same name and in the same way by a File device, a database scanned through its own Database device, a Siemens CPU at the same host as a device that reads it by name, and a Matter node id. Other drivers match nothing, because a reachable endpoint is not proof that it is the same equipment. A configured Matter device, SNMP agent, File device, Database device or Siemens device read by name still takes something: its card lists the values the device publishes and has no tag for yet, ticked, and Add tags, before Open, adds the ticked ones to that device (see Matter, SNMP, File, Database and Siemens S7).
Dismiss clears the list, and waits for the scan: while one is running it is greyed, because clearing the list mid-scan also cancels it and throws away everything that had already answered. Selecting another driver, or changing the scope, clears it too. While a scan runs, deleting a device or a tag and moving a device into a folder grey with the same reason: the scan holds the driver, and the command would have failed after you confirmed it. On Modbus RTU the unit id is a column of its own, and an id already configured on the line is refused when added: "Unit 5 is already configured on 'Line 1'."
Discovering a device's tags
A device you already have reads more of its points without going back to its driver's page: the head of its Tags card carries Discover tags beside Add tag, wherever its driver can read one device's points. It scans that device alone, as it is saved (an edit still waiting on its save is saved first), and lists only the values it publishes that it has no tag for yet, compared by the point each one reads and never by name: a value the device already reads under another name is not offered again.
| Driver | How the device is read |
|---|---|
| OPC DA, NI-DAQmx, OCPP, a Simulated device added from the catalogue | The driver browses the device's own address, as its scan browses each endpoint it finds. |
| OPC UA, Redfish | The same browse, signed in as the device is, so a server or a service that answers only a signed-in client lists its points too. |
| Rockwell EtherNet/IP | The controller's tag list, on a Logix or Micro800 controller. A PLC-5, SLC 500 or MicroLogix publishes none, and its page shows no Discover tags. |
| Matter | The values its commissioned node publishes. |
| SNMP | A walk of its agent with its own settings and credentials, over the standard subtrees and the vendor branch its tags already read. |
| File, Database | The driver's scan through the device, as the Scan scope card scans a device of the driver. |
| MQTT | A listen on its broker for 10 s: a Sparkplug B device's own edge node, which is asked for its birth while no other edge node is asked anything; a plain device's topics under the levels its tags share, and every topic on the broker when they share none. |
| Siemens S7 | The variables of its CPU, on a device read by name, signed in as the device is, as the same tree as the driver's scan. A device read by address publishes no names, and its page shows no Discover tags. |
AVEVA PI shows no Discover tags: its walk starts from an AF element, which a device does not hold, so its points come from the driver's Discover or are added by hand. Modbus, BACnet, Omron, SCPI and the drivers that have no scan find no points and show none either.
While the scan runs, Discover tags turns into Cancel, a status line stands above the Tags card, and the scan holds the driver exactly as the driver's own Discover does: the verbs that need the driver stay drawn, greyed, and say why. Discover tags is greyed itself while the station takes no changes, while another scan or a pairing holds the driver ("A discovery scan is running on this driver. Wait for it to finish."), and while the device still waits for its address or has a field its save refuses. It needs Configure connector: a role without the bit is not drawn the button.
What the scan found appears on a Discovered tags card right above the Tags card, every value ticked, with Tag, Type and Access and, under a name, the longer place the driver found the point at, as on the driver page's cards. Add tags, on the card's head, adds the ticked values to the device, each once, numbered where a tag of the device already has its name, and saves it; the new tags are marked in the Tags card's table, which stays on screen, and the feed reads "Added 2 tags to 'Line PLC'." What is left stays offered, and Dismiss clears the card. A device that already has a tag for every value it publishes is told so ("'Line PLC' already has a tag for every value it publishes."), and one the scan read nothing from too ("The scan found no values on 'Line PLC'. Check that it answers, then run Discover tags again."). Leaving the driver clears the card, as it clears the driver's results.
The driver's own Discover keeps finding the devices you do not have yet, and its Discovered devices card is unchanged.
Pairing a Matter device
Matter commissions the physical device over Bluetooth before it exists here, so the Matter driver's first verb is Pair device, not Add device, and it opens a form on the driver's page (the New… menu and the driver's right-click menu offer the same). Pairing needs Configure connector, a usable Bluetooth LE radio on this computer, and the network the device will join, registered first on the driver's Networks card: a Wi-Fi name and its password, or a Thread network and its dataset (see Networks). Until one network there is usable, Pair device stays greyed with the tooltip "Add the network the device will join first." The form says: "Put the physical device in pairing mode before continuing. Pairing uses Bluetooth on this computer."
| Field | What it is |
|---|---|
| Device name | The editable name the device will have in the Connector; "Matter device" by default, with "Kitchen light" as the placeholder. |
| Matter setup code | The official 11- or 21-digit manual code printed on the device, or the complete QR payload beginning with MT:. Hidden as typed; Show setup code reveals it. |
| Network | The network the device will join, one of the usable networks of the Networks card. With one, the form names it in a line with its kind and there is nothing to choose; with several, it is a picker. Under it: "The device says whether it joins by Wi-Fi or Thread. A network of the other kind is refused before anything is written to the device." |
| Destination folder | Only when a folder's New device opened the form (on the folder's Devices table, its right-click menu, or New… > Matter > <Folder> > New device): the folder the paired device is filed in, with "The paired device is filed in the folder this pairing was opened from." under it. Opened by Pair device, the form has no such line and the device lands at the driver's own level. |
Pair device is enabled once the name and the setup code are filled, a network is usable and the station accepts mutations. The form then walks five steps, Validate, Find, Pair, Join the network and Save, with a status line under them: "Validating the setup code and the network…", "Searching for the device over Bluetooth…", "Authenticating and pairing the device…", then for a Wi-Fi network "Sending the Wi-Fi network's name and password to the device…" and "Waiting for the device to join the Wi-Fi network…" (for a Thread network, "Sending the existing Thread network configuration…" and "Waiting for the device to join the Thread network…"), "Saving the commissioned node in the local Fabric…", "Pairing complete." Cancel is accepted only until the matching advertisement is selected ("Stop before the device is changed"); from then on the button reads "Finishing safely…", because the device has been changed and the station must record the node even if you leave. Close dismisses the form while nothing runs.
On success the device is created with the node id as its identity and the name of the network it joined in its read-only Network field, and the feed reads "Paired Matter device 'Kitchen light'." The page then opens on the Matter driver, with the new device marked in its Devices table, and scans that one device: its card lists the values it publishes, ticked, beside Add tags, and the scan closes with "Tick the values of 'Kitchen light' to create as tags, then Add tags." What the device offers, and what each value does, is on Matter. The setup code is never stored, logged or shown again; the network's password or dataset stays on the Networks card, stored encrypted for this Windows user, and never reaches the device, its address or the journal. If the node was commissioned but its device could not be created, the feed says so and Discover is the recovery path. Failures are said plainly and the form stays open for a retry: an invalid code, a network whose name, password or dataset is not valid, no usable Bluetooth adapter, Bluetooth denied or turned off, no matching device ("Put it in pairing mode, keep it nearby and try again."), a rejected setup code, a device that joins by the other kind of network or by cable (nothing is written to it), a device that answered that it could not join the network (a Wi-Fi name it did not find, a refused password or another refusal: it keeps nothing and is back in pairing mode, so correct the network and pair again), a device that gave no answer and never appeared on the local network (its node stays in the Fabric and can be recovered with Discover), a Fabric that could not be saved (when the device was already commissioned: "Do not reset the device until the Fabric storage problem is resolved."), or another pairing already running. What each failure leaves on the device is on When pairing fails. One pairing runs at a time; while it runs you cannot leave the driver ("Wait for Matter pairing to finish before leaving this driver.").
What discovery does not do
A scan never persists anything by itself, never changes an existing device, and never re-runs on its own. It does not infer subnets, register maps or serial settings, does not enable or disable a line or a broker, and does not remove dismissed candidates from the equipment. It is refused for a driver the package does not carry. What each driver's results contain is on that driver's page under Drivers.