Appearance
Platform nomenclature #
Dataplicity uses a small set of product names repeatedly. This page is the map of those names. Read it once, then keep it open while you follow a walkthrough.
If you only remember four ideas, remember these:
- A Device Class is the product model you design once.
- A device is one physical unit of that model.
- A Product Application is optional customer workflow around one or more classes.
- A Customer Portal is where the buyer operates their allocated devices and applications.
For the deeper Software / OS / agent vocabulary, see Application and Software glossary.
How the pieces connect #
Read the diagram left to right:
- You define the hardware product as a Device Class.
- You optionally attach Class Software and design streams, actions, and the device page.
- You provision a device into that class in the OEM organisation.
- You optionally author a Product Application, publish a version, and attach it to your portal.
- You allocate the device to a customer.
- The customer Admin places it on a Network, which makes it Enabled.
- The customer uses live controls on the device page, and any attached application workplace on the network.
The two workspaces #
| Workspace | Who uses it | What it is for |
|---|---|---|
| OEM / Engineering workspace | Your staff | Device Classes, Software, provisioning, allocation, Product Application authoring, fleet support |
| Customer Portal | Your customers | Operate only the devices and application instances allocated to them, on your hosted domain |
A portal user does not receive OEM Remote Shell, fleet-wide logs, or Software rollout controls. Those stay in your organisation unless you deliberately grant a separate support path.
Core terms #
Organisation and tenancy #
| Term | Meaning | Not the same as |
|---|---|---|
| Organisation | An account boundary with users, roles, and billing | A Network or a Device Class |
| OEM organisation | Your vendor organisation that designs products and provisions devices | The customer's organisation |
| Customer organisation | A downstream buyer created under Customer journey > Customers | A tag or a Network |
| Customer Portal | Branded customer application hosted on your *.dvcmgr.com domain | The OEM dashboard |
| Allocate to customer | Audited ownership handoff of a device from OEM to a customer organisation | Installing the agent or changing the Device Class |
Hardware product definition #
| Term | Meaning | Not the same as |
|---|---|---|
| Device Class | Reusable definition for one hardware product line: architecture, Software, streams, actions, settings, inventory, and customer device UI | A customer, site, or temporary filter |
| Device | One registered Linux unit running the Dataplicity agent | The Device Class it belongs to |
| Stream | Stable named value a device publishes through the local agent broker | A Product Application record |
| Action | Lightweight one-off request a device can perform | A durable Product Application command |
| Setting | Lasting desired/reported configuration on a device | An action that already ran once |
| UI Designer / device page | Layout shared by every unit of the Device Class | A Product Application records page |
Use a Device Class when units share a product contract. Use tags, networks, and customer records for ownership, place, and rollout cohorts.
Software on the device #
| Term | Meaning | Not the same as |
|---|---|---|
| Software | Device Class workspace for containers, I/O, OS, builds, and delivery | A Product Application |
| Container / Class Software | Optional OCI workload Dataplicity installs for the class | Your entire Linux image |
| Software Build | Pinned set of container versions, optionally with an OS image | Complete appliance firmware unless you deliberately equate them |
| Agent | On-device Dataplicity connection and product runtime | The container that captures sensors or video |
A product can publish streams without Class Software. Class Software is only needed when Dataplicity should install and version an OCI image for that class.
Product Applications #
| Term | Meaning | Not the same as |
|---|---|---|
| Product Application | Versioned customer product: models, rules, processes, commands, pages, and optional offline datasets around one or more Device Classes | Class Software, or a generic web app host |
| Binding / role | Named job a Device Class performs inside an application, such as bay, entry_camera, or controller | Creating a second Device Class |
| Product Version | Immutable published snapshot of an application | The editable draft |
| Product Instance | One Product Version running for one customer | The OEM draft or another customer's instance |
| Process | Durable multi-step workflow that can wait, branch, and resume | A Linux process or container |
| Command | Durable invocation of a bound device action with lifecycle and result state | A bare Device Class action |
| Rule | Immediate reaction to a reading, record change, or event | A Process that must pause and resume |
When the customer only needs this device's readings and knobs, a Device Class may be enough. Add a Product Application when you need customer records, tenancy, durable workflow, or multi-device composition.
Place and device state in the portal #
| Term | Meaning | Not the same as |
|---|---|---|
| Network | Customer place or operating boundary, such as a farm, warehouse, venue, or cabinet | A Device Class, VLAN, or VPN |
| Ready | Online claimed device that has not been assigned to a Network yet | Broken or offline |
| Enabled | Device assigned to a Network and eligible for app-active site work | Merely Online in the OEM fleet list |
| Controls | Device page for one unit's vendor UI, live data, and permitted actions | The network-wide application workplace |
| Workplace | Network-scoped application surface for all roles at that place | One device's Controls tab |
One concrete example #
Using the SiloSentry camera walkthrough names:
| Layer | Example |
|---|---|
| Device Class | SiloSentry Camera |
| Class Software | video-gen-sim |
| Device | North Yard Camera |
| Customer organisation | Acme Farm |
| Network | Site Entrance |
| Optional Product Application | Camera access / two-camera entrance inspection |
| Binding roles | entry_camera, lobby_camera |
Path:
SiloSentry Camera → provision North Yard Camera → allocate to Acme Farm → place on Site Entrance → customer opens Controls for live view.
If you also attach the Camera access application, the same Device Class can be bound twice as entry and lobby roles inside that application without becoming two different hardware products.
Common mix-ups #
| People often say | Usually they mean | Correct Dataplicity term |
|---|---|---|
| "the app" | Customer portal product, or the on-device container | Product Application or Class Software - pick one |
| "firmware" | Container build, OS image, or modem firmware | Name the exact layer |
| "site" | Customer place in the portal | Network |
| "device type" | Shared product definition | Device Class |
| "give the customer the device" | Ownership handoff after provisioning | Allocate to customer |
| "activate the camera" | Place a Ready unit on a Network | Assign to a Network so it becomes Enabled |
Where to go next #
- How it works - outbound connection and agent architecture
- Devices - the device record
- Customers, sites, and ownership - customer and place context
- Device Classes - design the hardware product contract
- Product Applications - add customer workflow
- Application and Software glossary - Software, builds, OS, and agent terms
- Build your first connected product - prove the full path
- Build a camera and CCTV product - worked Path A using these names