DEV Community: Arek Mazur

I Built a Smart Meeting Lamp So My Wife Knows When I'm in a Call

Arek Mazur — Wed, 13 May 2026 17:54:41 +0000

There are two types of interruptions during remote work:

the important ones
and the "quick question" that somehow starts exactly when your camera turns on during a meeting

So I decided to build a small smart lamp that sits outside my office and instantly shows whether:

my camera is active
my microphone is active
or I'm free and available

The goal was simple:
before entering the office, my wife can immediately see if I'm:

on a call
talking to someone
recording something
or finally available for coffee

And honestly... it turned into a surprisingly fun ESPHome + Home Assistant project.

Final Result

The lamp changes colors automatically based on my MacBook state:

State	Color
Camera active	Red
Microphone active	Orange
Neither active	Green

Everything is fully local and integrated with Home Assistant.

Demo Video

Technologies Used

ESP32-S3
ESPHome
Home Assistant
WS2812 RGB LED ring
Tinkercad
Bambu Lab 3D printer

Hardware Components

ESP32-S3 Board

I used a tiny ESP32-S3 development board with:

USB-C
WiFi
Bluetooth
native USB support
enough power for ESPHome projects

The size is honestly impressive.

WS2812 LED Ring

The LED ring contains 24 individually addressable RGB LEDs.

This means every LED can be controlled independently using a single DATA pin.

Supporting Components

I also used:

470Ω resistor
470µF capacitor
prototype PCB
female headers

Why the Resistor and Capacitor?

The resistor protects the DATA line from signal spikes.

The capacitor stabilizes the power delivery to the LED ring and prevents random flickering or instability when LEDs suddenly change brightness.

Recommended setup:

470Ω resistor between ESP GPIO and LED DATA
470µF capacitor between 5V and GND

Wiring Diagram

Connections used in the project:

LED Ring	ESP32-S3
5V	5V
GND	GND
DI	GPIO4 through 470Ω resistor

Capacitor:

positive -> 5V
negative -> GND

Soldering the Hardware

I assembled everything on a small prototype PCB.

The ESP32-S3 is mounted using female headers which makes it removable and easy to replace later.

The LED ring wires are also detachable.

Prototype PCB

Top Side

Bottom Side

Installing ESPHome

I installed ESPHome locally on macOS using pipx.

Install pipx

brew install pipx
pipx ensurepath

Restart terminal after installation.

Install ESPHome

pipx install esphome

Verify installation:

esphome version

Creating the ESPHome Project

Create project directory:

mkdir -p ~/esphome
cd ~/esphome

Create configuration file:

nano led-ring.yaml

ESPHome Configuration

The configuration below creates a WiFi-connected RGB lamp exposed directly to Home Assistant.

esphome:
  name: led-ring
  friendly_name: LED Ring

esp32:
  board: esp32-s3-devkitc-1
  framework:
    type: arduino

wifi:
  ssid: "YOUR_WIFI"
  password: "YOUR_PASSWORD"

logger:

api:

ota:
  platform: esphome

light:
  - platform: esp32_rmt_led_strip
    name: "LED Ring"
    pin: GPIO4
    num_leds: 24
    rgb_order: GRB
    chipset: WS2812

Flashing the Firmware

Connect ESP32-S3 using USB-C and run:

esphome run led-ring.yaml

ESPHome:

compiles firmware
uploads firmware
connects the device to WiFi
exposes it to Home Assistant

Home Assistant Integration

Once connected to WiFi, Home Assistant discovered the device automatically.

The LED ring appeared as:

light.led_ring

And that was enough to control it from automations.

Detecting Camera and Microphone Usage

The Home Assistant macOS companion app exposes sensors like:

binary_sensor.areks_macbook_pro_camera_in_use
binary_sensor.areks_macbook_pro_microphone_in_use

That means Home Assistant knows:

when my camera is active
when microphone is active
and can trigger automations instantly

Automation Logic

The logic is intentionally simple:

Condition	Lamp Color
Camera ON	Red
Microphone only	Orange
Neither	Green

This is the automation:

alias: Office Call Lamp - Camera and Microphone Indicator
description: Red when camera is in use, orange when only microphone is in use, green when neither is in use.
mode: restart

