Published Saturday, October 03, 2026 at 12:27 PM PT

Burbank · Saturday, October 3, 2026 · 12:27 PM · 101°F, 25% humidity, wind 0 mph NW (gusts 2), 29.28 inHg, UV 0, PM2.5 1

Home Assistant Glow is an ESPHome-based firmware project that stares at your electricity meter’s pulse LED and reads it like a fortune teller, piping kilowatt data back into Home Assistant so you can obsess over your power consumption in real-time. It’s been around since 2021, sitting at 1,269 stars, with a fresh push two days ago—meaning Klaas Schoute is still maintaining this thing like it’s his actual child. The pitch is simple: if your meter doesn’t have a P1 port (and honestly, if you’re in North America or don’t live somewhere meter manufacturers decided to love you, it probably doesn’t), a cheap ESP32 with a photodiode can watch that LED pulse and count power like a tiny obsessive-compulsive comptroller living in your meter box.

The Meter Gap

The reason Glow exists at all is that electricity meters are a sprawling landscape of regional incompatibility. Europe got standardized around P1 ports—essentially a small serial interface on the meter itself that spits out consumption data in a structured format. Some utilities push that data directly; others require a cable you buy separately. North America, by contrast, largely standardizes on nothing. Your meter has a spinning wheel (or, more commonly now, a digital display), and that’s it. No port. No wire. Just a pulse LED that blinks once per unit of energy consumed. The ratio varies by meter—some pulse once per kilowatt-hour, others once per tenth of a kWh. Your utility documentation might tell you, or you might have to stand in front of your meter with a phone stopwatch like some kind of power-consumption archaeologist.

This isn’t negligence, exactly. It’s path dependency. Utilities deployed millions of meters over decades before P1 ports existed, and replacing them all is hideously expensive. For utilities in regions that did standardize, the rollout happened at different times. Japan has its own standard. Australia has another. India has nothing. China has… well, probably something, but good luck finding documentation in English. The point is: if you live anywhere that doesn’t have a standardized meter port, and you want real-time whole-house power data, you either pay for a commercial solution (Sense, Neurio, whole-house CTs), run a bunch of dedicated outlet sensors and math your way to the answer, or you put a camera on your meter like a weird person and hope the lighting is consistent.

Glow is the “weird person” option, except it’s not a camera—it’s just a photodiode. It’s simpler, cheaper, and it doesn’t care if your meter box has a 40-watt bulb or is pitch black except for the pulse LED. The firmware detects the LED pulse in whatever light conditions exist and counts it. No machine learning, no neural networks, no cloud training data. Just pulse-counting logic that’s been hammered into working condition.

The Hardware Reality

Let’s be precise about what you’re actually building. The hardware side is this: you get an ESP32 (or an ESP32-C3, which is slightly cheaper and lower power), a photodiode sensor module (typically an LM393-based board that costs a dollar or two), some jumper wires, optional RGB LED for status indication, and a 3D-printed case if you want your installation to not look like you taped a circuit board to your meter. The sensor module is a ready-built breakout—photodiode, amplifier, and comparator already on the board. You wire three pins: power, ground, and the digital output. Flash the ESPHome firmware. Done.

The decision space, such as it is, lives in component choices. An ESP32 gives you more GPIO and RAM if you want to expand later (maybe you add a temperature sensor, or you want to do local logging before syncing). An ESP32-C3 is cheaper, lower power, and simpler—still plenty of pins and memory for this job. ESP8266 works but is more memory-constrained and older. If you’re running ESPHome on a device farm already, you probably have opinions about which chip you prefer. The photodiode module matters slightly more. You want one with a dedicated digital output pin (not a bare analog sensor), because the firmware needs to count individual pulses, not interpret analog voltage swings. A two-dollar module from the right vendor works fine. A five-dollar “premium” one works equally fine.

