Importing from CSV
The same three-step wizard imports three different things, depending on where you open it:
- From the monitor list's Create dropdown, it creates CVE monitors. See Importing CVE monitors below.
- From an S7 data source's Import action, it declares data points on that source. See Importing S7 data points below.
- From an OPC UA data source's Import action, it declares data points on that source. See Importing OPC UA data points below.
The wizard guides you through the same three steps either way: Upload, Map columns, and Results — only the column set and what a row builds differ.
Importing CVE monitors
Organization administrators can create many CVE monitors at once from a CSV file. In the monitor list, open the Create dropdown and choose Import CSV to open the import wizard.
CVE monitors are the only monitor type this import creates. Connections to OPC UA servers and S7 PLCs are added as data sources, and everything that alerts on a value is a condition monitor — neither is a row in a spreadsheet. To declare S7 tags or OPC UA nodes in bulk, see Importing S7 data points or Importing OPC UA data points.
Two values behave in ways worth knowing up front:
escalationPolicyreferences an existing escalation policy by name or numeric id. A name must match exactly, so create the policy before importing.incidentMessageTemplateis the literal incident message, not a reference to a saved template.
The column set is listed under Map columns.
Importing S7 data points
Organization administrators can declare many S7 data points at once from a CSV of tag addresses. Open an S7 data source's detail page and choose Import to open the wizard, already bound to that source.
Because the source is implied by where you started the import, the file is about tags and nothing else — no endpoint, rack or slot column, and no monitorType either. The column set is listed under Map columns.
A data point this import declares is adopted and reads on the source's own cadence, like any other data point of the source. A row naming an address and data type already declared on the source is a no-op — it resolves to the existing data point rather than creating a duplicate, so re-running an unchanged file is harmless.
Unlike the CVE import, this run is all or nothing: every row is checked before anything is written, and if any row fails, nothing is created — the results step lists every failing row so you can fix the file and try again. See Results.
Alerting on the values you import
Mapping four more columns — aggregation, operation, operand and duration — turns each row from a data point declaration into a threshold alert on it: "alert when the average of DB1.DBD10 over 5 minutes is above 80". For a row with all four mapped, the import creates:
- a condition — the graph
Sensor → Aggregate → Compare → Alert— pinned to the data point the row declares, and - a condition monitor that alerts on it, in the Conditions group of the monitor list.
The condition opens in the same guided sentence form a hand-built threshold uses, so a hundred imported alerts stay editable afterwards — nothing about them is canvas-only.
Once any of the four is mapped, all four become required, along with name (the condition and monitor's name) and escalationPolicy (who an incident from it pages) — a row cannot build a threshold from three fields and a guess at the fourth. Leaving all four unmapped keeps the plain behavior above: rows declare data points only, with no conditions or monitors created.
Condition names are unique per organization and case-insensitive. A row whose name is already taken — by an existing condition, or by another row in the same file — fails validation before anything is written, the same way an invalid address does.
The Activate created monitors toggle on the mapping step decides whether the monitors this run creates start active or inactive. Off (the default) creates them inactive: they sit in the monitor list for review, and the evaluator skips an inactive monitor entirely, so none of them can raise an incident until you turn them on by hand. On starts them alerting immediately. This is a good default for a first import of a hundred thresholds — review the generated conditions, then activate the ones that look right.
Importing OPC UA data points
Organization administrators can declare many OPC UA data points at once from a CSV of node ids — the same case a machine builder's node list or a large server you'd rather not browse covers. Open an OPC UA data source's detail page and choose Import to open the wizard, already bound to that source.
Because the source is implied by where you started the import, the file is about nodes and nothing else: a row is one column, nodeId. Unlike an S7 tag, an OPC UA data point's value type is not declared — it is learned from the first reading, the same as when you declare one by hand — so there is no dataType column to map. The column set is listed under Map columns.
Node ids are checked for valid syntax only — ns=2;s=Line1.Temperature or ns=3;i=1001, the same textual form the source detail page uses. Whether the node actually exists on the server is not checked at import time: that would make the import depend on a reachable server, which defeats the point of preparing a file before commissioning. A node id the server does not recognize comes back as a bad reading once the source starts sampling it, visible on the source's detail page like any other bad reading.
A row naming the source's own health-check node is refused, the same way declaring it by hand is — the point already exists as the source's reachability probe, so importing it again would create a second, meaningless liveness point rather than a real reading.
A data point this import declares is adopted and reads on the source's own cadence, like any other data point of the source. A row naming a node already declared on the source is a no-op — it resolves to the existing data point rather than creating a duplicate, so re-running an unchanged file is harmless, and two rows that spell the same node differently (say, with or without a leading zero in the identifier) still resolve to one data point.
Unlike the CVE import, this run is all or nothing: every row is checked before anything is written, and if any row fails, nothing is created — the results step lists every failing row so you can fix the file and try again. See Results.
Alerting on the values you import
Mapping four more columns — aggregation, operation, operand and duration — turns each row from a data point declaration into a threshold alert on it: "alert when the average of ns=3;s=Boiler.Pressure over 5 minutes is above 80". For a row with all four mapped, the import creates:
- a condition — the graph
Sensor → Aggregate → Compare → Alert— pinned to the data point the row declares, and - a condition monitor that alerts on it, in the Conditions group of the monitor list.
The condition opens in the same guided sentence form a hand-built threshold uses, so a hundred imported alerts stay editable afterwards — nothing about them is canvas-only. Because an OPC UA data point's value type is only learned from its first reading, a threshold over a freshly declared node imports and validates cleanly even if the node turns out to hold, say, a boolean — it simply won't fire sensibly under a numeric comparison like avg ... > 80.
Once any of the four is mapped, all four become required, along with name (the condition and monitor's name) and escalationPolicy (who an incident from it pages) — a row cannot build a threshold from three fields and a guess at the fourth. Leaving all four unmapped keeps the plain behavior above: rows declare data points only, with no conditions or monitors created.
Condition names are unique per organization and case-insensitive. A row whose name is already taken — by an existing condition, or by another row in the same file — fails validation before anything is written, the same way an invalid node id does.
The Activate created monitors toggle on the mapping step decides whether the monitors this run creates start active or inactive. Off (the default) creates them inactive: they sit in the monitor list for review, and the evaluator skips an inactive monitor entirely, so none of them can raise an incident until you turn them on by hand. On starts them alerting immediately. This is a good default for a first import of a hundred thresholds — review the generated conditions, then activate the ones that look right.
CSV format
The first row must be a header row of column names — the next step matches those names to fields (you can adjust the mapping by hand). Save the file as UTF-8 and follow standard CSV rules (RFC 4180): separate values with commas, and wrap any value that itself contains a comma in double quotes.
To start from a working example, use Download example CSV on the upload step: it contains the columns for the wizard you opened, with one or more example rows.
Step 1 — Upload
Drag a CSV file onto the drop zone, or click to browse. A preview table shows the first rows so you can confirm the file was read correctly; use Replace to swap in a different file. Click Next to continue, or Cancel to close the wizard.
Step 2 — Map columns
Map each field to a column from your CSV. The wizard auto-detects matching column names and pre-fills the mapping where it can. For every field you can:
- pick the CSV column whose values to use,
- choose Fixed value… to apply one value to every row (handy for shared settings such as the escalation policy), or
- leave it Not mapped — allowed only for optional fields.
The table lists every column, whether it is required, and the values it accepts.
CVE monitor columns
| Column | Required | Valid values / format |
|---|---|---|
monitorType | Yes | cve |
name | Yes | Free text |
escalationPolicy | Yes | Name (exact match) or numeric id of an existing escalation policy |
vendor | Yes | Device vendor, e.g. Siemens |
orderCode | Yes | Device order code / MLFB, e.g. 6ES7516-3AN00-0AB0 |
firmware | Optional | Firmware version, e.g. V2.9.2 (empty → matches all firmware versions) |
incidentMessageTemplate | Optional | Free text (the message itself) |
TIP
CVE monitors match published advisories against a device by vendor + orderCode (+ optional firmware). See CVE monitors for how matching works.
S7 data point columns
| Column | Required | Valid values / format |
|---|---|---|
address | Yes | An S7 address, e.g. DB1.DBW0 or DB2.DBD4 |
dataType | Yes | BOOL, BYTE, WORD, DWORD, INT, DINT, or REAL |
name | Only if any threshold column is mapped | What to call the condition and its monitor |
escalationPolicy | Only if any threshold column is mapped | Name (exact match) or numeric id of an existing escalation policy |
aggregation | All four, or none (see below) | min, max, sum, avg (or average), count |
operation | All four, or none | gt (or >, above), gte (>=), lt (<, below), lte (<=), eq (=), neq (!=) |
operand | All four, or none | The threshold value, e.g. 80 |
duration | All four, or none | The aggregation window: seconds, or a number with a unit, e.g. 300, 5m, 1h |
TIP
See S7 data sources for what each address form and data type means, and Alerting on the values you import for the four threshold columns.
OPC UA data point columns
| Column | Required | Valid values / format |
|---|---|---|
nodeId | Yes | An OPC UA node id, e.g. ns=2;s=Line1.Temperature or ns=3;i=1001 |
name | Only if any threshold column is mapped | What to call the condition and its monitor |
escalationPolicy | Only if any threshold column is mapped | Name (exact match) or numeric id of an existing escalation policy |
aggregation | All four, or none (see below) | min, max, sum, avg (or average), count |
operation | All four, or none | gt (or >, above), gte (>=), lt (<, below), lte (<=), eq (=), neq (!=) |
operand | All four, or none | The threshold value, e.g. 80 |
duration | All four, or none | The aggregation window: seconds, or a number with a unit, e.g. 300, 5m, 1h |
TIP
See OPC UA data sources for the node id syntax and how a data point's value type is learned, and Alerting on the values you import for the four threshold columns.
When every required field is mapped, click Run Import. To close and discard your work, click Cancel; to pause without losing your column mappings, use the × button in the header — the wizard resumes where you left off when you reopen it.
Step 3 — Results
A summary shows how many rows were imported successfully and how many failed.
- CVE monitors commit row by row, so a failed row does not stop the rows around it from being created.
- S7 and OPC UA data points commit all together: if any row failed, the summary shows zero successes, and nothing was written.
Each failed row is listed with the error that caused it. Click Download failed rows to export just those rows as a CSV, correct them, and import the file again.
Related
- Monitors — monitor types, configuration, and evaluation
- S7 data sources — declaring data points by hand, adoption, and cadence
- OPC UA configuration — declaring data points by hand, adoption, and cadence