trigger:
  - platform: state
    entity_id:
      - binary_sensor.areks_macbook_pro_camera_in_use
      - binary_sensor.areks_macbook_pro_microphone_in_use

action:
  - choose:
      - conditions:
          - condition: state
            entity_id: binary_sensor.areks_macbook_pro_camera_in_use
            state: "on"
        sequence:
          - service: light.turn_on
            target:
              entity_id: light.led_ring
            data:
              rgb_color: [255, 0, 0]
              brightness: 255

      - conditions:
          - condition: state
            entity_id: binary_sensor.areks_macbook_pro_camera_in_use
            state: "off"
          - condition: state
            entity_id: binary_sensor.areks_macbook_pro_microphone_in_use
            state: "on"
        sequence:
          - service: light.turn_on
            target:
              entity_id: light.led_ring
            data:
              rgb_color: [255, 120, 0]
              brightness: 255

    default:
      - service: light.turn_on
        target:
          entity_id: light.led_ring
        data:
          rgb_color: [0, 255, 0]
          brightness: 120

Designing the Enclosure in Tinkercad

Once the electronics worked, I wanted the project to actually look good on the desk instead of resembling a cyberpunk breadboard experiment.

So I designed a simple two-part enclosure in Tinkercad.

The enclosure consists of:

top shell with LED ring opening
bottom shell holding PCB and ESP32-S3

The design keeps:

USB-C accessible
LEDs visible
electronics hidden
assembly simple

Tinkercad Design

3D Printing

The enclosure was printed on a Bambu Lab printer.

Printed Parts

Final Assembly

What I Like About This Project

What started as:

"please don't walk into the office during calls"

ended up becoming:

a fun ESPHome project
a useful Home Assistant automation
a custom hardware build

The best part is how little code is actually needed.

ESPHome handles:

firmware
networking
Home Assistant integration
OTA updates

Which means you can focus on the actual idea instead of low-level firmware work.

Final Thoughts

ESPHome + ESP32-S3 is honestly one of the best combinations for DIY smart home projects.

The development experience is fast, modern and surprisingly reliable.

And the result is a genuinely useful device that solves a real everyday problem.

Or at least reduces the probability of:

"Are you on a call right now?"

RAG finds chunks. TrailGraph finds answers. Here's the difference.

Arek Mazur — Thu, 26 Mar 2026 10:59:51 +0000

Imagine asking your AI assistant: "How does lead qualification work?"

RAG searches the vector store, pulls the top 5 chunks by cosine similarity, and hands them to the model. You might get three paragraphs about leads, one about opportunity stages, and one about case escalation — because they all share similar keywords. The model does its best to stitch them together. Sometimes it works. Sometimes you get a confidently wrong answer built from pieces that were never meant to be combined.

To be clear — RAG is a proven, powerful pattern. For unstructured documents, broad search, and fast retrieval, it's hard to beat. But when knowledge has clear hierarchy and multi-level relationships, retrieval by similarity alone can lose the structure that makes the answer meaningful.

So I built TrailGraph — an AI agent that navigates a knowledge graph step by step. It explores nodes, scores them for relevance, follows the most promising path, and only reads the full content when it's confident it found the right answer. No embeddings. No vector search. Just an LLM with a single tool and a graph of markdown files.

Where I ran into limits with standard retrieval

RAG was designed for retrieval. You embed documents, query a vector store, get back the top N chunks ranked by cosine similarity. It's fast, it scales, and for many use cases it's the right approach.

But working with Salesforce knowledge — which is inherently hierarchical — I kept running into situations where similarity-based retrieval felt like the wrong tool for the job:

Structure gets flattened. A Salesforce knowledge base is a tree: CRM → Sales → Lead Process → Lead Qualification. With chunked retrieval, that hierarchy disappears — every chunk is equally distant from every other chunk.

No feedback loop. Top-k gives you one shot. There's no way for the model to say "this chunk isn't quite right, show me something adjacent." You get your k chunks and that's it.

Context mixing. When retrieved chunks come from different branches of knowledge, the model has no way to know they're unrelated. This isn't a RAG-specific flaw — any retrieval method can surface unrelated content — but flat retrieval makes it harder to prevent.

