Azure IoT Hub + UniAsset: Enterprise Asset Monitoring Simplified
If you run an industrial estate on Azure IoT Hub, you already have the hardest part of an IoT program in place: devices, identities, and a message broker. What you usually don't have is somewhere for the telemetry to live next to the asset record — the place your maintenance and reliability teams actually open every day.
This post is the practical companion to that gap. It walks through how to forward Azure IoT Hub telemetry into UniAsset's Enterprise IoT Signal foundation, what the payload should look like, and what changes for your operations team once the connection is in place.
Phase 1 of UniAsset's IoT foundation is ingestion plus history. Automation, alerting, and predictive workflows ship on top of the same foundation in a later phase — adopting now keeps you compatible with everything that follows.
The end-state in one diagram
Field device ──MQTT/AMQP──▶ Azure IoT Hub ──Message route──▶ UniAsset
│
▼
Asset detail page
Global IoT explorer
Nothing changes on the device or on the IoT Hub configuration that already exists. We add a custom endpoint and a message route. That's it.
Step 1 — Generate a UniAsset API key
In UniAsset (Owner role, Enterprise plan):
- Settings → Integrations → API Keys → Create API Key.
- Name it
Azure IoT Hub — Production. - Grant only
iot:signal:ingest. No write permissions, no delete permissions. - Copy the key once — UniAsset stores only a bcrypt hash.
- Store the plaintext in Azure Key Vault, not in the IoT Hub UI.
Step 2 — Add UniAsset as a custom endpoint
In the Azure portal:
- Open your IoT Hub.
- Hub settings → Message routing → Custom endpoints → + Add → Webhook.
- URI:
https://<your-uniasset-domain>/api/integrations/iot/signals. - Custom headers:
Authorization: Bearer <your-key>(use a Key Vault reference, not the plaintext)Content-Type: application/json
- Save.
Step 3 — Add the message route
- Message routing → Routes → + Add.
- Data source: Device Telemetry Messages.
- Endpoint: the
UniAssetendpoint you just created. - Routing query:
trueto forward everything, or a property filter likesignalType = 'temperature.high'if you want to be selective. - Save.
Step 4 — Shape the payload
UniAsset accepts a small, well-defined schema:
{
"assetId": "ckxyz123abc",
"deviceId": "azure-device-001",
"source": "AzureIoTHub",
"signalType": "temperature.high",
"severity": "HIGH",
"numericValue": 92.5,
"payload": {
"temperature": 92.5,
"unit": "C",
"messageId": "12fa..."
}
}
Required: source, signalType, payload. Everything else is optional.
If your devices emit a different schema, the cleanest pattern is an Azure Function between IoT Hub and UniAsset that does the transform. Devices stay untouched; the contract sits in one well-tested function:
export async function azureIoTBridge(req: { body: any }) {
const raw = req.body;
const uniassetPayload = {
deviceId: raw.systemProperties["iothub-connection-device-id"],
source: "AzureIoTHub",
signalType: raw.properties.signalType ?? "telemetry.raw",
severity: raw.properties.severity,
numericValue: raw.body.value,
payload: raw.body,
};
await fetch("https://<your-uniasset-domain>/api/integrations/iot/signals", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.UNIASSET_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify(uniassetPayload),
});
}
Step 5 — Verify
In UniAsset, the IoT Signals item appears in the left sidebar (Enterprise only). The global explorer should show messages within seconds. If you mapped assetId, open the corresponding asset detail page and scroll to the IoT Signals section.
What changes for your operations team
The technical work above is small. The operational change is the point.
| Workflow | Before | After |
|---|---|---|
| Morning walk-the-plant | Generic checklist, no priority | Sort by past 24 h, severity ≥ HIGH; walk to the assets that need eyes |
| Vendor call-out triage | Vendor portal in one tab, UniAsset in another | Vendor-emitted signals appear alongside the asset's maintenance history |
| Audit evidence | Manual screenshots from the IoT Hub UI | Filtered export from the UniAsset global signal explorer |
| Replace vs repair | Gut feel + TCO chart | TCO chart + signal volume + severity distribution |
| Incident retrospective | Reconstruct timeline from emails | Read the asset's signal timeline straight off the detail page |
None of these workflows require automation. They all benefit from visibility alone.
Operational guardrails
A few production-grade habits we recommend from day one:
One API key per environment. Production and staging must have distinct keys so revocation is surgical and audit logs are unambiguous.
Edge summarization for high-frequency telemetry. A 1 Hz vibration sensor should not emit 86,400 signals per device per day. Aggregate at the edge to a per-minute or per-event-band summary; keep the raw stream in your historian.
Use dotted-path signalType values. temperature.high, motor.runtime.threshold, door.held_open. The convention is free today and pays dividends the moment the rules engine ships and you want to write temperature.* patterns.
Always include deviceId in the payload. Even if you also pass assetId, the device identifier lets you reconcile mappings later if hardware swaps occur.
Cap payload size at 1 MB. UniAsset rejects larger bodies with a 413. If you have legitimately large payloads (camera images, audio snippets), upload the binary to your blob store and reference the URL in payload instead.
The next 30 days
If you are wiring this up for the first time, here is the deployment plan that has worked best with early customers:
- Day 0: Pick one critical asset class (chillers, compressors, generators — whichever is most expensive when it fails).
- Day 0: Generate the API key, add the custom endpoint, route only that class to UniAsset.
- Day 1–7: Confirm signals are arriving against the asset records.
- Day 7–14: Read the timeline alongside the maintenance log. Identify the recurring
signalTypevalues that correlate with callouts. - Day 14–30: Roll out to additional asset classes. Lock in the
signalTypenaming convention before the volume grows.
By day 30 you have a tenanted signal stream ready for the automation phase. By day 90 you have a longitudinal record long enough to be useful for replace-vs-repair decisions.
Closing thought
Azure IoT Hub is excellent at moving messages. It is not designed to retain them in a form that maintenance and reliability teams can act on against the asset register. Connecting it to UniAsset closes that loop in an afternoon, and the operational change is immediate.
See also: Connecting Azure IoT Hub to UniAsset (KB), Understanding IoT Signals in UniAsset, and Why Modern Asset Management Needs IoT Signal Visibility.
Ready to put this into practice?
Start tracking your assets, scheduling maintenance, and gaining operational insights today.