Documentation

Appearance

Device classes ​

A device class models a product line. It groups identity, deployment mode, hardware and architecture compatibility, provisioning defaults, feature composition, firmware context, and device-page layout.

Use a class when a product cohort shares lifecycle configuration, not merely because devices need the same temporary filter. Use tags for environment, site, customer, and rollout cohorts.

Current Dataplicity device classes for an edge gateway, retail controller, and environmental sensor
Device classes model distinct production hardware and deployment cohorts.

Design a class ​

Before creating a class, document:

  • product identity and short code
  • managed appliance or bring-your-own-OS deployment model
  • supported architectures and hardware profile
  • default provisioning behaviour
  • feature and microservice composition
  • firmware policy where that module is enabled
  • operator-facing device layout and actions

Create a staging class first. Provision representative hardware, verify the agent and feature heartbeat, confirm remote support, and test upgrade and recovery paths.

Change safely ​

Class changes can affect every device that resolves configuration from the class. Separate editable presentation fields from identity and compatibility decisions that downstream provisioning, licensing, firmware, and customer records may depend on.

Retire an obsolete class instead of reusing its identity for a different product. Before retirement, inventory remaining devices, active provisioning paths, firmware assignments, licence records, monitors, and customer links.

Once a class grows past 20 devices, peer fingerprints become statistically meaningful, so Device Class Pulse can learn what normal looks like for that product line and surface aberrations that often point to real problems, without a hand-maintained gold-state profile.

Troubleshooting ​

  • Device received the wrong configuration: inspect provisioning key, explicit class override, and organisation default class.
  • Feature absent: verify class feature assignment, release target, architecture, and device heartbeat.
  • Device missing from a rollout: check class, firmware eligibility, network, tags, and current bundle.
  • Action hidden: check class UI configuration and the user's effective permissions.

Availability of class-related modules depends on organisation configuration. Your organisation administrator can confirm which modules are enabled for your team.