Building a smart device should feel as approachable as building a web app.

Chipwright turns one declarative device definition into firmware, a cloud API, tests, docs, a Matter device, and a signed package. It runs as a live digital twin before you own any hardware.

Or search “Chipwright” in the Extensions view.

device.yaml the single source
device:
  name: smart_thermostat
  category: thermostat
capabilities:
  temperature_sensor: { type: sensor, unit: celsius,
                        range: { min: -20, max: 50 } }
  hvac:               { type: actuator,
                        modes: [heating, cooling, off] }
connectivity: { protocols: [matter, thread, bluetooth] }
  • Firmware interfaceC header
  • Cloud API contractOpenAPI
  • Acceptance testsrunnable
  • Reference docsstatic site
  • Matter devicedevice type
  • Signed packageshareable

One file. Six artifacts.

Everything downstream is generated, never hand-authored separately. Change the definition and every artifact moves with it.

Editor

Design the device in a form, not a spec document.

The Chipwright extension gives VS Code a form-based device designer. It reads and writes your device.yaml, validates while you type, and shows exactly which artifacts your definition produces.

One click writes every generated artifact. Another scaffolds a starter firmware module, already wired to the generated interface, so the first thing you edit is your logic.

  • Live validation against the compiler
  • Generate all artifacts in one action
  • Scaffold firmware wired to the interface
smart-thermostat generated
  • device.yaml authored
  • generated/
  • firmware/device_interface.h
  • cloud/openapi.yaml
  • tests/acceptance/
  • docs/reference/
  • matter/device_type.json
  • firmware/ yours
  • thermostat.c
Definition valid. 6 artifacts up to date.

Simulation

Run the firmware before the hardware arrives.

The digital twin runs your actual firmware SDK and HAL code, not a mock. Sensor signals stay bounded and realistic, and actuators feed back into the world: set a thermostat to heating and the temperature actually rises.

Inject faults to see how your logic handles a stuck, failing, or drifting sensor. The same acceptance tests run against the twin and against a real chip, unchanged.

smart_thermostat twin running
18.0°C
temperature_sensor nominal
30s agodashed: actual valuenow
hvac
fault

A simulation of the twin, running in your browser. The real twin executes your firmware code.

Editor

An assistant that has to compile before it can suggest.

The AI assistant proposes edits to your device definition, and every proposal is checked against the real compiler before it reaches you. You read a change that is already known to build, then you approve it.

Bring your own key. Chipwright works with Anthropic, Gemini, any OpenAI-compatible endpoint, or a fully local model, from the CLI and from chat inside the editor.

Works with

  • Anthropic
  • Gemini
  • OpenAI-compatible
  • Your local model
proposed edit awaiting approval
# capabilities
+ humidity_sensor:
+   type: sensor
+   unit: percent
+   range: { min: 0, max: 100 }
Compiler check passed. 6 artifacts would regenerate.

Nothing is applied until you say so.

Cloud

A fleet backend that comes with the definition.

Registry, telemetry, identity, and rollouts, generated from the same file and running with no external dependencies.

Registry
Every device, its definition, and its current build.
Telemetry
Readings in, plus a device shadow for last known state.
Commands
Dispatch to a device and track what it did.
Identity
Per-device credentials and certificates.
Signing
Firmware images signed before they leave the cloud.
Rollouts
Staged OTA, a slice of the fleet at a time.
signed over the air update SHA-256 + Ed25519
  1. SignThe cloud signs the image before it ships.
  2. VerifyThe device checks the hash and the signature.
  3. ApplyThe image is written and the device reboots into it.
  4. Roll backA build that fails to boot reverts on its own.

Device

Real Matter, real silicon.

Chipwright is proven end to end on an ESP32-C6. Not a diagram of a plan: a board on a desk, reporting from its on-die temperature sensor and commissioned onto a Matter fabric.

New chips arrive through a board support package. The firmware layer is Apache-2.0, so board support can be written and shipped freely.

ESP32-C6 verified end to end
  • Telemetry from the on-die temperature sensor
  • Hardware in the loop testing
  • Matter over Wi-Fi commissioning onto a fabric
  • Signed OTA, applied and verified on device

Distribution

Devices you can hand to someone else.

Marketplace

An app store of signed device packages. Publish yours, install someone else’s, and every package is re-verified at install time.

Extensible hardware

A new chip is a board support package, not a fork. Write the BSP, keep the definition, and the same acceptance suite runs on the new silicon.

Start with the thermostat.

Install the extension, open the reference device, and watch the twin run before you buy a board.

Marketplace chipwright.chipwright
In the editor Search “Chipwright” in the Extensions view.
build from source
$ git clone https://github.com/ChipWright/chipwright.git
$ cd chipwright
$ pnpm install && pnpm -r build