Olsen Automation
Active invention record

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.

See the current prototype Read the development record
Prototype in development ESP32-based Low-voltage outdoor lighting Organic behavior engine OTA firmware roadmap Wedding/event rental potential
Close-up nighttime Living Lights prototype showing several small warm LED points glowing among tomato plants Early behavior prototype
Real project evidence—not a rendering. A close-up field test used to judge brightness, spacing, visible wiring, and whether several independent nodes read as living points of light rather than a decorative string.
Independent behavior Each firefly develops and expresses its own timing rather than following a single show sequence.
No obvious loop Long observation should not reveal a repeating pattern, synchronized flash cycle, or mechanical rhythm.
Modular hardware Control pods, drivers, harnesses, branches, and future node types are designed as serviceable building blocks.
Measured product path Bench work comes first, followed by outdoor reliability, event testing, and only then productization research.

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.

Working baseline

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.

Production renderer GPIO / ULN, eight independent outputs per pod, standard F1–F8 to 1C–8C mapping.
Lighting and power direction Current prototype notes specify 12V firefly strings and a waterproof 12V supply goal, with regulated low-voltage rails used where required.
Modular wiring Branches and controller hardware are separated by documented harnesses and connectors so assemblies can be serviced or replaced.
Optional sensing Photoresistor and PIR inputs are reserved in the firmware architecture but can remain unconnected during prototype testing.

Hardware architecture

A human-readable map of what each physical layer is responsible for.

Control

Control pod

An ESP32 runs the behavior system, controls outputs, reports pod identity and firmware state, and provides the local Firefly Lab control surface.

Visible habitat

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.

Electrical

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.

Switching

Driver stage

ULN2803A driver hardware sinks current for the eight standard output channels, keeping the ESP32 from directly carrying the LED load.

Serviceability

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.

Calibration

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.

Environment

Outdoor enclosure

Weatherproofing, cable entry, condensation control, mounting, fuse access, and serviceability are active design considerations. No certification claim is made.

Future input

Sensors

Reserved photoresistor and PIR inputs create a path toward darkness awareness and motion-aware habitat behavior after the core system is stable.

Expansion

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.

Behavior system

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.
Identity and deployment

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.

Current Host source identity V2.7.9-satellite-ota-baseline-stabilization for the normal Pod 1 build.
Current addressable bench source identity V2.7.9c-pod1-addressable-10-node-bench for the explicit Pod 1 bench environment only.
Guarded satellite milestone Pod 2 has twice completed the one-pod transfer, verification, manual reboot, and exact live-identity confirmation path.

Build log

A public development record designed to be extended as hardware, testing, and product direction mature.

June 27, 2026

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.
June 28, 2026

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.
June 28, 2026

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.
June 29, 2026

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.
July 16, 2026

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.

Behavior

Making the light feel organic

Balancing individuality, quiet periods, fades, delayed activation, and weak interaction without making the habitat feel random or chaotic.

Perception

Avoiding repeating patterns

Preventing a viewer from recognizing a loop, synchronized pulse, or fixed sequence after watching for several minutes.

Scale

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.

Field hardware

Low-voltage outdoor wiring

Managing shared power, grounding, connectors, cable protection, enclosure entry, strain relief, and service access in a practical installation.

Truth

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.

Safety

Guarded OTA updates

Proving one satellite at a time while preserving manual apply, exact identity confirmation, and an untouched control pod.

Assembly

Cleaner, serviceable harnesses

Replacing fragile loose wiring with documented branches, modular connectors, mechanical support, and repeatable construction methods.

Calibration

Addressable node testing

Validating direction, color order, skipped nodes, duplicated nodes, flicker, and data integrity before addressable hardware is connected to natural behavior.

Product discipline

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.

Commercial exploration

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.

Wedding and event rentalsTemporary ambient installations where setup speed, serviceability, and repeatable presentation matter.
Ambient outdoor installationsLonger-running decorative habitats for patios, venues, hospitality spaces, or private outdoor environments.
Garden and pathway lightingSubtle low-voltage decorative placement that prioritizes atmosphere over illumination output.
Prototype product developmentA documented platform for testing enclosure, branch, control, interface, and deployment decisions.
Future small-batch salesA possible later direction only after reliability, safety, assembly, support, and market questions are better understood.

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.

Done

Stage 2 — Outdoor pod prototype

Package the controller, power, harnesses, and branches into modular hardware suitable for controlled outdoor observation.

In progress

Stage 3 — Organic behavior refinement

Continue long observation, preserve distinct personalities, improve participation, and avoid visible repetition or excessive activity.

In progress

Stage 4 — Addressable node testing

Calibrate a separate ten-node chain, verify direction and color behavior, and record physical data integrity before natural routing.

In progress

Stage 5 — Waterproofing / deployment testing

Evaluate enclosure sealing, condensation, cable entry, strain relief, mounting, fuse access, runtime, and repeat outdoor setup.

Planned

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.

Planned

Stage 7 — Productization research

Study manufacturing, enclosure standards, certification needs, documentation, pricing, liability, support, and small-batch feasibility.

Future

Documentation

The current technical truth lives in the private/source project documents. Public subpages can be added later without restructuring this hub.

Internal project document

Current State

Confirmed live hardware, source identities, OTA posture, renderer state, known cautions, and next recommended step.

docs/CURRENT_STATE.md
Internal project documents

Hardware Notes

Power, driver, mapping, branch, connector, addressable bench, and future enclosure architecture.

docs/HARDWARE.md + HARDWARE_ARCHITECTURE.md
Internal project documents

Firmware Notes

Behavior philosophy, renderer boundaries, pod identity, OTA safeguards, and versioned implementation history.

README.md + docs/NOTES.md
Internal project document

Testing Notes

Bench procedures, OTA confirmation rules, renderer diagnostics, and field-observation checks.

docs/TESTING.md
On this page

Build Log

Dated public entries covering hardware bring-up, behavior milestones, modular branches, OTA, and addressable testing.
Internal project document

Changelog

Version-by-version record of firmware identities, behavior-preserving changes, deployment rules, and confirmed milestones.

docs/CHANGELOG.md
Public link

Contact

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.

Contact

Brian Olsen

Oxnard, California brian@olsenautomation.com (626) 524-8156 LinkedIn profile
Email about Living Lights Back to Olsen Automation