Home Assistant Glow: reading your smart meter by watching its pulse LED

Why the energy dashboard needs a workaround

The origin story is in the README and it explains the whole design. During an internship at Nabu Casa in the first half of 2021, the author worked on energy management for a house, collecting energy data and displaying it on a dashboard. Since Home Assistant release 2021.8, the Home Assistant Energy dashboard can display your energy usage. The catch, and the reason this project exists, is that not everyone has a smart meter or is equipped with a P1 port.

That is a real gap. A P1 port is a serial port on the meter that many Dutch and European meters have, and it delivers a clean data stream. The meters without one still have a pulse LED, whose flash rate is printed on the meter as imp/kWh, and that flash is the only signal most people have.

So Home Assistant Glow makes what the README calls a not so smart meter without a P1 port easily readable, by reading the pulse LED that is always present in most cases. The project works with ESPHome, and there is even a case designed to hide it all in your meter cupboard that you can 3D print yourself.

The result is a device rather than a piece of software. The repository has components/ and home-assistant-glow/ directories, and a glow-basic/ directory, alongside docs/ and a.yamllint file for the YAML that ESPHome uses. It is MIT licensed, copyright Klaas Schoute, and the homepage is glow-energy.io. The last push to the repository was on 2026-10-15, and the recent releases are 5.0.0 from 2026-06-07, 4.4.0 from 2026-02-18, and 4.3.1 from 2026-01-19.

Checking whether your meter will work at all

There is one check that decides whether the project is viable for you, and the README puts it before anything else.

To make sure your meter will work, you have to look for the imp/kWh rate on your meter. Make a note of this value because you may need it later when configuring your device.

That single number is the specification of the whole thing. The rate tells you how many flashes per kilowatt hour your meter emits, and the firmware uses it to convert a pulse count into an energy value. A meter with a different rate gives you a proportionally wrong number, which is why the value has to be recorded rather than assumed.

The check is a physical one. You look at the meter itself, find the rate printed on the faceplate, and check that it is the pulse rate rather than something else on the display. The project ships a picture of the pulse rate in its documentation for exactly this reason.

The limitation implied by the design is that the LED has to be visible. If your meter is in a cupboard with a solid door, the photodiode has nothing to see, and the 3D printed case, which is described as designed to neatly hide everything in your meter cupboard, is only useful if the light path is preserved. The README says the pulse LED is always present in most cases, and that word most is doing the work in that sentence.

The bill of materials, and why the ESP32 is recommended

The hardware list is short and specific, and the documentation links to suppliers for each part.

For the microcontroller you choose one of three, with the ESP32 recommended, an ESP32-C3, or an ESP8266. The ESP32 is the one to pick if you have no reason not to, and the reason is usually processing headroom and the availability of a good development board.

The sensing part is an LM393 photodiode, and the documentation carries a note worth reading before you order: you will not receive an LDR, so the light dependent resistor is not included and the photodiode is not interchangeable with it. The illumination side is a 5mm four pin RGB LED with a cathode, which is the light source the photodiode aims at, so that the pulse is read against a steady background rather than against whatever light happens to be in the cupboard. Wiring is done with female to female Dupont jumpers.

That last part is the trick worth understanding. The LED is not decorative. A meter pulse LED is usually dim, and the flash is easier to detect when the photodiode is pointed at a constant bright source with the pulse appearing as a dip or a rise against it. The RGB LED gives you a stable reference, and the colour is not important so much as the consistency.

The case is a 3D printed enclosure, and the documentation links to a resources page for the case folder, so the model files are part of the project rather than something you have to design yourself.

Getting the firmware onto the ESP, and the branch warning

The installation is browser based, and the important warning comes first.

The default branch shows development and may be ahead of the released version. For copying YAML code, use the release branch instead. And it is best to use the website to install the latest firmware on your ESP. The project documentation site at glow-energy.io has a complete walkthrough covering which hardware you need, how to install the correct firmware using the ESP web tools, and how to add the device to Home Assistant.

The ESP web tools route matters because it removes the flashing step from the user's side. You do not need a local toolchain or esptool, since the browser handles the flashing for you.

The branch warning is a real trap for anyone following the instructions from the repository rather than from the site. The default branch is develop, and the YAML on it describes a configuration that may not match the firmware you are actually running, which produces a device that connects but reports nonsense. The documentation's advice is to take YAML from the release branch and firmware from the website.

The two other ecosystems: ESPHome and Home Assistant

The project sits in the middle of two ecosystems, and understanding which does what is what makes it usable.

ESPHome is what the firmware is. The README says the project works with ESPHome, and the .yamllint file at the repository root is for the configuration files, which confirms that the device is defined as an ESPHome YAML configuration rather than as a hand-written firmware binary. The consequence is that the device is described in a declarative file, so the pin assignments, the calibration of the photodiode, and the pulse rate all live in a text file that you can read, diff, and put in version control.

Home Assistant is what consumes it. Once the device is running and added to Home Assistant, the pulse count becomes an energy reading, and the reason the project exists at all is that this feeds the Home Assistant Energy dashboard introduced in 2021.8. Everything before that was the reason to build the device.

The repository's shape reflects this layering. The components/ directory holds the ESPHome component definitions, home-assistant-glow/ and glow-basic/ hold the configurations for the two device variants, and docs/ holds the documentation site content. The topics attached to the project list esp32, esp8266, esphome, iot, smartmeter, and home-assistant, which is the same stack written out.

The community support is the usual arrangement for a hardware project. There is a Discord link, a discussion space, a code of conduct, and a contributing guide, and the project has a shop in the badge row, with the project site at glow-energy.io as the front door.

The optical trade-off, and what a P1 port would have given you

It is worth being blunt about what this device is and is not.

A P1 port gives you a serial data stream from the meter, and the meter tells you the consumption directly. The Glow instead counts flashes, which means the accuracy depends on the optical signal being clean. Ambient light in the cupboard, a meter that dims its LED as it ages, and a photodiode that needs calibrating for the brightness of your particular LED are all failure modes that a serial port simply does not have. The project mitigates these with the constant LED reference and the rate configuration, and it can be recalibrated, but the fundamental difference in signal quality remains.

The counter-argument is cost and availability. A P1-equipped meter or an add-on P1 kit is a purchase or an electrician's visit. An ESP32 and a photodiode is a parcel from AliExpress and an afternoon.

The third alternative is not to measure at the meter at all. Many households already have a plug-in energy monitor, and some have a smart meter with a network interface. If your measurement already reaches Home Assistant, this project solves a problem you do not have, and the honest advice is to check your existing setup first.

The fourth is the software-only alternative of estimating from device power sensors, which gives you per-device consumption rather than whole-house consumption. That is a different question, and for a question about one device, it is often the more useful one.

Editorial conclusion

Adopt Home Assistant Glow if your meter has a pulse LED but no P1 port, and you want your consumption in the Home Assistant energy dashboard. Do not adopt it if your meter already exposes P1 data, because a P1 port gives you a clean signal without any optical guessing. Verify first that your meter shows the imp/kWh rate, since the pulse LED is what the whole design depends on.

Frequently asked questions

Official sources

1. klaasnicolaas/home-assistant-glow on GitHub
2. License: MIT
3. Project website
4. README
5. Releases