Back to all articles
6 min read

Where Boston Builders Turn Sunlight Into Side Projects

Open-source solar and energy monitoring projects are quietly born at Boston unconferences. Here is how to join one, or pitch your own session.

Why Energy Sessions Fill Up Fast

Walk into a Boston unconference on a Saturday morning and you will see the usual sticky notes on the wall. Someone wants to talk about React. Someone else wants to argue about Kubernetes. Then there is a small, slightly crooked note near the bottom that says something like "I put a solar panel on my porch and now I have too much data. Help?"

That note fills the room. Every time. Not because energy is trendy, but because it is the rare technical topic where everyone has a personal stake. People pay electric bills. People lost power in the last nor'easter. People have a landlord who says no to rooftop anything. So the session turns into part show and tell, part group therapy, part hardware swap.

What comes out of those rooms is more interesting than most people expect. Not startups. Not pitch decks. Small, sturdy, open-source tools that solve one annoying problem well.

“Getting this detail right early is what separates a smooth project from an expensive redo,” notes one specialist focused on this detailed guide.

Three Shifts That Put Power Data Within Reach

The barrier to entry has collapsed. Ten years ago, monitoring your own power use meant an expensive proprietary box and a subscription. Now a microcontroller costs less than lunch in Kendall Square, and the firmware is free. Three things changed at once:

  • Cheap sensors. Current clamps, voltage monitors, and light sensors are commodity parts now, sold in kits with decent documentation.
  • Good open firmware. Projects that let you flash a device and get real readings in an afternoon, with no cloud account required.
  • Local data storage. A Raspberry Pi on a shelf can log years of readings. No vendor lock, no monthly fee, no surprise API shutdown.

So a person with modest coding skills can build something genuinely useful in a weekend. And Boston has an unusual concentration of people who both write code and care about municipal utility data.

There is also a practical driver. New England power prices swing hard, and winter peaks hit differently here than they do in Phoenix or Austin. Before you can interpret a single sensor reading in dollars, you have to read your utility bill closely enough to know which charges are usage and which are demand. A tool built for Boston conditions has to think about snow cover on panels, short December days, and old triple-decker wiring. That local specificity is exactly what generic commercial products get wrong, and exactly what a room full of local builders gets right.

"The most durable energy tools we see come from people solving their own building's problem first, then generalizing," says Marcus Feldman, senior systems engineer at a firm focused on commercial solar development. "The ones that start as a market opportunity tend to fizzle. The ones that start as an itch tend to last."

Hardware Kits That Actually Get Finished

Builds That Survive Past Sunday Night

Half of all hackathon hardware projects die in a drawer. The difference between a finished build and a dead one is usually scope, not skill. Here is what tends to survive past Sunday night.

The Single-Circuit Monitor

Clamp one sensor around one wire. Measure one thing. A single-circuit monitor tells you what your heat pump actually draws, or how much your dehumidifier costs to run in August. It takes an afternoon, and the data is immediately interesting, which keeps you motivated. Cost is low, risk is low, and the pattern generalizes: once you can read one circuit, reading eight is just more of the same.

The Panel Health Logger

If you already have solar, whether a two-panel balcony setup or a full roof array, the interesting question is not how much you generated. Your inverter already tells you that. The interesting question is whether a specific panel is underperforming, and why. Shade from a tree that grew. Bird mess. A connector working loose.

A small logger comparing per-string output against a simple sun-position model catches these problems weeks before a human notices the monthly total dropped.

The Community Sensor Node

This one gets people excited because it scales socially rather than technically. A dozen people install identical low-cost sensors across a neighborhood, share the data openly, and suddenly you have a map. Solar potential by block. Voltage sag during heat waves. Outage timing that reveals which feeder serves which street. Once the map exists, the follow-up questions get concrete fast, from shade patterns to whether targeted glazing upgrades would flatten a west-facing building's afternoon cooling load. The technical work per person is small; the collective output is something no individual could produce, which is the whole point of building in a community setting.

