Work
Product

Residential System Diagram

An interactive, data-driven diagram that lets homeowners understand their energy system at a glance — which devices are connected, how power is flowing between them, and what the system is doing right now.

Context

Most homeowners never think about how electricity moves through their house until something stops working.

Modern residential energy systems are surprisingly complex. A single installation might include battery packs, solar inverters, grid meters, EV chargers, backup gateways, and a main electrical panel — all wired together in configurations that vary significantly from home to home.

The challenge wasn’t just visualizing this topology accurately. It was making it understandable to non-technical users in real time.

I owned this feature end-to-end: from early design conversations through architecture, implementation, and production rollout. The goal was to build something that felt as approachable as a thermostat display while representing a system with dozens of possible states and hardware combinations underneath.

The diagram

GRIDMeterSOLARInverter3.8 kW ↓BATTERYChargingMAINPANEL1.2 kW loadHOMELoadsWALLCONNECTORBlue lines = active power flow · Dashed = standby

Simplified topology — real diagrams reflect each home's specific hardware configuration.

The diagram is built with React Flow.

Each device type — battery, solar inverter, grid meter, wall connector, main panel — is rendered as a custom node component. Edges are more than static connectors: they visualize directional power flow in real time, with animation speed and direction driven directly from live telemetry.

The topology itself is fully dynamic.

Some homes have multiple battery units. Others have AC-coupled solar with separate inverter systems. Some installations have no solar at all. The diagram builds itself from configuration payloads returned by the backend rather than from a predefined layout.

That distinction ended up shaping most of the architecture.

Hard problems

Dynamic group sizing

React Flow groups require explicit dimensions.

The problem is that energy systems don’t arrive with predictable layouts. A “Powerwalls” group might contain one battery or six depending on the customer installation.

Initially, I tried sizing groups using static heuristics and quickly ran into overlapping nodes and layout drift as configurations became more varied.

The eventual solution was a pre-layout sizing calculation that inspects the configuration payload before rendering. It counts the devices inside each group and derives dimensions from actual content: node heights, spacing constants, internal padding, and layout rules — not arbitrary magic numbers.

Because sizing happens before render, groups appear correctly on first paint without post-render corrections or layout jumps.

Layout vs. rendering separation

This became the most important architectural decision in the project.

Power flow visualization updates continuously. Edges animate at near animation-frame frequency to represent live energy movement through the system.

Layout calculations, however, are comparatively expensive and only need to run when the device topology changes.

Early versions of the diagram mixed the two concerns together. Every telemetry update triggered layout recalculations, which immediately caused frame drops and janky animations once real data started streaming.

The fix was architectural separation.

Layout runs only when configuration data changes and produces a stable node and edge tree. The animation layer reads from that tree independently without mutating layout state.

That separation is what made smooth 60fps rendering possible even under continuous telemetry updates.

Handle positioning

React Flow edges connect through handles attached to nodes.

In a standard flowchart, handles usually live at fixed positions: left, right, top, or bottom.

That model broke down quickly for residential energy systems.

Connection lines needed to emerge dynamically depending on surrounding topology. A battery placed to the left of the main panel connects differently than one placed below it. Solar systems, meters, and wall connectors all introduced slightly different routing expectations.

I ended up building a topology-aware handle configuration system where nodes determine their connection points relative to neighboring device positions instead of hardcoded directions.

That allowed layouts to stay visually coherent even as device configurations changed dramatically between homes.

Module Federation boundary

The diagram lived inside a micro-frontend architecture using Module Federation with Rspack.

React Flow is a relatively heavy dependency with its own React context. Loading it naively across federation boundaries introduced duplicate dependency instances, broken providers, and inconsistent internal state between host and remote applications.

The solution was careful dependency externalization.

React, ReactDOM, and React Flow were all declared as shared singletons in the federation configuration, with strict version constraints to prevent mismatches across independently deployed applications.

It’s one of those problems that sounds small until everything randomly stops rendering.

What I’d do differently

The layout engine accumulated complexity over time as additional device types and edge cases were introduced.

What started as a clean layout function gradually evolved into a centralized collection of conditional branches handling specific device combinations and rendering exceptions.

Given more runway, I’d refactor toward a proper strategy-based layout system where each device group owns its own sizing and positioning rules independently instead of relying on a shared orchestration layer.

I’d also invest earlier in visual regression testing.

The diagram supports many valid hardware configurations, and validating layout correctness manually became increasingly time-consuming as the system evolved. Snapshot-based visual tests against known topology configurations would have caught layout drift and rendering regressions significantly earlier.

Final thoughts

One of the most interesting parts of the project was realizing that the real challenge wasn’t rendering nodes and edges.

It was translating infrastructure complexity into something homeowners could understand instantly.

Most users don’t care about topology trees, telemetry pipelines, or render performance. They care about answering questions like:

  • Is my house charging right now?
  • Why is energy flowing to the grid?
  • Are my batteries powering the home?

The diagram succeeds when those questions stop feeling technical.

That was the real product problem underneath all the engineering.

Company

Tesla

Period

2025 – 2026

Role

Senior Software Development Engineer

Scope

Feature owner, end-to-end

Stack

    ReactReact FlowTypescriptGraphQLRspackModule FederationCSS Modules