Understanding IoT signals
An IoT signal is a telemetry or event reading pushed into UniAsset from an external connected system — a sensor, a gateway, an IoT platform.
Requirements
- Available on: Odyssey, Cosmos
- Roles: Owner, to create the API key that ingests signals
IoT ingestion is gated separately from general API access. A key needs both the iot:signal:ingest scope and your plan needs IoT access.
What a signal carries
| Field | Notes |
|---|---|
| Source | Which system sent it — for example AzureIoTHub |
| Signal type | A dotted path such as temperature.high |
| Severity | INFO, LOW, MEDIUM, HIGH, or CRITICAL |
| Value | Numeric, text, or boolean |
| Payload | The complete raw payload, retained verbatim |
| Asset | Optional — signals may arrive before a device is mapped |
| Device ID | The external device identifier |
The raw payload is kept exactly as sent. If your interpretation of a reading turns out to be wrong, the original is still there.
Where to read signals
Dashboard → IoT Signals is the dedicated view across your organization.
On the asset timeline, signals appear alongside everything else that happened to that asset — changes, assignments, documents, services, scans, movements. That is the point of putting them there: the temperature spike and the service record that followed it sit in one sequence.
Severity
Severity is set by the system sending the signal, not by UniAsset. It describes what the sending system thought the reading meant.
Use it consistently in your upstream pipeline or it becomes noise.
Signals without an asset
A signal can arrive unattached when the device is not yet mapped to an asset. It is still stored and still visible in the IoT Signals view — it just is not on any asset's timeline until the mapping exists.
That is deliberate: telemetry arriving before configuration is finished should not be dropped.
What signals do
Signals are stored and displayed. They are tenant-isolated, browsable, and shown on the asset timeline.
What signals do not do
Nothing reacts to a signal automatically.
- A signal does not raise a work order
- A signal does not open an incident
- A signal does not raise an alert or send an email
- A signal does not breach an SLA
If you need action taken on a reading, that logic has to live in the system sending the signal, or in your own systems reading UniAsset's webhooks.
UniAsset's existing alerting paths — overdue maintenance, document expiry, warranty expiry, low stock, checkout returns — work as normal and are unaffected by signals.
Important Organizations that need signal-driven automation today should pair UniAsset with a dedicated IoT platform and use it to decide when to act.
Common mistakes
Expecting a CRITICAL signal to page someone. It will not. Severity is a label on stored data.
Sending high-frequency raw telemetry. A 1 Hz sensor produces 86,400 readings a day per device. Aggregate upstream and send what is meaningful.
Using signal type strings inconsistently. temp.high, temperature.high, and Temperature_High are three different types. Fix the vocabulary before you scale.
Assuming the asset link is automatic. Map devices to assets, or signals arrive unattached.
Troubleshooting
IoT Signals isn't in my sidebar. It needs Odyssey or above.
Ingestion returns 403. Check both gates: the key needs the iot:signal:ingest scope, and your plan needs IoT access.
Signals arrive but appear on no asset. The device is not mapped to an asset. Include the asset in the payload, or map the device.
A signal type was rejected. Signal types allow letters, digits, and the characters ., _, : and - only.
The payload was rejected as too large. Payloads are capped at 1 MB.
Related articles
Need Help?
If you have questions not covered in this article, our support team is here to help.
Contact Support