# Devices

> The device page: its header and verbs, the Device card, the Connection card with the fields each driver shows, credentials and certificates, the Tags grid with mass edit, copying a device, and how duplicates and name collisions are handled.

A **device** is one piece of equipment the station talks to over a driver: how it is reached, and the tags read from it. Select a device row in the Communication column, or press Open on a device row of a driver's, line's, broker's or folder's table, to open its page. View connector reads it; Configure connector edits it. Serial lines have their own page, [Serial lines](connector-lines), and MQTT brokers are described on [MQTT](driver-mqtt#the-broker).

## Creating a device {#creating-a-device}

| Gesture | Result |
| --- | --- |
| **New…** > `<Driver>` > **New device** in the column footer | A device at the driver's own level, under every driver whose devices hang straight under it. |
| **Add device** on the Devices table of a driver's page | The same. |
| **New device** on a folder's Devices table or its right-click menu, or **New…** > `<Driver>` > `<Folder>` > **New device** | A device filed in that folder; under Matter, the pairing form opens and the paired node is filed in that folder. |
| **Add device** on a serial line's Devices card or right-click menu, or **New…** > `<Driver>` > `<Line>` > **New device** | A Modbus RTU device on that line, under the first free unit id, or on a line of the generic serial and TCP driver or of the SCPI driver a device of that driver on the line. On a line of the Omron driver, a PLC on the line under the first unit number free from 0 to 31. |
| **Add device** on a broker's Devices card or right-click menu, or **New…** > MQTT > `<Broker>` > **New device** | An MQTT device on that broker, in Plain MQTT. |
| **Add device** on a discovery result | A device with the endpoint the scan found and the tags you ticked; see [Discovery](connector-discovery). |
| **Pair device** on the Matter driver's bar, or **New…** > Matter > **Pair device** | A commissioned Matter node at the driver's own level; see [Discovery](connector-discovery#pairing-a-matter-device). |
| **Copy device** on a device | A copy of the selected device, tags included. |

A new device is named "New device" (then "New device 2", and so on), enabled, with a 1000 ms poll interval, unit id 1 and the port its driver uses (see the Connection card below; a device of the generic serial and TCP driver starts with none), and it is not opened: it appears marked, scrolled into view, in the Devices table of the page that lists it (the driver's, the folder's, the line's or the broker's), and the feed reads "Added device 'New device'. Open it to edit its details." From that table the screen stays where it is; from New… or a right-click it goes to that page. The row's **Open**, or its row in the tree, opens the device. A device is refused under a driver the package does not carry, and under Matter, where a device only comes from pairing or discovery ("Use Pair device to add a new Matter node, or Discover to add one already commissioned."). Every one of these gestures stands under a driver already added; adding one is described on [The drivers list and a driver's page](connector-drivers#row-actions).

A device whose driver reaches its equipment at a host (every driver with a **Host** field) starts with that host empty, and the station does not try to connect it until the host is entered: its dot stays grey, the row and the page say "Host not entered yet", its tags read as gaps, and no connection error can appear before there is an address to try. It is never pointed at this computer in the meantime; for equipment that really is on this computer, enter `localhost`. An NI-DAQmx device has no host: it waits the same way for its **Device name**, and reads "NI-DAQmx device not entered yet" until it has one (see [NI-DAQmx](driver-ni-daqmx#the-ni-daqmx-device-card)). A Fluke NetDAQ device waits for its host, and then for the **Base channel** of its instrument, reading "Base channel not entered yet" until it has one (see [Fluke NetDAQ](driver-fluke-netdaq#device)). A File device waits for its **Folder path**, and reads "Folder not entered yet" until it has one (see [File](driver-file#device)). A Database device waits for where its database is (its server and database name, its file or its data source), and reads "Server not entered yet" until it has a server (see [Database](driver-database#the-database-card)). A LoRaWAN device waits for its **DevEUI** (a sensor) or its **Station EUI** (a concentrator), and reads "DevEUI not entered yet" or "Station EUI not entered yet" until it has one (see [LoRaWAN](driver-lorawan#connection-fields)); an identifier that is written and is not 16 hexadecimal digits is not waited for but refused.

Once it has a host, connection is never a blocking step: the Connector onboards the device and connects in a background retry loop, so an unreachable device costs nothing. Its tags read as gaps until the connection lands, and the page shows the last connection error meanwhile.

## The header {#the-header}

The name, the line "One piece of equipment this station talks to: how it is reached, and the tags read from it." and a pill with the **Base URI**, the exact address the Connector connects to, assembled live from the Connection card (for example `modbus+tcp://192.168.0.10:502/1`, `opc.tcp://plc:4840`, `simulated://CompressedAir`). A device with no host yet has no Base URI, so the pill is absent until the host is entered. It is absent as well while the fields make no address the driver takes, for example on a Modbus RTU device whose line is missing, or whose line holds a value its page has not saved. Under it, one of six notices:

- **Driver not included in this package**: "This device needs the … driver, which this installation does not include, so it stays offline. Its settings are kept and it can be deleted; nothing else here changes what it reads." The dots stand for the driver's name.
- **VISA is not installed on this computer** (SCPI instruments, a device reached through VISA): "This device reaches its instrument through VISA, which this computer does not have, so it stays offline. Install NI-VISA or the Keysight IO Libraries Suite and the device connects. An instrument with a network port can also be reached over TCP." See [SCPI instruments](driver-scpi#visa-on-this-computer).
- **NI-DAQmx is not installed on this computer** (NI-DAQmx, on a computer without it): "This device is read through NI-DAQmx, which this computer does not have, so it stays offline. Ganter Lab does not include NI-DAQmx: install it, free from ni.com, and the device connects with the configuration it has." See [NI-DAQmx](driver-ni-daqmx#ni-daqmx-on-this-computer).
- **Waiting for certificate approval** (OPC UA, Redfish, AVEVA PI, HTTP over HTTPS, MQTT over TLS): "This equipment presented a certificate this station has never approved, so nothing is read from it yet. Check the fingerprint with whoever commissioned the equipment, then approve it under Equipment access on the OPC UA driver's page.", with the device's own driver named, or for an MQTT device "This device's broker presented a certificate this station has never approved, so nothing is read from this device yet. Check the fingerprint with whoever manages the broker, then approve it under Equipment access on the MQTT driver's page.", with a **Review certificate** button that opens Equipment access on the driver's page on that certificate ([OPC UA](driver-opc-ua#equipment-access), [Redfish](driver-redfish#equipment-access), [AVEVA PI](driver-aveva-pi#equipment-access), [HTTP](driver-http#equipment-access), [MQTT](driver-mqtt#equipment-access)).
- **Host not entered yet**, a neutral notice on an enabled device whose host is still empty: "The station does not try to reach this device until it has a host, so nothing is read from it yet and there is no error to show. Enter the host in the Connection card below and the station connects to it." An NI-DAQmx device without its device name reads **NI-DAQmx device not entered yet** instead: "The station does not try to reach this device until it has the name of an NI-DAQmx device, so nothing is read from it yet and there is no error to show. Enter the name NI MAX gives the device in the NI-DAQmx device card below and the station connects to it." A File device without its folder reads **Folder not entered yet**: "The station does not read this device until it has a folder, so nothing is read from it yet and there is no error to show. Enter the folder in the Folder and file card below and the station starts reading it." A Database device that does not say where its database is reads **Server not entered yet**, **Database name not entered yet**, **Database file not entered yet** or **Data source not entered yet**, by what it still lacks: "The station does not reach this device until it says where its database is, so nothing is read from it yet and there is no error to show. Enter it in the Database card below (the server and the database name, the file or the data source) and the station connects to it."
- Otherwise, on a device that goes through a serial line or a broker with an error, a neutral notice that points there, "This device goes through serial line Bench bus, which has an error. The line's page says why.", or else the device's own error in red, when there is one (see [Enabling and health](connector-health#last-error)).

Under them, the device names its tags that have an error of their own, after the same red marker the tree shows: "3 tags with errors: C3, Opt_Int, T5", the rest counted past three names. The reason of each stays on the tag. While the device is not connected it names none: its own error says why.

## The command bar {#the-command-bar}

| Command | What it does | Greyed when (situation) | Not drawn when (role) |
| --- | --- | --- | --- |
| **Reconnect** | Closes this device's connection and opens it again, touching no other device. The feed waits for the driver and then says what happened: "Reconnected 'Furnace'.", or "Couldn't reconnect 'Furnace':" with the cause. Nothing is reloaded, and a device that only answers later still comes back on its own. | A scan or a pairing is running, a run holds the station, the runtime is stopped, or the device is still waiting for its address. Its tooltip then says what its driver is missing, in the words of the device's own row: "Host not entered yet, so there is no connection to reopen." for a driver that dials a host, and the same sentence opened by "NI-DAQmx device not entered yet" on NI-DAQmx, by "Folder not entered yet" and then "File name not entered yet" on File, and by "Server not entered yet", "Database name not entered yet", "Database file not entered yet" or "Data source not entered yet" on Database, and by "DevEUI not entered yet" or "Station EUI not entered yet" on LoRaWAN. | Without Configure connector. |
| **Enable** | Lets the device take part in acquisition. | Already enabled, or the station refuses mutations. | Without Configure connector. |
| **Disable** | Stops all communication with the device and withdraws its tags from the live address space; every tag keeps its own Enabled switch. | Already disabled, or the station refuses mutations. | Without Configure connector. |
| **Copy device** | Creates a copy, marked in the table of the page that lists it (below). | The package does not carry the driver ("Driver not included in this package."), or the station refuses mutations. | Without Configure connector. |
| **Delete device** (danger ink, on the right) | Asks "Delete 'Furnace'? This also deletes all its tags. This cannot be undone.", then deletes and selects the parent, open in the tree with its table in view (the line, the broker, the folder it was filed in, or the driver). | The station refuses mutations. | Without Configure connector. |

The right-click menu adds **Add tag** and **Move to** (see [Device folders](connector-folders#moving-a-device)).

## The Device card {#the-device-card}

| Field | What it is | Values / default | Effect |
| --- | --- | --- | --- |
| **Name** | The friendly name; the last segment of the device's wire identity and address. | Required; unique within the driver, case-insensitively. | Typing previews what the rename carries ("Checking references…", then how many references follow, or "The effective address does not change; no references need updating."); Enter or leaving the field commits, and every reference to the old addresses is rewritten in the same operation: "Device renamed and 3 references updated." A blank name is refused: "Device name is required." |
| **Driver** | The protocol the device speaks. | Read-only. | Fixed at creation; see [Drivers](drivers). |
| **Poll interval (ms)** | How often the station reads the device's tags, unless a tag overrides it. | 1000; a value of zero or less is saved as 1000. | Hidden for drivers that poll at a fixed 1 s or receive pushed data (Mitsubishi MC, BACnet, OCPP, LoRaWAN, MQTT). |

## The Connection card {#the-connection-card}

The card appears for every driver that declares connection fields and shows only the fields that driver reads. Each driver's page explains its fields in depth; this is the full inventory as the panel draws it.

| Field | Shown for | What it is |
| --- | --- | --- |
| **Host** | Modbus TCP, OPC UA, Siemens S7, Rockwell, Omron, Beckhoff, Mitsubishi, BACnet, Redfish, AVEVA PI, HTTP, Generic serial and TCP (TCP client), SCPI instruments (TCP), SNMP | Host name or IP address. While it is blank the device is not connected at all (see [Creating a device](#creating-a-device)); write `localhost` for equipment on this computer. An IPv6 literal is bracketed for you in the Base URI. A whole address can be pasted: the driver's own scheme (`opc.tcp://`, `modbus+tcp://` and the like) is dropped, a port after the host goes to the port field and a path to the resource path. What the device has no field for (another protocol's scheme, a path or a port the driver does not keep, an IPv6 address after a scheme without brackets) is refused with the reason under the box, and the box goes back to the host in force. So is a host that cannot be a name: one of its dot-separated parts empty (`plc..local`), longer than 63 characters, or starting or ending with a hyphen. |
| **Port** | Modbus TCP, OPC UA, Beckhoff, Mitsubishi, Omron (FINS), BACnet, Redfish, AVEVA PI, HTTP, Generic serial and TCP (TCP client), SCPI instruments (TCP), SNMP | TCP port, 1 to 65535, or the UDP port an SNMP agent answers on. A new device starts on the port its driver uses (502, 4840, 851, 5007, 5025, 9600, 47808, 443, 161). An empty box shows that port in grey and the device is dialed on it: a device saved with 0 reads that way, and emptying the box goes back to it. AVEVA PI and HTTP start empty, because their port follows the chosen transport: 443 over HTTPS, 80 in the clear, and the grey port changes with the transport. Generic serial and TCP starts empty too, with no grey port: no port is standard for such equipment, and the device is not connected until it has one. |
| **Unit ID** | Modbus TCP, Modbus RTU | The Modbus unit id: 0 to 255 on TCP; 1 to 247 on a serial line, unique per line. On a serial line any other number is refused before it reaches the device: the feed says why ("Unit ID must be between 1 and 247.") and the box goes back to the unit id in force. |
| **Framing** | Modbus TCP | How each request travels on the connection: MBAP (Modbus TCP proper, the default) or RTU, the RTU frame with its CRC sent as it is, for a serial-to-Ethernet converter in transparent mode. The Base URI then carries `framing=rtu`. See [RTU over TCP](driver-modbus-tcp#rtu-over-tcp). |
| **Minimum transaction interval (ms)** | Modbus TCP | Silence after one completed attempt before the endpoint starts the next, 0 to 1000, default 0 ("Compatibility aid, 0-1000 ms. Zero adds no artificial delay."). Enabled devices sharing a host and port use the largest value among them, and the card says so when another device raises it: "Effective 200 ms · another enabled Device on 192.168.0.10:502 raises the endpoint maximum." |
| **Serial line · fixed** | Modbus RTU, Generic serial and TCP (a device on a line), SCPI instruments (a device on a line), Omron (a device on a line) | The line's name and its tuple, read-only; changed on the line's own page. "Missing line" or "No physical line assigned" means the device has lost its line and cannot be saved: "A serial line is required." |
| **Broker · fixed** | MQTT | The broker's name over its address, read-only; the connection and the sign-in are changed on the broker's own page. "Missing broker" means the device has lost its broker and cannot be saved: "An MQTT broker is required." |
| **Protocol** | MQTT, Omron | On MQTT, **Plain MQTT** or **Sparkplug B**: whether each tag names a topic or a metric. See [MQTT](driver-mqtt#device). On Omron, **FINS** or **NJ/NX tags by name**: whether each tag names a memory address or a variable, and whether the device has a port and a FINS card. See [Omron](driver-omron#connection). |
| **Group ID**, **Edge node ID**, **Device ID** | MQTT, Sparkplug B only | The edge node the device is, or the device behind it; an empty Device ID reads the edge node's own metrics. One Sparkplug B identity is configured once per broker. |
| **Rack / Slot** | Siemens S7 | Two numbers; the Base URI reads `s7://host:rack:slot`. |
| **Slot** | Rockwell EtherNet/IP | One number, the chassis position the controller is seated in; a CIP route carries no rack, and the Base URI reads `eip://host:slot`. |
| **Local IP (AMS)** | Beckhoff ADS | This station's IP on the AMS route; both AMS net ids are derived as `<ip>.1.1`. Blank uses this station's address on the network that reaches the PLC, shown in grey. |
| **PLC AMS Net Id** | Beckhoff ADS | The PLC's own AMS Net Id, for a PLC whose id is not its IP followed by `.1.1`. Blank uses the Host's IPv4 address followed by `.1.1` (a name resolved first), shown in grey. |
| **Device Id** | BACnet | The BACnet device instance. |
| **Server / Key** | LoRaWAN | The application key. |
| **Identifier** | OCPP, LoRaWAN | The charge point id, or the DevEUI (a spelling with colons or dashes is normalized to the bare hexadecimal). Blank falls back to the sanitized device name. |
| **Resource path** | OPC UA, AVEVA PI, HTTP | A path appended to the authority: the OPC UA server path, the PI Web API service root (default `piwebapi`), or the prefix every HTTP tag path is joined to. |
| **Transport** | AVEVA PI, HTTP, Generic serial and TCP, SCPI instruments | On a network device of the generic serial and TCP driver, a list: TCP client or UDP listener, which turns Host and Port into Accept from and Local port (see [Generic serial and TCP](driver-generic-serial-tcp#connection)). On a device of the SCPI driver that is not on a line, a list: TCP (LXI socket) or VISA (USB, GPIB, network), which turns Host and Port into the VISA resource (see [SCPI instruments](driver-scpi#connection)). On AVEVA PI and HTTP, the checkbox **Send over plain HTTP**. Off means HTTPS, with the note "HTTPS. The bearer token or password stays encrypted on the way to the PI Web API."; on, the note turns to a warning that the token or password is sent unencrypted on every request, for a PI Web API that answers on no other transport. An HTTP device carries the same checkbox with a note of its own, about the requests and any credential it sends, and there the checkbox is also what a host typed with `http://` or `https://` in front of it moves, the host being stored without it. |
| **VISA resource** | SCPI instruments (VISA) | The instrument's name as VISA lists it, such as `USB0::0x0957::0x1A07::MY12345678::INSTR`, in place of Host and Port. Discover fills it in. |
| **Username**, **Password** | OPC UA, Redfish, AVEVA PI | Per-device credentials; an empty username means an anonymous connection ("Empty = anonymous. Stored per device; the password is protected at rest."). |
| **Bearer token** | AVEVA PI | A token that wins over the username and password when set; **Show token** reveals it. |

A Matter device shows a different Connection card: **Node ID · read only**, the 64-bit node id the pairing assigned (or "Needs re-pairing" when the stored identity cannot be read), **Network · read only**, the name of the network the device joined when it was paired (a device paired before Ganter Lab recorded it, or added with Discover, says it was not recorded), and **State**, the device's health word. Nothing on it is editable. A Simulated device has no Connection card at all. A device of the generic serial and TCP driver carries two more cards under its Connection card, Messages and Checksum, which say how a message ends and how it is checked; see [Generic serial and TCP](driver-generic-serial-tcp#the-messages-card). An Omron device read over FINS carries a FINS card under its Connection card, with the transport, the network, the nodes, the unit and the response timeout; see [Omron](driver-omron#the-fins-card). A device of the SCPI driver carries an Instrument card under its Connection card, with the instrument's identity, the terminator, the response timeout, the write confirmation and the setup commands; see [SCPI instruments](driver-scpi#the-instrument-card). An NI-DAQmx device has no Connection card: the NI-DAQmx device card stands in its place, with the name NI MAX gives the device and the product NI-DAQmx reads from it; see [NI-DAQmx](driver-ni-daqmx#the-ni-daqmx-device-card). A device of the SNMP driver carries an SNMP agent card under its Connection card, with the version, the community or the SNMPv3 user with its security level, protocols and passwords, the response timeout and the retries; see [SNMP](driver-snmp#the-snmp-agent-card). A File device has no Connection card: the Folder and file card stands in its place, with the folder, the file and the format, followed by the Text of the file card and, on a device that reads one file, the Writing card; see [File](driver-file#the-folder-and-file-card). A Database device has no Connection card: the Database card stands in its place, with the database type and where the database is, followed by the Sign-in card on every database but SQLite; see [Database](driver-database#the-database-card).

### Credentials and certificates {#credentials-and-certificates}

Passwords, bearer tokens and SNMP communities are protected at rest with per-user Windows data protection, so the configuration database never holds the clear value. That protection is bound to the Windows account and machine that entered the secret: on another account the field comes back empty with the note "Cannot be read on this Windows account: it only opens on the machine and the Windows account that entered it. Enter it again here." Credentials are handed to the driver directly; they never appear in the Base URI or the journal, and they are redacted from the error messages the action feed shows.

An OPC UA device presents its equipment certificate before a session opens, and so does the equipment a Redfish, AVEVA PI or HTTP device reaches over HTTPS, or the broker of an MQTT device over TLS. One that Windows does not trust and this station has never approved does not fail silently: the device reads "Waiting for certificate approval" in the tree and on the page, and the banner's button opens Equipment access on its driver's page on the certificate to approve or block it. Revoking an approval later closes the connections running on it. Details are on each driver's page: [OPC UA](driver-opc-ua#equipment-access), [Redfish](driver-redfish#equipment-access), [AVEVA PI](driver-aveva-pi#equipment-access), [HTTP](driver-http#equipment-access) and [MQTT](driver-mqtt#equipment-access).

## The Commands card {#the-commands-card}

Three drivers reach equipment that is asked to do things as well as read: **HTTP**, **Redfish** and **AVEVA PI**. Their device page carries a **Commands** card between the Connection and Tags cards, headed "What this equipment can be asked to do. Each command names the path the request is sent to, under the device address." Everyone sees the list; declaring, editing and issuing need Configure connector, and a role without the bit is drawn neither the fields nor the verbs.

**Add command** adds a row named "Command 1" (numbered after what is already there). Each row carries:

| Column | What it is |
| --- | --- |
| **Name** | What the command is called. It is also the method name on the device in this station's own OPC UA address space, so it is unique within the device. |
| **Path** | Where the request goes, under the device's own address: the path the equipment's documentation names, for example `redfish/v1/Systems/1/Actions/ComputerSystem.Reset`. A command with no path is never put on the device. |
| **Takes** | The name of the one value the command takes, as the equipment names it (`ResetType`), or empty for a command that takes nothing. |
| **On** | Whether the command is offered at all. An off command is neither created on the device nor issued, which is how one is parked without losing what it addresses. |
| **Value** | What this press sends, for a command that takes a value. It belongs to the press, not to the device, so it is never saved. |

The trailing cluster carries the two verbs that act on that row alone: **Run**, which sends it and reports what the equipment answered ("'Reset' answered: accepted"), and **Delete**. Run says why it is refused rather than vanishing: a command with no path ("This command has no path yet, so there is nothing to send."), one that is off, one still waiting to be saved into the runtime, a device that is not connected, and the station's own engineering or run boundary. Other drivers do not carry the card at all: a charge point takes commands too, but its commands are fixed by the protocol and come from the driver, not from what you type here, and a Matter node takes none, because every change to it is a write to one of its tags.

Issuing is a write to the equipment, so Run takes the same funnel the manual tag write takes: the command waits its turn behind whatever the station is already doing, it reaches the equipment by the same path a call from an outside system takes, and the press is recorded with what was asked, of which device, and what came back. While the station has stopped taking work the press is answered rather than going quiet: "The station is not taking commands right now." A Connector that is not running reads "The Connector is not running, so nothing can be issued to the equipment.", and a refusal from the equipment itself is passed on in its own words. A command the Connector could not carry out says what it met in the station's language, as a device's red line says it: "The device is not connected, so nothing was sent to it." for a device that dropped, the device not answering in time, a request the network refused or the driver failing; the journal keeps the technical line.

## The Tags card {#the-tags-card}

The card is headed **Tags**, then "Address format · `<hint>`" saying how this driver addresses a tag ("Free-form tag name (e.g. sim/temperature).", "Register number + quantity (typed fields).", "Node id, e.g. ns=2;s=Temperature."), and for Configure connector the instruction "Tick rows, then edit a cell to apply it to all of them. The ticks clear once it is applied." and the **Add tag** button. Add tag creates "Tag 5" (numbered after the count) as Float, or the driver's first supported type, Read only. The tag is not opened: it appears marked in the grid, inside its type's group and scrolled into view, where its fields are edited in the row, and its **Open** leads to its page. The feed reads "Added tag to 'Furnace'." or, when the new tag still needs something, "Added tag to 'Furnace'. Fill in its details in its row." In the column's New… menu, a device's entry offers **New tag**, and the device's right-click menu **Add tag**: both bring the screen to the device's page and do the same. Beside the Add tag button, where the device's driver can read one device's points, **Discover tags** scans the device for the values it publishes and offers those it has no tag for yet (see [Discovering a device's tags](connector-discovery#discovering-a-devices-tags)).

### The grid {#the-grid}

Rows are grouped by data type, in this order: **Numeric**, **Boolean**, **Text & other**, each group headed with its count. The columns follow the tag page's card order; a cell that does not apply to a row (a numeric field on a Boolean tag) is drawn empty and disabled.

| Column | Group | What it edits |
| --- | --- | --- |
| tick | | Selects the row for a mass edit. Drawn for Configure connector only. |
| **Name** | General | The tag's name, with the same rename preview and reference rewrite as the page. Never replicated. A tag with an error of its own carries the tree's red marker after the name, with the reason as its tooltip. |
| **Type** | General | The data type; changing it snaps the row's signal kind, Modbus register class, limit action and NaN policy as described on [Tags](connector-tags#the-general-card). |
| **Access** | General | Read only, Write only, Read and write (Read only alone for OCPP and LoRaWAN). |
| **Unit** | General | The engineering unit. |
| **Poll (ms)** | General | The per-tag override; 0 means the device default. Hidden for fixed-rate and push drivers. |
| **Address** | Source | The free-text address, for the drivers that take one. Never replicated. |
| **Signal** | Source | The simulated signal kind, with a picture of the shape beside each name. Simulated devices only. |
| **Raw** | Source | The latest raw reading, read-only. |
| **Scale ×**, **Scale +**, **Scaled** | Conversion | The Scale stage's factor and offset, and its result. |
| **Cal on**, **Cal ×**, **Cal +**, **Calibrated** | Conversion | The Calibration stage: its switch, its factor and offset, and its result. |
| **Limits on**, **Min**, **Max**, **Limit**, **Limited** | Conversion | The Limits stage: its switch, its bounds, its action, and its result. |
| **Dec on**, **Dec** | Conversion | The Decimals stage: its switch, and its places, 0 to 15. |
| **Invert** | Conversion | The Boolean negation. |
| **Sub start**, **Sub len** | Conversion | The String substring window. |
| **Value** | Live value | The engineering value, read-only. |
| actions | | **Open**; then for Configure connector **Enable**, **Disable** and **Delete**, the last with a confirmation. |

The three stage switches are columns like the fields they govern, and they mass-edit with them: ticking rows, typing the coefficients and turning the stage on changes what those rows read in the same edit, without opening each point. What the grid still does not carry are the invalid-reading policies, the two-point assistants, the write field and the cross-references: those are on the tag page. A Calibrate-only role reads the grid but edits nothing in it, the Cal cells and the Cal on switch included; its calibration edits go through the tag page.

### Mass edit {#mass-edit}

Tick the rows to change, then edit a cell of any row: the new value is applied to that row and to every ticked row, and the ticks are spent. While rows are ticked a strip above the grid says "3 rows selected. Editing a cell applies it to all of them and clears the ticks." with a **Clear selection** button. The ticks belong to the device: coming back to it later finds them cleared. Three rules keep a mixed selection honest: Name and Address never replicate; the Type cell snaps each row's dependent fields as it lands; and a value a row cannot take is refused for that row and kept as it was, which is how a String row survives being handed a numeric signal kind, and an integer row a NaN limit action.

## Copy device {#copy-device}

Copy device creates a device of your own from the selected one: the same connection fields and credentials, every tag cloned under a fresh identity with its whole pipeline, its enabled state and poll interval. The copy takes the source's name while it is free on the driver, then "Furnace (2)", "Furnace (3)", and lands at the driver's own level whatever folder the source was in; a Modbus RTU copy stays on the same line under the next free unit id, a copy on a line of the generic serial and TCP driver or of the SCPI driver stays on that line, and an MQTT copy on the same broker, a Sparkplug B one with its innermost ID numbered the same way ("Press1 (2)") so that no two devices on the broker name one identity. The copy is not opened: the screen goes to the page that lists it (the driver, the line or the broker), with the copy marked in its Devices table and scrolled into view, the original beside it: "Copied 'Furnace' to 'Furnace (2)'. Open the copy to edit it." An Omron copy on a line stays on that line under the next free unit number.

## Duplicates and collisions {#duplicates-and-collisions}

Device names are unique within a driver, ignoring case: the create verbs step aside with a numeric suffix, and a rename onto a taken name is refused when committed. Two enabled devices under one driver whose names normalize to the same technical segment (`Line A` and `Line-A`) are both withheld from polling rather than one winning, and their tags read nothing until one is renamed or disabled. The technical identity is limited to 128 characters: "Technical device identity cannot exceed 128 characters." Two Modbus TCP devices may share a host and port with different unit ids and then share the endpoint's transaction pacing. Two Matter devices may name the same node id: discovery offers to open the existing one instead, but does not forbid the second. Two NI-DAQmx devices may read the same device of NI MAX in the same way, for example one module at two poll intervals.

## What the device page does not do {#what-the-device-page-does-not-do}

The driver cannot be changed, the folder is not edited here, and neither the line of a device on a serial line nor the broker of an MQTT device can be reassigned; a device of the generic serial and TCP driver switches between TCP and UDP, and one of the SCPI driver between TCP and VISA, never between a line and the network. Enabling a device does not enable its tags, and disabling a device does not flip theirs. There is no per-device import or export, and no connection test other than enabling the device and reading its health and Last error. An Omron device switches between UDP and TCP, never between a line and the network.