IoT Device Tooling

The second domain option on the wizard’s first step. Pick this and the modules, solutions, and parameters are filtered through the IoT-device lens — they don’t overlap with vehicle control, home datacenter, or edge AI.

Scope: ESP32-family sensor hubs, gateways, panels, developer probes, bus analyzers, home-automation endpoints, plus the surrounding Home Assistant / raw MQTT / Zigbee2MQTT / Matter / standalone-local ecosystem.

Explicitly excludes vehicle/aircraft control — that goes to Vehicle & Aircraft Control. The safety model for a car (motor cutoff, failsafe) is fundamentally different from the IoT model.

One core principle

The adversary in IoT is silent data loss, not visible crash.

When a quadcopter falls out of the sky, you see it. IoT is different: a sensor that drops three hours of data during a Wi-Fi reboot is invisible — until a month later you pull up a chart and notice a gap.

So this domain’s wizard exposes an axis the vehicle wizard does not have: Data Behavior. Every solution must declare five fields:

Field	What it answers
`retention`	Local storage depth (RAM ring / Flash ring / external Flash / SD)
`cache_on_disconnect`	What to do during outage (`drop`, `replay_on_reconnect`, `aggregate_stats`, `timestamp_queue`)
`dedup`	How to suppress chatter (`threshold_change`, `interval_only`, `both`)
`rate_limit`	Upload throttle (`none / 1Hz / 0.1Hz / 0.01Hz / event_only`)
`power_loss_behavior`	Crash recovery (`volatile / persist_state / persist_queue / persist_both`)

Defaults bias toward “don’t lose data” — replay_on_reconnect, persist_state, threshold_change rather than drop, volatile, none. Probe-family solutions (probe_tool) are the exception: local, user-as-consumer, so (none, drop, volatile) is allowed.

Three-axis model

Where Vehicle had three logical chains, IoT instead uses three orthogonal choice axes:

Axis	What it asks	Count
Category	What the device is for	27 across 6 families
Network Profile	How it connects / topology shape	17 presets
MCU Role	The MCU’s job in the topology	5 roles

These three axes are wizard steps 2 / 3 / 4 (Vehicle’s same slots are FormFactor / Topology / Architecture). When a Category locks the NetworkProfile or Role uniquely (e.g. picking lorawan_gateway pins both Profile = LoRaWAN and Role = gateway_bridge), the wizard auto-advances two slots — but Back always lets you return and override.

27 Categories across 6 families

Family	Count	Members
Sensing	7	sensor_hub / env_sampler / presence_detector / energy_monitor / air_quality_station / water_leak_sensor / soil_moisture_sensor
Actuation	4	actuator_controller / status_notifier / lock_controller / irrigation_valve_bank
Bridging	5	mqtt_bridge / ble_scanner_proxy / zigbee_thread_gateway / lorawan_gateway / industrial_bus_bridge
Tooling	4	bus_analyzer / sigrok_probe / uart_debug_probe / esp_prog_replacement
Presentation	3	dashboard_panel / alarm_panel / indicator_bar
Specialty	4	thread_zigbee_endpoint / esp_now_peer / data_logger / industrial_io_bank

The family you pick narrows the NetworkProfile list — picking bus_analyzer, for instance, leaves only the four Wi-Fi profiles (including wifi_captive_local); Zigbee / Thread / LoRaWAN are suppressed entirely.

17 Network Profiles

Grouped by connectivity:

Group	Profiles
Wi-Fi	`wifi_ha_native` (ESPHome native API), `wifi_mqtt_star`, `wifi_esphome_api`, `wifi_captive_local` (pure local AP)
BLE	`ble_gatt_standalone`, `ble_mesh_distributed`, `ble_scanner_proxy_uplink`
802.15.4	`zigbee_leaf` / `zigbee_coordinator` / `thread_leaf` / `thread_border_router` (C6-only), `matter_over_wifi` / `matter_over_thread`
Specialty / long-range	`esp_now_p2p` (router-less), `lorawan_endnode` (SX1276/1262)
Wired	`wired_rs485_modbus`, `wired_can_bus`

Each Profile carries a default chain triple (uplink / downlink / HA publishing) that seeds the solution; you can override in the Parameters step.

C6 is the only chip with 802.15.4. Zigbee coordinator / Thread border router / Matter-over-Thread solutions auto-pin the chip to ESP32-C6 — a hardware fact (only C6 has the 802.15.4 radio).

