How to manage connected industrial assets
Connecting equipment to UniAsset puts telemetry in the same record as maintenance history, cost, custody, and documents.
Requirements
- Available on: Odyssey, Cosmos
- Roles: Owner, to create the API key
What you get, and what you do not
You get telemetry stored alongside everything else about the asset, visible on its timeline and in a dedicated view.
You do not get automation. Nothing reacts to a signal. A temperature reading above a threshold sits there until a person looks. See Understanding IoT signals.
Knowing that up front decides how you design the integration: the decision logic stays in your IoT platform, and UniAsset becomes the record it writes to.
Steps
- Create the assets in UniAsset first, so signals have somewhere to land.
- Create an API key with
iot:signal:ingestand nothing else. - Map devices to assets in your sending system, so each signal carries the right asset.
- Decide what is worth sending — see below.
- Send a test signal and confirm it appears at Dashboard → IoT Signals and on the asset timeline.
For a worked platform example: Connecting Azure IoT Hub.
Choosing what to send
This is the decision that determines whether the integration is useful or noise.
Send events, not raw streams. A sensor reading every second produces 86,400 records a day per device. Aggregate upstream and send state changes and threshold crossings.
Send what someone would act on. A temperature crossing a limit is worth a signal. A temperature that is normal is not.
Send recovery as well as failure. temperature.high without temperature.recovered leaves every timeline looking like an unresolved crisis.
Naming signal types
Signal types are dotted paths. A consistent vocabulary is worth agreeing before you scale, because inconsistent names cannot be tidied up retroactively across millions of stored records.
A structure that works:
<domain>.<event>[.<qualifier>]
For example:
temperature.high
temperature.recovered
vibration.spike
motor.stop.unexpected
power.outage
power.restored
Signal types allow letters, digits, and ., _, : and -.
Using signals alongside maintenance
Even without automation, having telemetry in the same record changes how the maintenance team works.
Inspection rounds become targeted. Filter the IoT Signals view for recent high-severity signals before doing a round, and go to those assets first.
Repair-or-replace decisions get better. An asset generating frequent fault signals and carrying a high total cost of ownership is a replacement candidate rather than another repair. See Replace or repair?.
Failure investigations have a timeline. When you report an incident, the signals leading up to it are already on the asset's timeline — and the incident snapshot locks the asset's state at that moment.
Common mistakes
Sending raw high-frequency telemetry. Aggregate at the edge.
Expecting signals to raise work orders. They do not. Your sending system decides when to act.
Bundling iot:signal:ingest with write scopes on one key. Give the telemetry pipeline that scope alone.
Not mapping devices to assets. Unmapped signals are stored but appear on no asset timeline, which is where their value is.
Changing your signal type vocabulary halfway through. Historic records keep the old names.
Troubleshooting
IoT Signals isn't in my sidebar. It needs Odyssey or above.
Ingestion returns 403. Both gates must pass: the key needs iot:signal:ingest, and your plan needs IoT access.
Signals arrive but appear on no asset. The signal is not carrying an asset. Map the device in your sending system.
A signal type was rejected. Check the allowed characters.
Payload rejected as too large. Payloads are capped at 1 MB. Send a summary, not a batch dump.
I need alerts when a threshold is crossed. Set that up in your IoT platform. UniAsset stores and displays the signal; it does not act on it.
Related articles
Need Help?
If you have questions not covered in this article, our support team is here to help.
Contact Support