NeuroGrid

AI-Powered Community Energy Optimization

Comment 8

Inspiration

I started thinking about this problem after noticing how little visibility anyone has over energy use in a shared building. Residents get a monthly bill with a single number. Property managers have no idea which rooms are wasting power at 2 AM. And when a grid peak event happens, everyone finds out after the fact, but never before.

What frustrated me more was that most "smart energy" solutions require expensive hardware retrofits. Sensors, smart meters, new wiring. That's a multi-year, multi-million dollar project for most communities — and it never happens.

The real question isn't "how do we collect better data?" It's "what if we could optimize energy behavior with software alone?" That question led me to two fields I'd been separately interested in: AI forecasting and behavioral neuroscience. If you can predict when a peak is coming AND give people a reason to care, you don't need new hardware. You just need the right information delivered the right way at the right time. That's NeuroGrid.

What it does

NeuroGrid is a full-stack community energy management dashboard with three core layers:

  1. AI Forecasting Engine A Ridge Regression model trained on seven days of hourly data predicts community energy load for the next 24 hours. It uses cyclically-encoded time features (sin/cos for hour-of-day and day-of-week) so the model understands that 11 PM and midnight are neighbors — something plain integer encoding gets wrong. The model detects peak-risk events before they happen and generates a plain-English explanation of why the forecast changed.

  2. Recommendations Engine A rule-based system cross-references forecast output with live occupancy and solar data to generate a ranked list of actions: reduce HVAC setpoints, delay EV charging, shift appliances off-peak, prioritize stored solar. Every recommendation includes estimated kW savings, carbon reduction, urgency level, and whether it can be automated or requires a human nudge.

  3. NeuroNudge Behavioral Science Layer This is what makes NeuroGrid different. Instead of sending generic alerts, it converts energy performance into eco-points, streaks, badges, and personalized messages grounded in behavioral neuroscience — goal-gradient effect, social comparison, loss-aversion framing. Buildings compete on a live leaderboard. Residents earn the "Green Warrior" badge for three consecutive days below baseline. A community challenge can mobilize an entire building around a single energy goal.

The app also includes a scenario simulation page (hot weather, EV surge, solar surplus, high occupancy, savings campaign) where all three layers update simultaneously, and a one-click Live Demo mode that cycles through all scenarios automatically every four seconds.

How we built it

Built entirely solo in roughly one week.

Backend — Python + FastAPI I structured the backend around four independent modules: mock_data.py for seeded realistic energy simulation, forecasting.py for the Ridge Regression model, recommendations.py for the rule engine, and behavior.py for the NeuroNudge layer. Each module is stateless and swappable — the forecasting module can be replaced with Prophet or an LSTM without touching a single router. A lightweight state.py file holds the active scenario and demo mode flag in memory, so no database is needed for the MVP.

