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 or folder's table, to open its page. View connector reads it; Configure connector edits it. Serial lines have their own page, Serial lines.

Creating a device

A new device is named "New device" (then "New device 2", and so on), enabled, with a 1000 ms poll interval and unit id 1, and the page opens on it: "Added device 'New device'. Edit its details on the right." 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.").

Connection is never a blocking step: the embedded server 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 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 embedded server connects to, assembled live from the Connection card (for example modbus+tcp://192.168.0.10:502/1, opc.tcp://plc:4840, simulated://CompressedAir). Under it, one of three notices:

• Driver not included in this package: "This device needs the IEC 61850 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."
• Waiting for certificate approval (OPC UA): "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 Settings, Equipment access." with a Review certificate button that opens Equipment access on that certificate.
• Otherwise the device's last error text in red, when there is one (see Enabling and health).

The command bar

The right-click menu adds Add tag and Move to (see Device folders).

The Device 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.

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), and State, the device's health word. Nothing on it is editable. A Simulated device has no Connection card at all.

Credentials and certificates

Passwords and bearer tokens 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. One 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 the certificate to approve or block it. Revoking an approval later closes the sessions running on it. Details are on the OPC UA page.

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:

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 and a Matter node take commands too, but theirs are fixed by the protocol and come from the driver, not from what you type here.

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, and selects it; the feed reads "Added tag to 'Furnace'." or, when the new tag still needs something, "Added tag to 'Furnace'. Fill in its details on the right."

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.

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

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 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. The page opens on the copy: "Copied 'Furnace' to 'Furnace (2)'. The copy is yours to edit."

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.

What the device page does not do

The driver cannot be changed, the folder is not edited here, and the line of a Modbus RTU device cannot be reassigned. 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.