# Enabling and health

> What takes part in acquisition at each level of the tree, what the dots and state texts mean, the All/OK/Issues/Off chips, the status bar, Last error, and the Reconnect, Refresh and Refresh all verbs.

Two questions run through the whole Communication column, and both are answered the same way at every level: what is taking part in acquisition, and what is answering right now. The first is a choice you make with the Enable and Disable verbs; the second is what an always-on monitor observes once a second and pushes to every dot on the page, to the status bar, and to the Connector values that Logic and dashboards read.

## What takes part {#what-takes-part}

Enabling is decided per level, and a switch never rewrites the switch below it:

| Level | Verbs | Effect when off |
| --- | --- | --- |
| Driver | Enable / Disable on the Drivers row's table | The driver's group leaves the tree. Refused while the driver has devices or lines, so nothing configured can go off this way. |
| Serial line | Enable / Disable on the line's bar | The bus closes for every device on it; each device keeps its own Enabled choice and comes back exactly as it was when the line is enabled again. Enable is refused while the line's tuple is invalid. |
| Device | Enable / Disable on the device's bar or its row | All communication with the device stops and its tags leave the live address space; the tags keep their own switches. On by default. |
| Tag | Enable / Disable on the tag's bar or its row | That one tag leaves acquisition and the live address space. On by default. A Write only tag is never polled, enabled or not. |

Every Enable and Disable needs Configure connector and is greyed while a run holds the station or the runtime is stopped; a scan on the same driver greys the line and device ones too. A device is **operationally enabled** when it is enabled and, for Modbus RTU, its line is: that is what polling, the Off chip and the health monitor look at.

## The health of a device {#the-health-of-a-device}

The monitor derives a device's health from its enabled, readable tags:

| Health | Dot | Meaning |
| --- | --- | --- |
| **Online** | green | Every enabled readable tag answered its last read. |
| **Partial** | amber | Some answered, some did not. |
| **Offline** | red | None answered. |
| **Disabled** | grey | The device is disabled, or its serial line is. |
| **Unknown** | grey | Nothing to judge: no enabled tag. |

A device whose enabled tags are all Write only has no reading to judge and takes the transport's connection state instead: Online while connected, Offline while not, Unknown before the server has tried. An out-of-range value with a limit fault is a process condition, not a connection problem: it turns the tag's dot amber but never counts the device offline. A stand-in value likewise keeps the tag readable while the device is still reported offline. The embedded server itself has a health too: while it is stopped every tag reads as a gap, and the status bar says "Server: Stopped".

## The tag's dot {#the-tags-dot}

In the tree a tag's dot is green while the tag has a value and grey otherwise. On the tag's page the same dot is amber when the value is a stand-in or the Limits stage raised a fault, because a readable number is not the same as a measurement. The tag row also carries a red error marker when the last read failed, with the message as its tooltip.

## Serial line states {#serial-line-states}

A Modbus RTU line reports the physical port separately from its devices, in the tree row, in the driver's line table and in the line page's header:

| State | Dot | Meaning |
| --- | --- | --- |
| **Off** | grey | The line is disabled. |
| **Idle** | grey | Enabled, but no enabled device: the port is not open. |
| **Connecting…** | amber | A device is enabled and the port is being opened, or reopened after a failure. |
| **Online** | green | The port is open and serving. |
| **Port failure** | red | The port could not be opened or failed; the diagnostic is printed under the header and as the row's error tooltip, and the journal records the failure once and the recovery once. |

The line's summary text adds what its devices are doing: "Online · 2/2 devices online", "Online · 1 online · 1 with issues", "Idle · no enabled devices". A line can be Online and still hold a device nothing answers for.

## How the dots roll up {#how-the-dots-roll-up}

Folders, serial lines, drivers and the Drivers row all apply one rule to their children: only Online, Partial and Offline children count; Disabled and Unknown are neutral and never pull a parent amber or red. Of the counting children, all Online is Online, any Online or Partial among others is Partial, all Offline is Offline, and no counting child at all is Unknown. A folder rolls up every device inside it, subfolders included; a Modbus RTU driver rolls up its lines; the Drivers row rolls up every enabled driver. Sixteen enabled drivers with one Online group and fifteen empty ones read Online, not amber.

## The All / OK / Issues / Off chips {#the-all--ok--issues--off-chips}

The chips above the tree bucket every row by these same states: **OK** is an operationally enabled device or line that is Online, and an enabled tag that has a value; **Issues** is an enabled device or line that is Offline or Partial, and an enabled tag without a value; **Off** is a disabled device, line or tag, a device under a disabled line included. A driver row shows when something below it passes; the selected row always stays visible. The chips are described with the rest of the column on [Connector](connector#search-and-the-state-chips).

## The status bar {#the-status-bar}

The dot and text at the left of the window's status bar are the same monitor, folded to one line: "Online" when the server is up and no device is Offline or Partial; "Server: Starting…" or "Server: Stopped" when the server is not Online, which dominates everything else; otherwise the worst-off device by name, "Connector: Furnace not communicating" for Offline or "Connector: Furnace unstable" for Partial. Clicking the indicator opens the Connector page. The rest of the status bar is on [The window](app-window).

## Last error {#last-error}

Every warning or error the journal records for a device is attached to that device: it shows as a red marker on the tree row with the message as tooltip, as the **Last error** column on the driver's device table, and as red text under the device page's header; when the entry names a tag, that tag's row and page carry it too. The band clears on its own when the device comes back Online. A device whose driver the package does not carry shows the notice "Driver not included in this package." in that place instead, because there is no fault to investigate; an OPC UA device waiting for its certificate shows "Waiting for certificate approval". The full journal is on the Events page.

## Reconnect, Refresh and Refresh all {#reconnect-refresh-and-refresh-all}

| Command | Where | What it does |
| --- | --- | --- |
| **Reconnect** | A device's bar and right-click menu | Closes that device's connection and opens it again, touching no other device and reloading nothing. The message waits for the driver: "Reconnected 'Furnace'.", or "Couldn't reconnect 'Furnace':" with the cause. |
| **Refresh** | A driver's bar and right-click menu | Reads the configuration back from the database and rebuilds the whole tree. The running server is left as it is. Expansion and selection reset, and the column comes back closed. "Devices refreshed." |
| **Refresh all** | The Drivers page's bar | The same as Refresh. |

Refresh and Refresh all only read, so they are drawn for every role; Reconnect closes and reopens a connection, so a role without Configure connector is not drawn it at all. All three grey while a run holds the station or the runtime is stopped, and Reconnect and Refresh also grey while a scan or a pairing runs. Neither refresh is needed after an edit: every save reconciles the changed device into the running server by itself, and an unreachable device is retried in the background until it answers, its tags reading as gaps until then. Reconnect is what shortens that wait: it asks now instead of leaving the device to the next automatic attempt, and it reports whether the device answered. The limits that raise a limit fault are part of [the value pipeline](connector-value-pipeline).