Frontend — Next.js + TypeScript + Tailwind + Recharts Six pages: Dashboard, Buildings, Forecast, Recommendations, NeuroNudge, and Simulation. The Next.js rewrite config proxies all /api/* calls to the FastAPI backend, so the frontend never hardcodes a server address. Charts are built with Recharts using custom tooltips and gradient fills. All shared types live in a single types.ts file, which eliminated an entire class of runtime errors.

AI Forecasting Rather than use scikit-learn (which adds a heavy dependency), I implemented Ridge Regression from scratch using NumPy's linear algebra solver: w = (XᵀX + αI)⁻¹ Xᵀy. The cyclical encoding trick — representing hour as (sin, cos) rather than an integer — was the single biggest accuracy improvement, because it correctly treats the hour boundary (23→0) as a small step, not a jump of 23.

Behavioral Science I read through Allcott & Mullainathan (2010) and Thaler & Sunstein's nudge framework before writing a single line of behavior.py. Every mechanic maps to a named psychological principle. The "science note" visible in the UI is intentional — I wanted the behavioral layer to feel credible, not like a tacked-on points system.

Challenges we ran into

Making the AI explainable, not just accurate The first version of the forecast just returned a kW number. That's useless for a property manager who needs to act. I spent a full day designing the explanation layer — a function that inspects the active scenario multipliers and recent trend to generate a sentence like "Forecast influenced by elevated HVAC load and evening EV charging surge." Turning a model output into a human-readable decision prompt was harder than building the model itself.

Behavioral science without feeling fake A leaderboard and some badges is easy to build. Making it feel grounded — like it actually came from a psychologist — is harder. The temptation is to pile on features. I had to cut a lot and focus: each mechanic had to map to exactly one published principle, or it got cut. The constraint made the module better.

Cyclical time encoding I tried plain hour integers first. The model kept producing flat forecasts that missed the evening peak by 30–40 kW. Switching to sin/cos encoding fixed it immediately. Understanding why — that integer 23 and integer 0 are 23 units apart instead of 1 — was a genuine aha moment that required re-reading the feature engineering literature.

Scenario propagation Getting all three layers (forecast, recommendations, behavior) to update simultaneously when a scenario changes required careful state design. The solution was simple in the end — a single state.py module with a global scenario key, read by every router — but I went through two messier designs first before landing on it.

Accomplishments that we're proud of

  • Built a complete, working, full-stack AI product solo — frontend, backend, forecasting, recommendations, and behavioral science — in under a week.

  • The forecasting model runs entirely in NumPy with no ML framework dependencies. It's 80 lines of code, starts in milliseconds, and is accurate enough to correctly flag evening peak events.

  • The behavioral science layer has a visible citation and a published research basis. It's not gamification — it's applied psychology. That distinction matters and I'm proud it shows in the UI.

  • The scenario simulation page updates six simultaneous data streams (energy chart, KPIs, peak risk, recommendations, behavior nudges, leaderboard) in under one second. That responsiveness makes the Live Demo mode actually impressive to watch.

  • The architecture is genuinely modular. To swap the forecasting model for Facebook Prophet, you change two functions. To add a new scenario, you add one dictionary entry. I designed for extensibility without over-engineering.

What we learned

Architecture decisions compound. Keeping forecasting, recommendations, and behavior as truly separate modules felt like overkill at first. By the time I built the simulation page, it saved me days — each module just reads the current scenario multipliers and responds independently.

Explainability is a feature, not a footnote. The most technically impressive part of NeuroGrid is the AI forecast. But the most useful part is the one sentence that explains why it changed. Users don't need the model — they need the insight the model produces.

Behavioral science is a design constraint, not an add-on. I learned more about goal-gradient effect, loss aversion, and social comparison building this project than I did reading about them abstractly. When your design decision has to map to a named psychological mechanism, you make better decisions.

Working software beats perfect software. Simulated data with realistic patterns is better than real data that doesn't exist yet. A working MVP you can demo in a browser beats a theoretical system you can only describe. Ship first, upgrade later.

What's next for NeuroGrid

Real data integration Replace the mock data layer with MQTT polling from real smart meters. Most modern apartment complexes already have them — NeuroGrid just needs an adapter. First target: a single building willing to share read-only meter access.

Resident-facing mobile app The NeuroNudge layer currently lives in a dashboard that residents don't see. A lightweight React Native app — or even a WeChat/Line mini-program — would put personalized nudges directly on residents' phones. That's where the 8–15% demand reduction actually happens.

Upgraded forecasting Swap Ridge Regression for Facebook Prophet or a Temporal Fusion Transformer, adding weather API data as an external regressor. Hot days and cold snaps are the biggest drivers of peak events — the model should know the forecast before the residents do.

Demand charge optimization For commercial buildings on two-part tariffs, NeuroGrid's peak detection directly translates to demand charge savings — often $2,000–5,000/month for a mid-size complex. Building an automated demand-response layer that can shed load 30 minutes before a peak is the highest-value near-term feature.

Carbon marketplace integration Connect verified demand reductions to carbon credit markets. Communities that consistently avoid peak grid events produce measurable, auditable carbon reductions. That has real monetary value — and NeuroGrid already tracks the data needed to claim it.

Built With

Share this project:

Updates