The case design is free on the repo. 3D printer, PETG or PLA, takes a couple hours. It’s designed to hold the sensor and the ESP board and position the photodiode at the right angle to stare directly at the meter’s pulse LED. You could absolutely skip the case—Velcro or mounting tape works—but the case is nice because it keeps the sensor from shifting and losing calibration when your meter box vibrates or someone shuffles the equipment around.

Cost to you, total, including the ESP32 and a module and shipping from somewhere reasonable: fifteen dollars if you don’t overthink it. Maybe twenty-five if you want quality components from a vendor you trust or you need expedited shipping. Compare that to Sense (three hundred dollars, plus subscription if you want cloud), and this starts looking absurd. Even a couple of commercial smart outlets (thirty to fifty each) get expensive if you need fifteen of them to cover your house.

The Firmware and the Pulse

The firmware is where the magic actually happens, and it’s less magic than it is careful bookkeeping. The photodiode module outputs a digital pulse when the meter’s LED blinks. The firmware reads that GPIO pin and counts the pulses. Each pulse represents some fixed amount of energy—usually one kilowatt-hour or one-tenth of a kWh, depending on your meter. The firmware knows this number because you configure it when you flash the device. From the pulse count, it calculates current power consumption (by tracking the time between pulses) and cumulative energy (by keeping a counter). ESPHome handles the rest: pushing data to Home Assistant via MQTT or the native protocol, integrating with the energy dashboard, logging to your time-series database.

The tricky part is debouncing. Pulse LEDs are reliable, but they’re not perfect. Environmental light can introduce false readings. Electrical noise can bounce the signal. The firmware applies hysteresis and timing logic to ensure that a single blink registers as one pulse, not three or five. The author has clearly tuned this extensively, because the project doesn’t have open issues about phantom pulse readings, which is the kind of thing that would be noticeable immediately if it were broken.

The firmware also handles configurable pulse rates. Some meters might pulse at a different frequency than others, and the software lets you set the imp/kWh value (the number of LED pulses per kilowatt-hour consumed). Set it to ten if your meter blinks once per 100 watt-hours, or one if it blinks per kWh. The firmware calculates actual consumption from there. It’s configurable, which is respect for regional meter variance.

Power draw from the device itself is minimal—the ESP32 and photodiode together pull maybe half a watt at idle, probably less in sleep mode if you configure it aggressively. That’s an extra three to five kilowatt-hours per year, depending on your power management tuning. Totally immaterial to the math you’re trying to do.

Why Aggregation Alone Isn’t Enough

You’ve already got per-outlet power metering via Eve and smart plugs and whatever else you’ve instrumented. The natural follow-up is: can’t I just add them all up and get my total? The answer is technically yes, but the answer is also technically yes, assuming your house is a perfect sealed box with zero phantom load and every single circuit you own is smart-enabled.

Reality is messier. Your house has circuits you probably didn’t instrument because they seemed permanent: the HVAC, the water heater, the refrigerator (well, you might have instrumented this one), the garage outlets, the basement outlets, the outdoor lights. You have phantom load—every outlet with a standby current, every charger that draws 0.2 watts even when nothing is plugged in, every smart switch that’s drawing 0.1 watts to stay on the network. You might have a hot tub or a geothermal heat pump or a car charger that pulls so much power you need a dedicated circuit you haven’t gotten around to adding a smart plug to. You have efficient circuits—your air conditioning compressor might run at 70% efficiency, losing 30% as heat in transmission and power conversion. You have vampire load from things you genuinely forgot about.

When you add up all your instrumented outlets, you get a number that’s probably 60 to 80 percent of your actual consumption. Glow tells you what the actual number is. That gap isn’t a bug—it’s data. It tells you where your blind spots are. It’s the difference between thinking you know your power consumption and knowing you know it.

Real example from your own situation: you’ve got the whole-house Grafana dashboard and a Postgres database. Right now you’re plotting outlet-level consumption, and you’re probably wondering why the monthly bill is higher than what you calculated. The meter never lies. The meter has already been audited by regulators and utility companies. Glow lets you read what the meter says. If Glow says you’re using 30 kilowatt-hours per day and your aggregate outlets say 25, you have a 20 percent gap to investigate. That gap is worth money if you’re paying for electricity.