5 MCU roles

Vehicle has 7 roles (because of paired TX/RX links); IoT compresses to 5 since there’s less cross-board coordination:

Role	What it does	Typical power
`sensor_leaf`	Sample → dedup → uplink → sleep. One-way telemetry.	Battery (Li / AA / coin / solar)
`aggregator_hub`	Fan-in from many sensors (local I²C/SPI/BLE), single uplink, caches on disconnect.	Mains / PoE
`gateway_bridge`	Protocol translation: Zigbee↔MQTT, BLE↔Wi-Fi, RS485↔MQTT, LoRaWAN↔TCP. Stateless.	Mains / PoE
`probe_tool`	Developer-facing instrument, USB-powered, local-only data path.	`usb_only`
`panel_hmi`	User-facing display/input (LCD / OLED / keypad / alarm).	Mains / PoE

The shape of the 27 solutions

Full catalog is in iot-device-tooling-dag-v2.md §6 (private repo, reference only). A representative slice showing how Category + Network Profile + Role compose into a solution:

Solution	Category	NetworkProfile	Role	One-liner
`sensor_hub_solution`	sensor_hub	wifi_ha_native	aggregator_hub	I²C/SPI multi-sensor aggregator, ESPHome native
`presence_mmwave_solution`	presence_detector	wifi_ha_native	sensor_leaf	mmWave presence (LD2410 class)
`energy_ct_clamp_solution`	energy_monitor	wifi_mqtt_star	sensor_leaf	CT-clamp meter, Flash cache + aggregate stats
`water_leak_solution`	water_leak_sensor	ble_gatt_standalone	sensor_leaf	BLE leak alarm, IP67 outdoor, AA battery
`soil_moisture_solution`	soil_moisture_sensor	lorawan_endnode	sensor_leaf	Solar + LoRaWAN, 0.01Hz reporting
`mqtt_gateway_bridge_solution`	mqtt_bridge	wifi_mqtt_star	gateway_bridge	MQTT gateway, RAM ring cache + replay
`zigbee_thread_gateway_solution`	zigbee_thread_gateway	zigbee_coordinator	gateway_bridge	Zigbee coordinator (C6)
`sigrok_logic_analyzer_solution`	sigrok_probe	wifi_captive_local	probe_tool	SUMP / OLS protocol, USB-powered
`alarm_keypad_solution`	alarm_panel	wifi_ha_native	panel_hmi	HA `alarm_control_panel` entity + keypad
`esp_now_sensor_solution`	esp_now_peer	esp_now_p2p	sensor_leaf	Coin-cell + ESP-NOW, no router

What the wizard looks like in this domain

Step	What	Notes
1	Domain = IoT Device Tooling	shared
2	Category	27 entries, picked via 6 families
3	Network Profile	17 entries, usually 3–8 after Category filter
4	MCU Role	5 entries, filtered by Profile
5	Device	chip (D0WD / C6 / S3); skipped if Profile already pinned C6
6	Module	skipped when only one module is compatible
7	Solution	usually narrowed to 1–3 candidates by this point
8	Variant	hardware sub-config of a solution (4ch/8ch relay, LCD/OLED/e-ink, etc.)
9	Parameters	all enums, no free-text (I²C address, Modbus slave ID, LoRaWAN DevEUI, etc.)
10	Review + Build	shared

Vehicle’s wizard runs 7 steps; IoT runs 10. The extras are Category (2), NetworkProfile (3), and Variant (8). All three support auto-skip + Back-to-override: when an earlier choice uniquely determines a step, the wizard advances by two slots, but the Back button always returns to the skipped step, and a top banner reads “we picked X for you — change it?”.

What this domain does not cover

Vehicle / aircraft / drone control — go to Vehicle & Aircraft Control. The anti-pattern to avoid is “use IoT’s actuator_controller to drive a car” — the data-behavior model is wrong for that (IoT fears data loss; vehicles fear a failsafe that didn’t trip).
OTA key management / secure-boot key rotation — lives in a separate security document. The wizard emits firmware skeletons, not signing chains.
RF compliance (FCC / CE / SRRC) — handled per region. The wizard gives you a power profile (mains_jack / battery_li / solar_harvest etc.), not antenna certification.
Microcopy / i18n strings — copy.ts owns those, not the domain definition.

ESP-IDF MCP — User Manual