Skip to main content
Creating a product is the first thing you do as a manufacturer. It’s a 4-step wizard, and the choices you make here shape everything downstream — your firmware, your dashboard, your API, and what your users experience. This guide walks each step and, more importantly, how to think about each field.
The wizard: AI Generator → Basic Info → Commands & Actions → User Info & Metadata. You can skip the AI step and fill everything by hand.

​
Step 1 — AI Generator (optional)

Describe your product idea in plain language and the AI scaffolds a starting point for you — basic info, a command set, database tables, and dashboard widgets — which you then refine in the following steps. How to think about it: treat the output as a first draft, not the final answer. It’s fastest when your product is a common pattern (a smart light, a thermostat, a sensor node). Describe what the device does and what it reports, e.g. “a soil-moisture sensor that reports moisture and temperature and can trigger a water pump.” Then review every generated command and field in the next steps — you own the result. Prefer full control? Skip this step and build from scratch.

​
Step 2 — Basic Info

The product’s identity. This is how it appears everywhere — the Studio, the marketplace, and your users’ apps.
FieldExampleHow to think about it
Product NameSmart ThermostatThe user-facing name. Make it clear and specific — what the thing is, not a codename. It shows on cards, dashboards, and the marketplace.
CategoryHome, Climate, Sensor, …Pick the closest match. It drives discovery in the marketplace and how the product is grouped. Choose the category a buyer would search.
Description—One or two sentences on what it does and who it’s for. This is your pitch on the marketplace listing — lead with the value, not the internals.
Model NumberTH-1000Your internal/product SKU. Use a scheme you can extend across a lineup (e.g. TH-1000, TH-2000). This is your reference, not the user-facing name.
Firmware Version1.0.0The starting firmware version. Use semantic versioning (major.minor.patch) so OTA updates and version tracking stay clean over time.
Icon—A visual shorthand shown across the platform. Pick one that reads at a glance for your category.
Name and category are the two fields buyers see first in the marketplace. Spend a moment on them — they affect discovery and trust more than any internal field.

​
Step 3 — Commands & Actions

This is the heart of the product: the command vocabulary your device understands. It’s organized as a tree — Commands → Actions → Parameters — and it’s what dashboard controls send and what your firmware handles.

​
The structure

Command            (a named capability, e.g. "GPIO_MANAGEMENT")
  └─ Action        (a specific operation, e.g. "ON" / "OFF")
       └─ Parameter (an input to the action, e.g. gpio, status)
Each Command has a name, an API Endpoint, a Method, and a description. Each Action sits under a command. Each Parameter has a name, type, default value, and description.

​
How to think about it

  • Model capabilities, not wires. A command should describe what the product can do (“Operate”, “SetBrightness”), not a raw pin. Keep names stable — they become your public contract with firmware, dashboards, and the API.
  • Actions are the verbs. Under one command, actions are the distinct operations (ON / OFF, START / STOP). If two operations are truly different, they’re different actions.
  • Parameters are the inputs. Add a parameter only when the action needs a value from the caller (a brightness level, a target GPIO, a duration). Give each a sensible default so a basic call works without every field.
  • Design for the dashboard and firmware together. Every command you define here is what a control widget will send and what your setUserCommandHandler will receive. If a command is awkward to send from a Button or handle in firmware, simplify it now.
  • Start small. Define the commands you’ll actually use first. You can add more later — but renaming a command after devices ship is painful.
These commands power several Studio tools: Command Flow visualizes them, the Testing Suite exercises them, and Voice Assistants map traits to them.

​
Step 4 — User Info & Metadata

The finishing details for the people who use the product.
FieldHow to think about it
User instructions / manualPlain-language guidance your end users see. Write it for a non-technical owner: how to set the device up, what it does, what to do if something’s wrong.
Metadata (key / value)Custom attributes on the product — e.g. warranty_period → 2 years, voltage → 5V. Use it for structured facts you or integrations may want to reference later.
How to think about it: the manual is the first thing a confused user reads — keep it short and task-focused. Metadata is for structured facts (specs, warranty, compliance), not prose.

​
After you finish

Saving the wizard creates the product and drops you into the Product Development Studio. From there you’ll design the dashboard, set up the database, flash firmware, and publish. If you used the AI step, review what it generated in each Studio tab before shipping.

Tour the Studio

Every tool in the product workspace.

Design the dashboard

Build the UI your users get.

Set up the database

Store your device’s data.

Flash firmware

Get a device online.