PRIZM Cloud

PRIZM Cloud is where you register your hardware, draw the application it runs, and watch the data come back. Each sidebar item is one piece of that chain, and the pieces depend on each other in a specific order. This page explains how they relate; each section links to the detail.

How the pieces fit together

Devices are grouped into a bundle. A blueprint is deployed to that bundle, and every device in it starts running the app. The app emits values into fields you defined beforehand. Dashboards and integrations read those fields back out.

Devices and bundles

A device is one board registered to your company. A bundle is a named group of devices.

The relationship is what makes deployment work:

• A device belongs to at most one bundle. A bundle holds any number of devices.
• Applications are deployed to a bundle, never to an individual device — so a device that is in no bundle can never run one, however healthy its connection.
• A device added to a bundle that already has an app starts running that app immediately. This is what lets one deploy reach a thousand boards.

If you have a single device, put it in a bundle of one. That is the expected pattern, not a workaround.

Fields and blueprints

A field is a named data channel, defined once per company rather than per device. A blueprint is your application: a graph of nodes, drawn on the Blueprint Editor canvas, that reads sensors and sends results to the cloud.

They meet at the Identifier. A blueprint sends each value under an identifier, and PRIZM Cloud matches it to a field of that name.

• Fields must exist before the app runs. A value whose identifier has no matching field is dropped — not stored, not queued, and nothing about the device or the blueprint looks wrong.
• Because fields are company-wide, a thousand devices reporting temperature all write to the same field. You define it once.
• A field has one data type. Send a value the field’s type cannot hold and you are relying on undefined behaviour.

This is why fields come before deploying, not after.

Deployed apps

Ship in the Blueprint Editor compiles the current blueprint and pushes it to a bundle you pick. See Ship.

• A bundle runs one application at a time. Deploying again replaces what its devices are running.
• The bundle keeps a deployment history, which is what you roll back to when a new version misbehaves.
• Devices that join later pick up whatever the bundle is currently running.

Dashboards and integrations

Everything above exists to produce field values. There are three ways to read them back:

• Dashboards — widgets you arrange yourself. A widget’s data source can be a single device or a whole bundle, so the same grouping you deploy with is the grouping you monitor with. The Widget reference covers what each widget type needs.
• Webhooks — PRIZM Cloud calls your endpoint as values arrive.
• REST API — query field data from your own applications.

All three read the same fields, and none of them can show data older than your data retention window.

The order to build in

The dependencies above only allow one sensible order:

1. Register your devices — nothing else can reference a board PRIZM Cloud does not know about.
2. Create a bundle and add them to it — this is what a deploy can target.
3. Define your fields — before anything sends, or the values are dropped on arrival.
4. Draw your blueprint and deploy it to the bundle — every device in the bundle starts running it.
5. Build a dashboard, or wire up a webhook or the REST API — read the values back.

New to all of this? The 4-minute quickstart walks steps 1 to 4 with a video for each.

More about PRIZM Cloud →