Device Onboarding

There are two ways to bring an ESP32 online for the first time:

Direct mode — you have the chip on your bench, plugged into USB, and you know the WiFi credentials. The SCADABLE web flasher writes everything (firmware, cert, WiFi creds) at flash time. Chip reboots and joins. Best for development.
Provisioning mode — you flash a small bootstrap firmware (gateway-provisioning) at the factory or your bench, ship the unit to the end-customer site, and the customer walks through a captive-portal WiFi setup on their phone. Best for production deploys where you don't know the customer's WiFi until install day.

Both paths converge: by the end the device has a per-device mTLS cert, knows its broker URL, and is publishing into your namespace.

Pages in this section

Provisioning mode: factory-flash, ship-to-site, customer walks through captive portal.
Direct mode: dev/bench path. Web flasher writes WiFi at flash time, chip joins immediately.
Captive portal experience: exactly what the end-customer sees on their phone.

Quick comparison

	Direct	Provisioning
Who flashes the chip	You (dev)	You or contract manufacturer
Who enters WiFi	You, in the dashboard	End-customer, on a phone via captive portal
WiFi creds stored where	NVS at flash time	NVS after captive portal completes
Time from "click Flash" to "online"	~90s	~90s once portal completed
Customer firmware swap	Immediate (Direct flash overwrites)	After provisioner completes; then OTA pulls customer firmware
Best for	Dev, bench, internal QA	Field deploys, customer sites, OEM products

What both modes share

Per-device mTLS cert minted at flash time by SCADABLE, written to NVS namespace scadable_certs. See Device cert lifecycle for details.
Same broker URL baked into the artifact (mqtts://io.scadable.com:8883 by default).
Same scadable_certs NVS namespace — once provisioned, your customer firmware reads the cert via scadable_init(NULL) and connects.
Same OTA path post-provisioning. Once the device is online, the standard BYOR pipeline governs every subsequent firmware update.

When to pick which

Building on the bench? Direct. You'll re-flash 50 times today; no reason to walk through a captive portal each iteration.
Shipping a product to a customer site? Provisioning. You don't know their WiFi until they plug it in.
Doing internal QA on a "production-like" path? Provisioning. Same code path the real device will hit.
Doing a customer demo where you control the WiFi? Either works; Direct is faster.

Hardware support today

gateway-provisioning v0.1.1 supports esp32 and esp32-s3. esp32-c3 and esp32-c6 are on the roadmap. See Supported devices for the current matrix.