Integration With Home Assistant

The integration is straightforward because ESPHome integration with Home Assistant is always straightforward once the device is flashed. Glow exposes sensors: instantaneous power (in watts), cumulative energy (in kWh), maybe status indicators. Home Assistant picks these up as standard entities. They appear in your energy dashboard. They flow into your Postgres database if you’re running a database recorder. They’re queryable via the history stats component if you want to know your peak power yesterday or your average over a week.

The energy dashboard specifically is built to work with sensors like this. It automatically calculates daily consumption, tracks the cost (if you give it your utility rate), and shows trends. It’s not a commercial energy monitor, but it’s not meant to be. It’s meant to be a local, persistent, auditable record of what you’re using, integrated into your existing smart home automation.

Because it’s ESPHome, it also means you can extend it. Want to log it to a separate database? Write an automation that runs a query every hour. Want to use the consumption spike to trigger something (like load-shedding logic, or alerting your household when peak draw is happening)? Home Assistant automations handle that. Want to expose it to other systems (Node-RED, AppDaemon, whatever else you’re running)? It’s all local data on the network. You’re not funneling your power consumption through anyone’s cloud.

The Comparison Matrix

Let’s be explicit about the alternatives and what they trade.

P1 cable (where available): If your meter has a port and you’ve already bought a cable, Glow is redundant. But most people haven’t. If you live somewhere with P1 ports, check whether yours is enabled first. Some utilities require a request or enable it selectively.

Commercial whole-house monitors (Sense, Neurio, etc.): These cost two to three hundred dollars and usually require a subscription for cloud features. They use current transformers around your main breaker to directly measure amperage and infer power. They’re more accurate in some ways (they measure the actual waveform), less accurate in others (they miss anything on a sub-panel or generator). They’re a closed system—you get what the vendor shows you, and if they go out of business or stop supporting your model, you’re stuck.

Utility smart meter API: If your utility publishes one, you can query it and get official consumption data. PG&E (California) has one. Some others do. The catch is API limits, authentication, and the utility can change their terms or disable access whenever they want. You’re at the mercy of their availability. Also, utility APIs usually push data with a 15-minute or hourly delay, not real-time.

Whole-house CT (current transformer) clamps: You can buy non-invasive CTs, clamp them around your main feed, wire them to an Arduino or MQTT gateway, and do the calculation yourself. This works fine and doesn’t require meter access. The downside is you need access to your electrical panel, which is more dangerous and more complicated than screwing something into a meter box. Glow is safer and lower-friction.

More smart outlets: Just add more sensors until you’ve covered everything. This works if you have the time, money, and patience to instrument every circuit, and if you don’t mind a hardware setup that’s scattered across forty different smart plugs. You’ll still miss phantom load and power factor correction losses. And you’ll have paid two hundred to five hundred dollars by the time you’re done.

Glow wins on cost, simplicity, authority, and local autonomy. You’re not buying into anyone’s platform. You’re not exposing your power consumption to cloud infrastructure. You’re not waiting for an API that may or may not stay available. You’re just reading what the meter already knows and feeding it into your Home Assistant.

The Operational Reality

Once installed and working, Glow is stupid reliable. It’s a single sensor reading a single input, debounced in firmware. There’s almost nothing to break. The photodiode is potted in the sensor module—no exposed components, no corrosion risk. The ESP32 is generic, boring hardware that’s been around for years. If your meter box stays dry (which it should, by definition), there’s no moisture risk.

Failure modes are few. The worst case is the photodiode gets obstructed by dust or someone moves a breaker in front of the LED. Unlikely if it’s mounted properly in the case. The second-worst case is the WiFi connection drops and the ESP32 can’t push data to Home Assistant; the device logs data locally and syncs it when connectivity returns, so you don’t lose history. The actual-worst case is the ESP32 dies, which happens to maybe one in ten thousand units after some reasonable operating lifespan, and you’ve spent fourteen dollars to replace it.