The idea: what if the LLM navigated knowledge like a human?

When a domain expert answers a question, they don't search all documents at once. They start from a general area, narrow down, check if they're on the right track, and drill into the specifics.

TrailGraph gives the LLM this exact workflow:

Pick an entry point based on the question (CRM, Security, Integrations)
Explore — see the node's key points, children, and related nodes
Score — assign a relevance score (0–100) and decide where to go next
Drill down — follow the most promising path through children
Focus — when confidence is high enough, retrieve the full content and answer

The LLM never sees the full graph. It only sees the local view of the current node — just like navigating a real knowledge base.

How it works

The knowledge graph

Each node is a markdown file with metadata:

# Lead Qualification

summary: Detailed internal rules, stages, criteria and responsibilities
         for lead qualification.
parent: sales/Sales.md
children: []
related: [sales/Opportunity_management.md]
key_points: ["Mandatory data must be complete before qualification starts",
             "Duplicate check is required before conversion",
             "Business fit and ownership must be confirmed"]

## Content

Lead qualification in our company consists of four main steps:
1. Verify that all mandatory lead data fields are complete.
2. Check whether the company and contact already exist in the system.
3. Assess business fit and confirm ownership of the lead.
4. Decide the outcome: convert, reject, or request more information.

The summary and key_points are what the LLM sees during exploration. The full ## Content section is only revealed when the model commits to this node as the answer.

This separation is intentional — it forces the model to navigate rather than skim.

The graph structure

entry_points/
├── CRM.md ──────────┬── sales/Sales.md
│                     │      ├── Lead_process.md
│                     │      │      └── Lead_qualification.md
│                     │      └── Opportunity_management.md
│                     │             └── Opportunity_stages.md
│                     └── service/Service.md
│                            ├── Case_handling.md
│                            └── Escalation_process.md
├── Security.md
└── Integrations.md

The tool

The agent has one tool: get_knowledge_context. It accepts a node path, a view mode, a score, and a reason.

def run(self, node, view="exploration", score=0, reason=""):
    self.last_score = score
    if score > self.best_score:
        self.best_score = score
        self.best_node = node

    if score >= ANSWER_THRESHOLD:
        view = "focused"

    if node in self.visited and view != "focused":
        return {"already_visited": True, "suggestion": "Explore other candidates."}

    self.visited.append(node)
    self.hop_count += 1

    if view == "focused":
        self.disabled = True

    result = build_node_info(node, view)
    # ...
    return result

Key behaviors:

Two views: exploration returns key points, children, and related nodes. focused returns the full content.
Score-driven transitions: when the model assigns a score >= 95, the tool automatically switches to focused view — no matter what the model requested.
Self-disabling: after returning focused content, the tool disables itself. The model has what it needs; no more graph navigation.
Dead end detection: if a node has no children and no related nodes, the tool flags it as a dead end and triggers a fallback.

The agent loop

The agent itself is completely generic — it knows nothing about knowledge graphs:

class Agent:
    def __init__(self, tools, prompt_vars=None, verbose=False):
        self.client = OpenRouterClient(model=os.getenv("OPENROUTER_MODEL"))
        self.tools = tools
        self.tool_map = {tool.name: tool for tool in self.tools}
        # ...

    def _step(self, user_input):
        for tool in self.tools:
            tool.reset()

        for iteration in range(MAX_TOOL_ITERATIONS):
            active_tools = [s for tool, s in zip(self.tools, self.tool_schemas)
                           if not tool.disabled]
            message = self.client.complete(self.messages, tools=active_tools or None)

            if not tool_calls:
                print(f"Agent: {message.get('content', '')}")
                return

            for tool_call in tool_calls:
                result = tool.run(**tool_args)
                # ...
                fallback = tool.should_fallback()
                if fallback:
                    print(fallback)
                    return

All the intelligence lives in the tool. The agent just runs the loop, passes messages, and checks stop conditions. You could swap GetKnowledgeContext for a completely different tool and the agent would work the same way.

The flow

