FOR THE PEOPLE WHO BUILD THE DEVICES
From a pilot unit to live data, without the key chase.
Give each unit its own key from Azure IoT Hub, write it once at flashing, and watch its data arrive. Keys and tokens for every device sit on its own connection panel.
New to OpenX? Key terms →
A PILOT UNIT · FOUR STEPS
- 01 · Add
- One connection per unit, then Deploy
- 02 · Copy
- The unit's own connection string
- 03 · Flash
- Write it to the unit once
- 04 · Watch
- Its data in the live stream
Each unit gets its own key. Nothing shared.
WHAT A DEVICE MAKER GETS
Keys, tokens and status where the device is.
A key per unit
The hub gives each unit its own random key. The unit uses it to sign its own short-lived access tokens.
Testing tokens that say when they end
Short-lived tokens for testing, labelled with their expiry.
Longer tokens when you need them
Device tokens of 30, 90, 180 or 365 days, for people with the right to deploy.
Changes that ask first
Regenerating the secondary key and switching a device off both ask before they act. Switching off takes effect at the next Deploy, and keeps the keys.
Keys kept from the wrong hands
Key strings are hidden from people without the right to deploy.
The protocols IoT Hub speaks
MQTT, AMQP or HTTPS, all with the same access token.
IF PILOTS STALL ON CREDENTIALS
For teams who ship the hardware.
Equipment makers
Run a pilot at a customer site without a credentials project first.
Integrators
Connect a mixed set of units, each with its own key, in the customer's Azure.
Firmware engineers
A reference flow for connect, back off and recover, written for the hub your device talks to.
NEXT TO DEVICE PLATFORMS
Standard IoT Hub on the device side. A whole workspace behind it.
Your firmware talks to Azure IoT Hub the standard way. What changes is what sits behind the hub: queries, API routes, apps and AI in the same workspace, in your customer's Azure.
- A firmware reference flow: clock sync, connect over MQTT and TLS, back off with jitter, recover.
- Firmware updates stay on your own channel. OpenX delivers none.
- Device data feeds warm queries and API routes from the first reading.
IN THE FIELD
From the bench to a customer site.
A five-unit pilot
- 01Add five connections and deploy.
- 02Flash each unit with its own connection string.
- 03Watch all five in the live stream.
A unit gone quiet
- 01A unit stops reporting.
- 02Its firmware backs off and retries, then waits to recover.
- 03When it reconnects, its readings show in the live stream again.
Sell the monitoring
- 01Device data is served through API routes.
- 02Licenses sells a monitoring plan per site.
- 03The plan's rights open those routes.
WHAT GETS CONNECTED
Devices that report back.
MACHINE BUILDERS
Monitoring units on equipment at customer plants.
LAB EQUIPMENT
Instruments and cleanroom sensors reporting into a customer's workspace.
ENERGY AND BUILDINGS
Meters and building sensors across sites.
Flash once. Start reading.
Start with a simulated device, then connect your first pilot unit.
MORE OF OPENX
AI governance →
Over MCP, AI proposes and a person accepts. Only a person deploys.
OpenX MCP Server →
A few tools let any MCP-capable AI read your workspace and propose changes to it.
API Manager →
Your workspace is already an API. Decide who may call it and what each caller reaches.
Warm queries →
Save a question over live data and serve the answer to dashboards, apps and AI.
Provenance →
A record you can prove, kept in your own cloud, with corrections and signatures.
Your cloud →
Connect your Azure, build the landing zone, and the rest of OpenX runs inside it.
Databases →
A Cosmos DB store in your subscription, with a governed API for each container.
App Identity →
Your own sign-in directory, identities for your jobs, and access in one window.
Licenses →
Sell what you build on your own Stripe, and turn a subscription into a plan's rights.
IoT →
IoT Hub and Data Explorer in your Azure, feeding queries, APIs and AI.
Communications →
Send mail through your own relay, with the password in your vault and sends on record.
App building →
Data, sign-in, access, an API and billing: your app's backend, already there.