Living Lights / Firefly System
Outdoor low-voltage lighting designed to imitate living fireflies.
Living Lights is an active prototype combining embedded firmware, electronics, organic behavior design, modular outdoor hardware, and a careful path toward future event, rental, and product use. It is not a Christmas light controller. The goal is to create the quiet illusion that the lights are alive.
Early behavior prototype
Active prototypes
Build history and physical observations are owner-reported. Done, In progress, Planned and Future labels retain their original scope.
The vision
Create the feeling of real fireflies—not decorative blinking lights.
The observer should stop thinking about LEDs and begin wondering whether the lights are making their own decisions.
The project is evaluated by perceived realism rather than by how many effects it can perform. Natural fireflies are not a synchronized display. They pause, wake, fade, interact, disappear, return, and vary in intensity. Living Lights is being built around that kind of restrained, believable behavior.
- No synchronized flashing across the habitat.
- No obvious loops or repeated show sequences.
- No easy pattern recognition after minutes of watching.
- Each visible firefly behaves independently.
- Fades, pauses, wake-ups, and quiet periods should feel intentional.
- The overall habitat should feel alive, calm, subtle, and natural.
Current prototype
Confirmed source state, separated from ideas that remain planned or unproven.
Three-pod ESP32 habitat architecture
The current system uses ESP32 development boards as control pods. Each production pod currently drives eight independent firefly outputs through GPIO and ULN2803A driver hardware. Pod 1 acts as the Habitat Host. Pod 2 is the proven guarded one-pod satellite OTA target. Pod 3 remains an intentionally protected control pod.
Hardware architecture
A human-readable map of what each physical layer is responsible for.
Control pod
An ESP32 runs the behavior system, controls outputs, reports pod identity and firmware state, and provides the local Firefly Lab control surface.
LED branches and nodes
Each current branch presents independently controlled firefly points. The physical hardware is meant to disappear into the environment so the observer sees only the glow.
Power system
The project uses low-voltage DC architecture. Production direction favors a fixed-output, enclosed, mechanically mounted supply rather than exposed adjustable bench modules.
Driver stage
ULN2803A driver hardware sinks current for the eight standard output channels, keeping the ESP32 from directly carrying the LED load.
Harnesses and connectors
Documented wiring, modular connectors, strain relief, and branch separation are being used to reduce clutter and make future replacement or repair practical.
Addressable test path
A separate level-shifted GPIO4 path supports ten low-brightness addressable nodes for Pixel 1–10 calibration without replacing the proven eight-output renderer.
Outdoor enclosure
Weatherproofing, cable entry, condensation control, mounting, fuse access, and serviceability are active design considerations. No certification claim is made.
Sensors
Reserved photoresistor and PIR inputs create a path toward darkness awareness and motion-aware habitat behavior after the core system is stable.
Modular pods
Multiple pods can form one larger habitat while preserving local pod identity, independent outputs, and controlled firmware deployment boundaries.
Firmware architecture
The software is built around organisms and habitats rather than a global lighting effect.
Each firefly carries its own state
The firmware models individual fireflies with separate activity, energy, personality, timing, and interaction state. Their visible behavior emerges through constrained decisions, fades, waiting periods, and weak social influence rather than through one master looped pattern.
- Independent state and decision timing per firefly.
- Organic fade, wait, wake, and quiet behavior.
- Randomized variation bounded by rules and internal state.
- No global show sequence controlling every light.
- Scalable separation between simulated organisms and physical outputs.
- Calibration and test modes kept separate from natural behavior.
Versioned pods with guarded updates
The system tracks pod identity and firmware identity so source builds are not confused with what the live hardware actually reports. This matters especially during OTA work, where transferred firmware is not considered applied until the target pod reboots and reports the expected live identity.
Build log
A public development record designed to be extended as hardware, testing, and product direction mature.
First ESP32 hardware bring-up
- What changed
- The PlatformIO project compiled, uploaded, booted, and reached firmware setup on physical hardware.
- Problem being solved
- Prove that the development toolchain and first controller could execute the project firmware outside simulation.
- Materials/components used
- ESP32 development board, PlatformIO firmware project, USB connection, serial monitor.
- Business or product-development purpose
- Established a working embedded foundation before investing further in branches, enclosures, and field hardware.
- Next step
- Connect the driver hardware and verify each firefly output individually.
Eight-firefly modular branch completed
- What changed
- The first fully wired branch was completed with eight independently controlled fireflies and modular connectors.
- Problem being solved
- Move beyond loose breadboard wiring while preserving independent control and replaceable branch hardware.
- Materials/components used
- LED firefly branch, ULN2803 driver, JST-XH connectors, magnet wire, lacing wire, documented harness pinout.
- Business or product-development purpose
- Created a repeatable branch-construction baseline that can reduce future assembly time and improve serviceability.
- Next step
- Run full behavioral firmware and observe whether the hardware disappears behind the firefly illusion.
First organic colony behavior observed
- What changed
- Hardware bring-up mode was disabled and the complete behavior system ran on the first eight-firefly branch.
- Problem being solved
- Determine whether the system behaved like an emergent colony rather than a deterministic sequence.
- Materials/components used
- Completed branch, ESP32, ULN2803 driver, natural behavior firmware, serial and visual observation.
- Business or product-development purpose
- Validated the central product premise: independent lights could create irregular, watchable behavior without an obvious loop.
- Next step
- Run longer observation sessions and confirm that every firefly can participate without making the habitat feel busy.
Behavior baseline and connected-habitat direction
- What changed
- Observation notes recorded distinct personalities, non-deterministic behavior, small conversational exchanges, and a calmer overall habitat.
- Problem being solved
- Refine participation without turning the system into frequent blinking or a visible animation routine.
- Materials/components used
- Firefly Lab live controls, behavior firmware, battery-powered observation setup, repeated resets and long viewing sessions.
- Business or product-development purpose
- Moved the project from a simple electronics prototype toward an ambient object worth observing for extended periods.
- Next step
- Preserve the believable baseline while expanding habitat architecture, deployment reliability, and documentation.
Guarded OTA baseline and ten-node addressable bench path
- What changed
- The project recorded two confirmed guarded Pod 2 OTA successes and prepared a distinct Pod 1 ten-node addressable calibration build.
- Problem being solved
- Update remote hardware safely while keeping a control pod untouched, and test addressable nodes without disturbing the proven renderer.
- Materials/components used
- ESP32 pods, ESP-NOW relay path, Pod 1 Host UI, SN74AHCT125N level shifter, 220-ohm series resistors, GPIO4 addressable data path.
- Business or product-development purpose
- Improved maintainability and created a controlled path toward richer branch behavior without overstating unproven field results.
- Next step
- Flash only the explicit Pod 1 addressable bench build, confirm its live identity, and test Pixels 1–10 individually at the existing brightness cap.
Problems being solved
The work is not only making lights turn on. It is solving the practical gaps between an effect, an installation, and a believable product.
Making the light feel organic
Balancing individuality, quiet periods, fades, delayed activation, and weak interaction without making the habitat feel random or chaotic.
Avoiding repeating patterns
Preventing a viewer from recognizing a loop, synchronized pulse, or fixed sequence after watching for several minutes.
More lights without one global show
Keeping behavior independent as the habitat grows from eight-output pods toward larger multi-pod and future addressable systems.
Low-voltage outdoor wiring
Managing shared power, grounding, connectors, cable protection, enclosure entry, strain relief, and service access in a practical installation.
Pod identity and version tracking
Separating source build identity, expected update identity, and actual live hardware identity so the system never claims an update that did not boot.
Guarded OTA updates
Proving one satellite at a time while preserving manual apply, exact identity confirmation, and an untouched control pod.
Cleaner, serviceable harnesses
Replacing fragile loose wiring with documented branches, modular connectors, mechanical support, and repeatable construction methods.
Addressable node testing
Validating direction, color order, skipped nodes, duplicated nodes, flicker, and data integrity before addressable hardware is connected to natural behavior.
Separating prototype from promise
Documenting what is proven, what is in progress, and what remains future work before commercial testing or customer-facing claims.
Business purpose
A careful commercial direction, not a claim that the prototype is already a finished product.
Potential directions
Living Lights is being developed with possible commercial use in mind. The immediate purpose of that direction is to guide durability, modularity, documentation, transport, setup, repair, and repeatable deployment decisions while the prototype is still being tested.
Roadmap
Progress is intentionally staged so expansion does not outrun reliability or evidence.
Stage 1 — Bench prototype
Compile and run firmware, switch eight independent outputs, validate driver hardware, and establish a repeatable branch.
Stage 2 — Outdoor pod prototype
Package the controller, power, harnesses, and branches into modular hardware suitable for controlled outdoor observation.
Stage 3 — Organic behavior refinement
Continue long observation, preserve distinct personalities, improve participation, and avoid visible repetition or excessive activity.
Stage 4 — Addressable node testing
Calibrate a separate ten-node chain, verify direction and color behavior, and record physical data integrity before natural routing.
Stage 5 — Waterproofing / deployment testing
Evaluate enclosure sealing, condensation, cable entry, strain relief, mounting, fuse access, runtime, and repeat outdoor setup.
Stage 6 — Event demo / rental test
Run a limited real-world demonstration to study transport, setup time, viewing distance, guest response, and operational support needs.
Stage 7 — Productization research
Study manufacturing, enclosure standards, certification needs, documentation, pricing, liability, support, and small-batch feasibility.
Gallery / evidence
These are original project photographs documenting actual hardware, wiring, firmware, and outdoor observation. The final public demonstration remains intentionally unclaimed until it exists.
Pod wiring
A working enclosure prototype with power conversion, controller hardware, and branch wiring being organized for safer service and repeatable assembly.
Prototype evidence
Control board
An ESP32 development board on a screw-terminal carrier, part of the move from temporary breadboard work toward cleaner bench and enclosure connections.
Hardware development
LED branches
A small light node on thin twisted wire, built so the physical branch can recede from view while the glow appears to float among plants.
Branch construction
Outdoor test
An early low-light observation used to judge placement, scale, viewing distance, environmental distraction, and whether the light points feel independent.
Not a final installation
Wider habitat view
A broader observation frame showing the prototype in its real surroundings. It records viewing distance, competing landscape lights, placement density, and the need for the firefly effect to remain subtle without disappearing.
Field observation
Addressable bench test
The separate level-shifter path prepared for GPIO4, regulated 5V, shared ground, and controlled ten-node calibration without replacing the proven GPIO/ULN system.
Calibration hardware
Firmware UI
The browser-based Firefly Lab control surface used during development to inspect habitat behavior, pod state, diagnostics, and guarded firmware workflows.
Development interface
Harness serviceability
Color tags, branch labels, and separated conductors support troubleshooting and repeatable field connections as the prototype becomes more modular.
Assembly refinementFinal demo
A polished three-pod installation or limited event demonstration will be added only after the hardware, deployment process, and behavior remain stable.
Documentation
The current technical truth lives in the private/source project documents. Public subpages can be added later without restructuring this hub.
Current State
Confirmed live hardware, source identities, OTA posture, renderer state, known cautions, and next recommended step.
docs/CURRENT_STATE.mdHardware Notes
Power, driver, mapping, branch, connector, addressable bench, and future enclosure architecture.
docs/HARDWARE.md + HARDWARE_ARCHITECTURE.mdFirmware Notes
Behavior philosophy, renderer boundaries, pod identity, OTA safeguards, and versioned implementation history.
README.md + docs/NOTES.mdTesting Notes
Bench procedures, OTA confirmation rules, renderer diagnostics, and field-observation checks.
docs/TESTING.mdBuild Log
Dated public entries covering hardware bring-up, behavior milestones, modular branches, OTA, and addressable testing.
Changelog
Version-by-version record of firmware identities, behavior-preserving changes, deployment rules, and confirmed milestones.
docs/CHANGELOG.mdContact
Project questions, collaboration, practical deployment discussion, or future rental/product interest.
Prototype disclosure
Living Lights is an active prototype project. It is not yet a finished consumer product, certified outdoor electrical product, or official commercial offering. Specifications, firmware, hardware layout, and product direction may change as testing continues.