Calibration is a one-time event. You set the imp/kWh value based on your meter’s rating (printed on the faceplate), flash it, and it’s done. No ongoing tuning. No “drift compensation” nonsense. The meter’s LED pulse frequency is deterministic—one pulse per unit of energy, always. The only reason calibration would drift is if your meter itself is miscalibrated, at which point your electricity bill is also wrong, and you have bigger problems.

Maintenance is vacuuming dust off the meter box once a year if you’re paranoid. That’s it.

The Data Quality Question

How accurate is this? The answer is: as accurate as your meter, which is legally required to be accurate to within 2 percent in most jurisdictions. Glow reads the meter’s own pulses, so it inherits the meter’s accuracy. If you’re comparing Glow data to your utility bill, they should match within rounding error. If they don’t, either your meter is failing (in which case your utility will replace it) or something weird is happening.

The data is real-time. You get pulse detection and power calculation as fast as the ESP32 can read the GPIO pin and transmit the update, which is on the order of seconds. Your utility bill is based on a different calculation (usually an average over 15 or 30 minutes) and is reported with a month-long delay, so comparing them directly is apples to oranges. But over a full day or week, they should line up.

The time-series data is clean because the pulse count is a discrete event. No smoothing, no interpolation, no anomaly detection that might lose actual data. You’re getting raw pulse counts and deriving power from the time between pulses. This means you can detect short power spikes that other monitors might miss, because you’re measuring at the resolution of the meter itself, not at a 15-second or 60-second sampling interval.

Integration With Your Stack

You’ve got Home Assistant, Grafana, Postgres 17, and a suite of ESPHome devices already running. Glow fits into this like it was designed for it, because it uses the same ESPHome infrastructure and Home Assistant integration layer. Same authentication, same entity naming, same data pipeline. It’s one more sensor in the energy dashboard. Your Grafana dashboards query the same database table where Glow logs its data alongside everything else you’re monitoring.

The firmware is open-source MIT, so if you ever need to fork it or modify it, you can. You own the data—it lives on your Postgres instance, on your Home Assistant instance, in your local network. No vendor lock-in. No “if we stop supporting your device” risk. If the repo goes dormant five years from now, the firmware you flashed still runs. The data you collected still exists.

The Decision

You already have “whole-house power surfaced into Grafana.” That sentence could mean a few things. If you’ve got a P1 cable running from a meter with an actual port and you’re already reading it directly, Glow becomes a second opinion at best and a wall ornament at worst. If you’re aggregating power from your per-outlet sensors (all those Eve smartplugs and metering relays), then Glow gives you independent verification and doesn’t rely on every outlet being instrumented. You could have a toaster that pulls two thousand watts and never plugged it into a smart outlet, and you’d never know. The meter knows. Glow tells you what the meter knows.

The active concerns are minimal. The project is maintained. The license is MIT, no weird proprietary firmware escrow. It’s hardwired into Home Assistant’s energy dashboard, which means data flows into your existing telemetry pipeline. Offline operation is fine—the device runs locally and pushes data over HTTP, so if your internet hiccups or Nabu Casa implodes, you’re still counting power. That’s actually respectful.

The power draw from the device itself is negligible—you’ll spend maybe a dollar a year on the electricity to run it. The hardware cost is trivial. The installation is literally “clip it into your meter box and flash firmware.” The learning curve is zero if you’ve already done Home Assistant and ESPHome. The maintenance is nonexistent.

The decision tree is simple. Do you want to know what your meter actually knows about your power consumption? Is that number different from your aggregated per-outlet estimate? If yes to both, flash Glow. If you’ve already got real meter-level data from somewhere else, you don’t need it. But if you’re currently wondering “are my smart outlets giving me the full picture?” then Glow answers that question with hardware that costs less than a pizza.

Scouted repo: klaasnicolaas/home-assistant-glow — 1269 stars. Verdict: ADOPT. Desk review, nothing was flashed or installed.