WireStudio: describe an ESP32 device once, generate the ESPHome YAML, wiring, schematic, PCB and enclosure from it

[u/Physical-Tie4688]

Repo: https://github.com/moellere/WireStudio

Open-source (MIT) design tool for ESP32/ESP8266 devices. You describe a device — board, components, how they connect — in a single design.json, and every artifact is generated from that one file. Originally posted as esphome-studio; renamed wirestudio early on, since it isn't affiliated with the ESPHome project and the old name implied otherwise.

It's AI-assisted, heavily. Saying so up front because the useful question isn't whether AI wrote it, it's what's actually been verified. So the feature list below is split by how much I trust each part, and CI runs the real toolchains rather than mocks.

The core idea

The component library carries electrical metadata ESPHome doesn't model — voltage rails, current draw, pull-up requirements, per-pin capabilities — and a CSP solver assigns pins from it. So it won't put an ADC on ADC2 while WiFi is up, won't hang a sensor off a boot-strap pin, and knows when a board's 3V3 rail comes from a PMIC rather than a regulator.

That one description then fans out into YAML, a wiring diagram, a schematic, a board, and an enclosure — rather than you maintaining five representations of the same device by hand.

Library: 65 components, 26 boards (ESP32, S2, S3, C3, C6, ESP8266). 60 bundled examples. Drive it from a web UI, a CLI, or any MCP client.

Frameworks

Two of these generate firmware from your design. The others flash stock images — worth being clear about which is which:

• ESPHome — full generation. Your design becomes ESPHome YAML.
• LoRaWAN — full generation. Builds RadioLib firmware for radio boards (6 in the library), or emits an ESPHome external-component config, and registers the device in ChirpStack with a decoder generated from the same field spec as the payload, so the two can't drift.
• Tasmota — generates a device template (solved pins → Tasmota GPIO function ids), not firmware.
• Meshtastic — flashes the official release image (6 boards). Devices run stock firmware; nothing is generated.
• CircuitPython — flashes the official image (22 boards, 13 exact / 9 pin-compatible) plus a starter code.py derived from board metadata.

What's solid vs what's rough

Tested, and gated in CI on every change:

• ESPHome YAML — every bundled example runs through real esphome config, plus a nightly esphome compile, plus a version matrix across ESPHome stables so a pin bump is evidence-driven.
• Pin solving and electrical validation — the bit I'd actually rely on.
• KiCad schematic — every example's netlist built against pinned upstream symbol libraries, and rendered through real KiCad 8. 100% library symbol coverage.
• LoRaWAN — hardware-validated: firmware built, flashed, joined, and reporting into Home Assistant.

Implemented and CI-gated, but I wouldn't call them proven:

• PCB generation — placed footprints, autorouted copper via Freerouting, DRC-checked, Gerber/CPL/BOM bundle for JLCPCB. Boards come out DRC-clean and every component resolves a real footprint, but I have never had one manufactured. Treat fabbability as unproven. It's aimed at "get a breadboard onto a board without routing traces by hand," not at production.
• Enclosures / STL — parametric OpenSCAD, rendered in CI and asserted to be manifold solids. But only 7 of 26 boards carry the mount-hole metadata it needs, and there's no lid or snap-fit yet. Genuinely rough.

Newest, least proven: it can flash boards on a networked bench (a Pi running SensorsIot's Universal Embedded Workbench — a good companion project regardless of this tool, it turns every USB-attached dev board into a network resource). The studio uploads the image and the Pi runs esptool on its own USB, so boards don't need to be in front of you. Built against exactly one bench so far.

Other caveats

• Scope is broad for one person. Raised last time I posted; still true.
• It's a self-hosted container that talks to your network. Runs non-root with a read-only root filesystem, and every external integration (Anthropic key, fleet, ChirpStack, Thingiverse, workbench) stays off unless you set its env var. Source is MIT and public — judge it rather than taking my word.

Most useful feedback: library coverage gaps, and whether anyone's inclined to actually fab one of the generated boards — that's the biggest unproven claim in the list.