Asset registry basics

Every physical instrument Open Gauge tracks — a sensor, a transmitter, a data logger — is an asset. Assets live under Assets → New Asset in the UI, and each one gets a human-readable ID (e.g. OG-00042) in addition to its internal database ID.

Sensor vs. DAQ

An asset's type is one of:

• sensor — a measuring instrument. Has one or more channels, each representing a single measured physical quantity (temperature, pressure, flow, ...). See Adding a sensor.
• daq — a data acquisition device: a data logger, signal conditioner, or gateway. Has a single hardware specification instead of measurement channels. See Adding a DAQ.

Common fields

Regardless of type, every asset carries the fields below, plus a computed health score (0–100) — see Health scoring. Every field here is also explained by an info tooltip (ⓘ) directly in the UI — clicking a tooltip brings you back to the matching section on this page.

Asset ID

An auto-generated, unique human-readable identifier (e.g. OG-00042), separate from the asset's internal database id. Used throughout the UI, on QR/sticker labels, and in exported bundles — and it's what appears in the asset's own URL (/assets/OG-00042), so a link to an asset is short and readable instead of a raw UUID. An old UUID-based link still works if you have one bookmarked.

Name, manufacturer, model & serial number

Free-text identity fields. Name is what shows in lists and headers; manufacturer, model, and serial number identify the physical unit.

Part number

The manufacturer's own part/catalog number, distinct from the asset's serial number — useful when ordering spares or looking up a datasheet.

Description

Free-text notes on the asset's purpose or context, shown under its identity fields.

Organization

The organization that owns this asset, picked from a dropdown of the creating user's own organizations when the asset is created — required, and independent of the asset's location (the two aren't cross-validated). See Organizations.

Location

Where the asset currently is, picked from the organization's location tree — see Locations. Moving an asset records an audit-logged location-history entry rather than overwriting the prior location silently.

Dimensions & weight

Physical size (free text, e.g. 150×30×30 mm) and weight in kilograms — purely informational.

Mounting type

How the asset is physically installed (e.g. wall, ceiling, pole, DIN rail).

Connection type

The physical connector or wiring interface (e.g. M12 4-pin).

IP rating

Ingress Protection rating (e.g. IP65) describing dust/water resistance.

Hazardous area rating

The ATEX/hazardous-location zone the asset is rated for (or "non-hazardous").

Operating temperature & humidity

The environmental range the asset itself is rated to operate within — distinct from a channel's measurement range, which is what it measures rather than what it tolerates.

Power supply & consumption

Supply voltage/type (e.g. 24 VDC) and power draw in watts.

Firmware version

The version string of the asset's onboard firmware, where applicable.

Purchase date, price & warranty

Procurement bookkeeping: when the asset was bought, what it cost, and when its warranty expires.

Asset picture

Each asset can have a picture of the physical unit, shown as a circled preview to the left of the header on the asset detail page. Click the preview to open it full-size in a modal. In edit mode, use the camera button on the picture to upload or replace it, and the trash button to remove it — changes take effect immediately, independent of the "Save changes" flow used for the rest of the asset's fields. The picture is stored in MinIO like any other attached file (see Data model & concepts) and is distinct from the write-once sensor_image_id/pinout_image_id/sensor_schematic_id reference images set at asset creation.

QR sticker labels

The Sticker button on the asset detail page opens a dialog with a printable label in three sizes, each downloadable as PNG, JPG, or PDF. Every size encodes a URL to the asset's detail page in its QR code:

• 1×0.5 in — QR code on the left half; asset ID and asset name on the right half. Sized for small components where a 2×2 or 4×2 label won't fit.
• 2×2 in — QR code with the asset ID printed below it.
• 4×2 in — QR code, asset ID, sensor name, latest calibration/due dates, and the calibration coefficient table, side by side.

Import & export

Any asset can be exported as a ZIP bundle — from the Export button on the asset detail page for a single asset, or from the Export button on the asset registry page to bulk-export a selection of assets (a checklist modal lets you pick individual assets or select all at once). Both produce the same bundle shape; a bulk export is just several single-asset bundles inside one outer ZIP.

Each asset gets its own folder named after its asset_id (e.g. OG-00042/), containing:

• asset.yaml — every asset field, its sensor channels or DAQ details, and its complete calibration history (including calibration data points and computed statistics), in a human-readable format.
• media/ — the actual files: the asset picture, datasheet, pinout/sensor images and schematic, any bulk-attached files, and each calibration's certificate PDF (one subfolder per calibration, oldest first).

What's deliberately left out of asset.yaml: internal database UUIDs — the asset's own id, its location, created_by/retired_by, and every file's id. These only make sense inside the database they came from. Where useful, a human-readable name is included instead purely for reference (e.g. location_name, calibration_method_name, internal_procedure_name) — sensor channels are relinked by channel_id rather than a raw sensor UUID. One field has no safe substitute and is omitted entirely: a calibration's reference to another asset (internal_reference_asset_id) is not exported or re-linked.

Calibration history is exported and re-imported verbatim — calibration_version and every computed statistic are copied as-is, never recalculated, since they represent historical fact (see Data model & concepts).

Importing

Import a ZIP either from Assets → + New Asset → Import from file (expects exactly one asset in the file) or from the registry's Import button (accepts one or more ZIPs at once, each of which may itself contain one or more asset folders — handy for re-importing a prior bulk export). Both flows call the same backend endpoint and report one result per asset folder, so a problem with one asset never blocks the others in the same file.

On import, a brand-new asset is created with a new internal id. Its location_id is left unset (the exported location_name is informational only) until you assign it manually. calibration_method_name/internal_procedure_name are matched case-insensitively against procedures already registered in the target system; if no match is found, the link is simply left blank rather than failing the import. If the exported asset_id already exists in the target system, that asset's import fails with a clear error — rename it in the YAML and retry.

Lifecycle

Assets are never hard-deleted while a deployment is active. Retiring an asset:

• Sets is_active = false and records retired_at, retired_by, and retired_reason.
• Preserves the asset's full calibration history — a retired asset's past calibrations remain visible and auditable.

This matches Open Gauge's general database philosophy (see Data model & concepts): traceability takes priority over tidiness. If you need an asset gone from daily views but its history intact, retire it — don't delete it.