Docs
A device here is anything that can send a packet. These pages cover getting the first one in, deciding how much the platform should demand of it afterwards, and driving the whole thing from your own tools.
Get a device talking
Two ways in, depending on what you have on the bench: firmware you wrote, or a blank board.
- Send your first packetBring your own firmware: the one line that gets bytes in over HTTPS, plain HTTP, MQTT, TCP or UDP, and how to claim the board afterwards.
- Browser flasherNo firmware yet? Put MicroPython and a working client on a blank ESP32 over USB, or a .bin on an STM32 over DFU. Nothing to install.
- Provisioning over USBCHIRP-PROV: a four-line UART protocol your firmware answers, so the portal can push Wi-Fi, a claim code and a signing key down the cable. Reference implementations in MicroPython and Arduino.
Decide what to demand of it
The level is not a switch you flip and hope. It is a design you declare, and the platform raises enforcement itself on the first message that proves the firmware can meet it.
- Security levelsThe L0–L2 ladder, the independent Enforce TLS flag, a threat model for each, and how a device climbs without ever going dark.
- L0 — OpenHardware id only, no token. The bench level — plus the hardening you can do without leaving it, including verifying your own HMAC inside the decoder.
- L1 — TokenOne token per device on every message. Removes every off-path attacker; here is exactly who is left.
- L2 — SignedToken plus an HMAC of each payload, on every transport. Integrity on a chip that cannot afford a TLS stack.
- Enforce TLSA per-device flag, armable at any level: plaintext is refused at the door. HTTPS is the one TLS listener today — MQTTS and TLS-TCP are planned and have none.
Build on it
For machines
/llms.txt is the whole platform in one file for an LLM: endpoints, wire formats, the error shape and the page list above. Point an agent at it before it starts guessing.