User: "How does lead qualification work?"
  │
  ├─→ LLM selects entry point: CRM.md
  │     → exploration view: sees Sales and Service as children
  │
  ├─→ LLM picks Sales.md (score: 70)
  │     → exploration view: sees Lead_process, Opportunity_management
  │
  ├─→ LLM picks Lead_process.md (score: 80)
  │     → exploration view: sees Lead_qualification as child
  │
  ├─→ LLM picks Lead_qualification.md (score: 98)
  │     → score >= 95 → automatic switch to focused view
  │     → full content returned, tool disables itself
  │
  └─→ LLM writes final answer based on focused content

4 hops. Each one narrowing the search space. Graph traversal guided by LLM reasoning.

Trade-offs: when does each approach make sense?

	RAG	TrailGraph
Retrieval	Semantic similarity (top-k)	Graph traversal (step by step)
Structure awareness	Chunks are independent	Nodes have parents, children, relations
Context control	Fixed (top-k chunks)	Dynamic — model decides what to explore
Latency	Fast (1 query)	Slower (multiple LLM calls per question)
Scalability	Proven at scale with vector DBs	Depends on graph depth and structure
Setup complexity	Moderate (embeddings, vector store)	Low (just markdown files)
Best for	Unstructured docs, broad search	Structured domains, multi-level knowledge

These aren't competing approaches — they solve different problems. RAG shines when you have large volumes of unstructured content and need fast, broad retrieval. Graph traversal shines when knowledge has explicit hierarchy and relationships. The roadmap for TrailGraph actually combines both: RAG for entry point selection, graph traversal for deep navigation.

What I learned building this

Scoring is everything

The system prompt includes a scoring guide that shapes how the model navigates:

0–59: Not relevant — stop exploring this path
60–94: Partially relevant — keep exploring children
95–100: Highly relevant — switch to focused view

Getting these thresholds right took multiple iterations. Set the answer threshold too low (e.g. 85) and the model stops at intermediate nodes like "Sales" instead of drilling into "Lead Qualification." Set it too high and the model never commits.

The key insight: only assign high scores to leaf nodes. If a node has children, there's always a more specific answer deeper in the graph. This rule is baked into the system prompt.

The model will hallucinate paths

Early versions had the model inventing node paths like Integrations/Salesforce_SAP_Integration.md — files that don't exist. The fix was a hard rule in the system prompt:

Never invent node paths. Only navigate to nodes explicitly listed in children or related of a previous tool response.

Combined with dead end detection in the tool (no children + no related = fallback), this eliminated path hallucination entirely.

What's next

TrailGraph is functional but minimal. Here's what's on the roadmap:

Near-term:

Multi-path exploration — instead of following a single path, explore the top N candidates in parallel (beam search)
Scoring module — extract scoring logic into a dedicated module to make strategies swappable

Longer-term:

Document parser — a tool that converts external documents (PDF, DOCX, Confluence) into the .md node format, making it easier to populate the graph
SQLite metadata store — store node metadata (summary, children, related, key_points) in a database while keeping full content in markdown files. Graph traversal happens against the DB; file I/O only on view=focused
RAG-based entry point selection — replace the fixed entry point list with a semantic search step. When a question arrives, RAG returns the top N most relevant nodes as candidate entry points. If the graph traversal from candidate i scores below threshold, automatically fall back to candidate i+1
Multi-query decomposition — split complex questions into sub-questions, run each through the full traversal independently, and consolidate into a single answer

The interesting part is that RAG and graph traversal aren't mutually exclusive. The roadmap leads to a hybrid: RAG for entry point selection, graph traversal for deep navigation.

Try it

TrailGraph is open source. The knowledge base covers Salesforce sales and service processes, but the architecture works for any structured domain.

git clone https://github.com/panhiszpandev/TrailGraph.git
cd TrailGraph
python -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt
cp .env.example .env
# Add your OpenRouter API key
python main.py --verbose --task "How does lead qualification work?"

Watch the verbose output. You'll see the agent hop through the graph, scoring each node, narrowing down step by step — the way a human would navigate knowledge.

Acknowledgments

This project was inspired by ideas from the AI_devs course, which pushed me to think beyond standard RAG patterns and explore agent-based architectures.

TrailGraph is a side project. Feedback, ideas, and PRs are welcome.
GitHub