What an IoT signal is
A signal in UniAsset is a single discrete event reported by an external IoT pipeline — a sensor reading, a state change, a heartbeat, a threshold breach. Every signal is a row in UniAsset's signal store, linked (when possible) to the asset it concerns.
UniAsset is provider-neutral. The same model accepts signals from:
- Azure IoT Hub
- AWS IoT Core
- Google Cloud IoT
- Custom MQTT bridges
- HTTP publishers from BMS, SCADA, PLC, or vendor cloud platforms
A signal is not an alert. Phase 1 of UniAsset's IoT foundation stores signals; it does not yet trigger alerts, create work orders, or notify users. That capability ships on top of the same store in a later phase.
Plan required: Enterprise
How signals are stored
Each signal records:
| Field | Meaning |
|---|---|
| Received timestamp | When UniAsset's server accepted the signal — authoritative, not the device-supplied time. |
| Source | The originating system, e.g. AzureIoTHub, AWSIoT, CustomMQTT. |
| External device ID | Stable hardware identifier from your IoT pipeline. |
| Signal type | A dotted-path event name like temperature.high or vibration.spike. |
| Severity | An optional hint: INFO, LOW, MEDIUM, HIGH, CRITICAL. |
| Numeric / text / boolean value | Typed projection of the headline value, used for filtering and (later) charts. |
| Raw payload | The full JSON body as received. Stored verbatim. |
| Asset link | An optional reference to the asset the signal belongs to. |
The raw payload is the source of truth. Typed projections (numericValue, textValue, booleanValue) are denormalizations for fast filtering — never mutate the source payload to fit them.
Where to read signals
There are two read surfaces in Phase 1:
Per-asset signal history
Open any asset (Assets → <name>) and scroll to the IoT Signals section. It shows the most recent 10 signals for that asset, with an expandable view of each raw payload. A View all link drops you into the global explorer pre-filtered to this asset.
Global signal explorer
The IoT Signals item in the sidebar (Enterprise only) opens the global explorer at /dashboard/iot-signals. It lists every signal in the organization, with filter controls for:
- Asset
- Signal type
- Severity
- Source system
- Date range (received between two dates)
Results are paginated 50 at a time, newest first. Each row expands to reveal its raw payload.
Severity levels
UniAsset accepts the following severity hints. They are stored as-is but normalized to upper case so dashboards and (future) rules can match them reliably.
| Level | Meaning |
|---|---|
CRITICAL | Immediate operational impact. Example: a chiller has lost compressor pressure. |
HIGH | Significant deviation that warrants attention soon. Example: a temperature is 20 % above the operational band. |
MEDIUM | Notable but tolerable for the moment. Example: a runtime counter has crossed a maintenance threshold. |
LOW | Informational deviation. Example: humidity is mildly above target. |
INFO | Routine telemetry. Example: an hourly heartbeat. |
Severity is optional. If your devices don't emit one, leave the field unset.
Capturing signals without an asset link
Some pipelines emit signals before the asset is registered in UniAsset, or from gateways that don't know the asset-to-device mapping. That's fine — the assetId field is optional. Signals without an asset link still appear in the global explorer, and you can reconcile them later by updating the device-to-asset mapping in your IoT pipeline.
Tenant isolation
Every signal carries a tenantId derived server-side from the API key that submitted it. There is no way to spoof a different tenant from the request body. If you delete a tenant, its signals are deleted with it. If you archive an asset, its signals are preserved (the asset link is cleared) so the historical record remains.
What signals do not do (yet)
Phase 1 is deliberately bounded. Signals do not:
- Trigger emails, in-app notifications, or push messages.
- Create work orders or maintenance records.
- Raise incidents.
- Breach SLAs.
- Feed predictive maintenance scoring.
- Stream in real time over WebSockets.
If you need any of those today, raise the signal severity in your upstream pipeline and use UniAsset's existing alerting paths (overdue maintenance, document expiry, warranty expiry, low stock) until automation phases ship.
Roadmap — what is coming
The signal foundation is the substrate for several capabilities that will ship in later phases on top of the same store:
- Rules engine — pattern-match
signalType,severity, and value thresholds; emit side-effects. - Auto work-order creation — turn a
CRITICALsignal into an open work order with SLA timing. - Incident auto-creation — escalate sustained failures into formal incidents.
- Predictive maintenance — historical signal streams feed a model that surfaces "due for service" suggestions.
- AI correlation — cluster related signals across assets so a single underlying fault doesn't generate dozens of duplicate tickets.
- Retention controls — per-tenant retention policy with cron-driven cleanup.
None of these change the Phase 1 contract. Adopting the ingestion endpoint today keeps you compatible with everything that follows.
Related articles
Need Help?
If you have questions not covered in this article, our support team is here to help.
Contact Support