Where Projects Usually Fall Apart

Being honest about failure modes saves months. The most common ones:

  • Dashboard first, data second. People spend the weekend on a beautiful front end before confirming the sensor readings are accurate. Then the numbers turn out to be off by 30 percent and the whole thing gets abandoned.
  • Calibration skipped. A current clamp needs calibrating against a known load. Ten minutes of work, endlessly deferred.
  • No enclosure. Outdoor electronics without a proper weatherproof box last until the first real rain.
  • Undocumented wiring. Six months later, nobody remembers which wire went where, including the person who built it.

Data quality is the quiet killer, and it is the same trap that shows up in software work, where the "clean data" delusion that quietly undermines otherwise promising projects. Bad inputs make every downstream decision worse, and sensors are unusually good at producing confident, wrong numbers.

One safety note deserves its own line: anything involving a breaker panel, mains voltage, or permanent electrical work needs a licensed electrician. Clamp-on sensors that never touch a conductor are the safe hobbyist entry point. Everything past that is professional territory, and no amount of enthusiasm changes that.

Pitching Your Session Without Overthinking It

What a Working Session Proposal Looks Like

Unconference sessions are not conference talks. Nobody expects slides, and nobody expects you to be the expert. The format rewards a good question far more than a polished answer, and energy topics are full of good questions. A pitch that works looks roughly like this:

  • One concrete thing you built or want to build. "I logged my apartment's power for a year and found something weird" beats "The Future of Energy."
  • A question you cannot answer alone. This turns attendees into participants instead of an audience.
  • Something physical on the table. A breadboard, a sensor, a printed graph. People gather around objects.
  • A clear ask at the end. Testers, a repo contributor, someone with roof access, someone who understands utility tariffs.

Session titles matter more than they should. The same content will draw five people or thirty depending on the words on the sticky note. Specificity wins, and phrasing your title as a discovery or a puzzle tends to outdraw a category label. This is the same instinct behind beyond backlinks thinking, where being findable depends on how clearly you describe the actual thing rather than the general subject area.

What to Bring, What to Leave Home

Bring a laptop with your dev environment already working, a phone hotspot in case venue wifi is rough, any sensor small enough to fit in a bag, and your repo link written on paper so people can photograph it.

Leave the mains-connected equipment at home. Leave the two hour presentation at home. Leave the assumption that everyone in the room knows less than you do, because in Boston that assumption is frequently wrong and always awkward.

Finding the Thread After the Weekend Ends

The real value of an energy session shows up three weeks later, when someone opens a pull request on the repo you barely announced. Momentum is fragile, so a little structure helps. Create the repo before the session, even if it is empty except for a readme. Set up a chat channel and put the invite link where people saw your session title. Pick one small next milestone with a date attached, because open-ended projects with no deadline drift toward nothing.

Then do the least glamorous thing: write down what you learned, including the failures. The person who documents that a particular sensor reads high at low currents saves the next twelve builders an afternoon each. That accumulated, shared knowledge is what turns a scattering of weekend projects into something a city can actually use.

The Sticky Note Is the Whole Point

Boston does not lack energy expertise. There are labs, utilities, and startups here doing serious work at scale. What the hackathon backrooms add is different: a place where the barrier to contributing is a marker and a piece of paper, where a renter with a balcony panel sits next to someone who models grid load for a living, and where the conversation stays practical because there is no investor in the room to impress.

The tools coming out of those rooms are small. A circuit monitor. A panel health checker. A neighborhood sensor map. None of them will make headlines. Together, they build something more valuable: a local, open, shared understanding of how power actually moves through the buildings we live in. The next session on that wall could be yours, and the only real prerequisite is having noticed something about your own electricity that you cannot yet explain.

Argue with this in person

Barcamp Boston runs on hallway disagreements and half finished ideas. Pitch a session, grab a slot on the board, and take the conversation further than a comment box ever will.

See the schedule