A PoE-powered, modular, network-discoverable I/O node for scare mazes, haunted attractions and escape rooms.
One cable in. Power and data. Pick a power board for the load, pick an IO board for the effect.
Driven by the-pult, or by anything else. The protocol is open and documented, plain HTTP/JSON, MQTT and sACN.
Immersive attractions are full of small, dumb jobs: flicker a ceiling light, trigger a DMX fixture, read a reed switch on a prop door, light a strip of WS2812s behind a wall panel, cut mains to a fog machine. Today each of those is solved with a different box, a different power supply and a different protocol.
OpenHaunt Node is a three-board set that gets power and data from a single Ethernet cable (PoE):
| Board | Role |
|---|---|
| Mainboard | Always the same. Does the network. |
| Power board | Sets the node's power, 12 W to 71 W. Swapping it is how you change PoE class. |
| IO board | Carries its own microcontroller and does the actual effect. |
Every node announces itself over mDNS, describes both boards it carries, and speaks HTTP/JSON, MQTT and Art-Net/sACN. the-pult is the show console built for it: it discovers, adopts and drives nodes. The protocol is not tied to it, though. It is open and documented, so Node-RED, QLab, a Python script or any other show-control software can drive a node directly.
Prototypes validated and tested.
Before building the three-board family, a single-board prototype proves the processor, the network, PoE and the firmware (D37). That prototype, V0, carries the mainboard electronics, an 802.3af PoE module and the IO the first haunt needed: four relays, two PIR inputs, two WS2812 outputs and audio.
| V0.1 | Ordered at JLCPCB on 2026-10-05, brought up and tested (test/firmware) |
| V0.2 | Bring-up fixes and line out. Tested on the bench against the-pult |
| Firmware | 0.5.0: discovery, HTTP and MQTT APIs, effects, audio, pixel strips, broker failover |
| Product boards | Mainboard, PWR-BT4 and IO-LED8 have schematics and layouts in progress |
Decisions D1 to D38 in 10 — Design Decisions record what was chosen and why. Superseded decisions say so at the top of their entry instead of being deleted.
| ⚡ Power | IEEE 802.3af, 802.3at or 802.3bt Type 3/4, by power board. 12 W to 71 W |
| 🔌 Rails | Up to 24 V, 12 V and 5 V, each with a hardware eFuse and V/I/W metering. Every board makes its own 3.3 V |
| 🔗 Connector | Neutrik NE8FAH-LR-DAE etherCON with Halo light ring, discrete Würth 7490220122 magnetics |
| 🌐 Network | 100 Mbit/s Ethernet, W5500 (MAC + PHY) over SPI |
| 🧠 Host MCU | ESP32-S3, dual-core 240 MHz, USB host. Wi-Fi stands by as a fallback on V0 |
| 🎛️ IO MCU | RP2354, dual-core 150 MHz, 2 MB flash, 12 PIO state machines |
| 🔀 Board link | USB full-speed, unchanged across generations |
| 💾 Storage | 16 MB internal flash (firmware, OTA, assets, IO images) |
| 📡 Discovery | mDNS _openhaunt._tcp, with both board types and the power budget in TXT records |
| 🛡️ Isolation | 1500 V (PoE), plus per-IO-board barriers where needed |
docs/ Concept, architecture, per-board design, protocols, decisions
firmware/ ESP-IDF firmware for every node: one image, the module decides what it is
hardware/ KiCad projects
OH_Node_V0_Prototype/ single-board prototype, production files, 3D-printed enclosure
OH_Node_Mainboard/ product mainboard
OH_Node_PWR_BT4/ 802.3bt Type 4 power board
OH_Node_IO_LED8/ first IO board, RP2354
tools/ gnd_reach, return_vias: board analysis scripts
test/ Bring-up firmware for V0.1 (PlatformIO)
Start with 01 and 02. If you want to know why something is the way it is, go straight to 10 — Design Decisions. It exists so that settled questions are not reopened.
| Document | Contents |
|---|---|
| 01 — Product Concept | What it is, who it's for, why three boards |
| 02 — System Architecture | Block diagram, isolation domains, power tree, thermal |
| 03 — Mainboard | etherCON, magnetics, ESP32-S3, W5500, pin allocation |
| 04 — Power Board | PoE variants, rails, eFuses, metering, identification |
| 05 — IO Board | Why the RP2354 is there, the link, firmware update |
| 06 — Board Interfaces | The three connector contracts, descriptors, boot sequence, mechanics |
| 07 — IO Board Catalog | Planned IO boards, from DMX to mains switching |
| 09 — Compliance & Safety | EMC, SELV, radio approval, the mains problem |
| 12 — V0 Prototype | The single-board prototype as built, and its revisions |
| Document | Contents |
|---|---|
| 08 — Firmware & Network | Two processors, discovery, APIs, protocols, Node-RED |
| 13 — Audio | Clips on the node, RTP streams, sound at a stated show time |
| 14 — Pixels | WS2812 strips: effects drawn on the node, or streamed pixels |
| 15 — Brokers | MQTT brokers, and a console that fails over |
| 16 — Standalone Show | A show a console puts on a node, which then runs it alone (designed, not built) |
| Document | Contents |
|---|---|
| 10 — Design Decisions | Why each part was chosen and what was rejected |
| 11 — Open Questions | What still has to be decided |
OpenHaunt is the umbrella project. OpenHaunt Node is the hardware platform in this repository: one mainboard, a few power boards, and a growing family of IO boards. Show control is the-pult, which speaks the node protocol of 08 — Firmware & Network.
Not yet decided. See 11 — Open Questions.