Guides
  1. device-onboarding

Direct Mode

Direct mode is the bench/dev path. You have the chip plugged into USB and you know the WiFi the device should join. The web flasher writes everything (firmware, cert, WiFi creds) in one pass, the chip joins on first boot, no captive portal involved.

What gets flashed

In one WebSerial session the flasher writes:

  1. Your customer firmware into ota_0. (If you don't have a release yet, the dashboard offers the gateway-provisioning firmware as a placeholder — you'll OTA your real firmware in once you push a tag.)
  2. Per-device mTLS cert into NVS namespace scadable_certs.
  3. WiFi credentials into NVS namespace scadable_wifi. SSID + password come from the form you fill in the dashboard.

Total flash time: 30 to 60 seconds.

Step-by-step

  1. Open the dashboard, click Add Device.
  2. Pick Direct mode in the wizard.
  3. Enter the SSID and password the chip should join.
  4. Connect the ESP32 over USB and click Flash. The web flasher (WebSerial) handles the rest.
  5. When flash completes, unplug the chip from your laptop, plug it into normal power.
  6. Within ~10 seconds the device shows up in the dashboard as online.

That's the whole flow.

When to use this mode

  • Building on the bench. Iteration speed matters; captive portal slows you down.
  • Internal demos where you control the WiFi (your office, a customer call where you're sharing your laptop's hotspot).
  • One-off devices where you'll never re-provision.

When NOT to use this mode

  • Shipping to a site you don't control. WiFi creds get baked into NVS at your bench. If the customer's WiFi password changes, the device is stuck. Use Provisioning mode instead.
  • Multi-unit deploys where each unit needs different WiFi. Tedious to flash each one with different creds.

Forcing the chip back to a captive portal

Holding BOOT for 5 seconds clears the WiFi creds from NVS. On reboot, the chip behaves as if it had been provisioning-flashed: SoftAP comes up, captive portal appears.

Useful when you accidentally flashed dev WiFi creds and now want to ship the unit.

Direct vs Provisioning at flash time

The only on-chip difference is whether NVS namespace scadable_wifi has values written at flash time.

  • Direct: WiFi creds present → boot, read NVS, join WiFi, connect to broker.
  • Provisioning: WiFi creds absent → boot, start SoftAP, wait for end-customer to enter creds, write NVS, then join WiFi.

The mTLS cert path is identical between the two modes. The dashboard's Add Device wizard is the only place you choose.

Limitations today

  • The dashboard doesn't yet support 5 GHz WiFi entry on ESP32 (chip-side limitation; 2.4 GHz only). ESP32-S3 with the right module variant supports 5 GHz.
  • WPA2 personal only. WPA-Enterprise is on the roadmap.
  • The dashboard caches the last SSID/password you entered for convenience. The cache is per-browser and never sent to SCADABLE servers — credentials only ever leave your laptop over the WebSerial wire to the chip directly.

Updated 4 days ago