Smarter electricity meter

People often mention switching off their geyser (electric water heater) for periods during the day when hot water is not needed in order to save electricity. And I have been wondering if I should be doing the same. How much would the savings be and would it be worth the hassle?

The problem is that I have no real, easy way of knowing if this makes a difference. The adage “if you can’t measure it, you can’t improve it” comes to mind.

We only have a prepaid electricity meter with a keypad, a small screen indicating the amount of units (kilowatt-hour) left and an LED that blinks 1000 times for every kilowatt-hour (kWh) used.

We can use the LED blinks to create a smarter electricity meter that will enable us to do the measurements we need. This method is hardly new, but I have always wanted to try it, and it seemed like a fun, useful project that could be done fairly quickly.

Technology Stack:

• Raspberry Pi (RPi) Pico W
• MicroPython
• Docker
• Grafana
• InfluxDB
• Apache
• Python
• Telegram Messenger
• Git
• Tailscale
• Raspberry Pi 4

The system

The solution consists mostly of things I had lying around and software I have used before.

A Raspberry Pi (RPi) Pico W and sensor are used to count the number of impulses from the electricity meter’s LED. The count value is written directly to an InfluxDB bucket from the RPi Pico W. Grafana is used to graph and display data from the InfluxDB bucket. The number of impulses can be counted over a period of time to derive the number of electricity units used. Along with a Rand value per unit, a cost can also be associated with the units used.

The hardware

The base of the sensor unit consists of a Raspberry Pi (RPi) Pico W with a Light Dependent Resistor (LDR) as a sensor to register the electricity meter’s LED blinks. The RPi Pico W has an analog-to-digital converter (ADC) that can be used to interface with the LDR.

Prepaid meter, RPi Pico W and sensor

For this application, the RPi Pico W could be powered from wall power and is in WiFi range for offloading measurement data.

I decided to give MicroPython a try for programming the RPi Pico W. I have not used it before this project, but it is pretty easy to pick up if you are familiar with Python. MicroPython made it fairly simple to implement an over-the-air (OTA) software update mechanism.

The software

The project software is all hosted “on-premises” on a Raspberry Pi 4. Docker (compose) is used to deploy InfluxDB, Grafana and Apache (more on this next paragraph).

To implement the rudimentary over-the-air (OTA) update mechanism, the MicroPython program on the RPi Pico W occasionally checks for updated software on the Apache web server. This consists of the new MicroPython script and a JSON file with the version number for the script. If there is a newer version, the RPi Pico downloads the Python script, replaces the current script and reboots to run the new software.

Using InfluxDB and Grafana, electricity usage can be logged and graphed over time and historical data can easily be accessed.

To improve usability, a Telegram Messenger bot was implemented. Telegram was used because it is quick and easy to implement a bot in Python for the messaging service. The user interacts with the bot using a Telegram chat and has commands to get the current number of units on the meter and a command to set a new unit value.

The Telegram bot can be used to query the current number of units left on the prepaid meter. This was implemented by allowing the user to use the bot to set the new meter reading after buying units. The number of units used since the value was set can be queried by the bot from the database. The units that have been used can then be subtracted from the set meter reading to get the current estimated meter reading.

At the moment, this is working well enough, but it seems that a small number of impulses are getting lost over time. But this is low enough to be investigated in the future at some point. The bot runs locally on the Raspberry Pi 4.

The Telegram bot periodically checks the amount of units left on the electricity meter and sends the user a warning message using Telegram if the value falls below a threshold value. This is quite useful.

All software is version controlled using Git and Grafana is accessible from outside the LAN using Tailscale.

Results

With a method in place to measure the amount of electricity used, it is now possible to investigate further. This section shows some of the interesting observations.

The main graph in the figures below shows the number of electricity meter impulses binned per minute. With the total number of kWh for the time period in the top left and cost in Rand next to it.

The figure below shows the electricity usage of our oven. Where you can see the oven is on for about 10 minutes while it gets up to temperature and then it can be seen switching on and off to maintain the temperature.

If you zoom in to show only the period for which the oven is on, you see that the oven uses about 0.87 kWh at a cost of around R3.40 for the 30 minutes it was on.

Graph - oven

The next figure shows a period of time from approximately midnight to 07:00 the next morning. In the main graph you see our fridge periodically switching on around every hour. The big spike in the middle of the graph is the geyser switching on to maintain the water temperature (without any hot water being used at the time).

This spike typically only occurs once, maybe twice a day, if no hot water is used.

Graph - Geyser wide

The figure below shows the graph zoomed in on just the spike and shows this event used around 0.73 kWh at a cost of around R2.86 and lasted about 10 minutes. These numbers would include a base electricity usage of other items that are also on, but should be relatively small over the small time period. Possibly on the order of 20 cents.

Graph - Geyser narrow

Conclusion

If we assume that the cost per unexpected switch-on shown above is about R2.50 and that happens twice a day. This would equate to around R155.00 a month. Which would roughly be around 12% of our total electricity spend. This cost is specific for our installation.

But I doubt that would be the direct saving if we started switching off our geyser during the day. Because you would have to switch on the geyser at some point and it would have to heat the water from whatever temperature it had dropped to, which might negate the supposed savings.

It is also difficult to factor in the extra inconvenience of having to switch the geyser on and off. This could be alleviated by installing a switch that can be remotely operated or automated.

The first port of call with trying to minimise electricity usage related to water heating would be to ensure that the geyser is well insulated and the heating element is not set to its maximum value (but not low enough to allow bacteria growth).

Should we be switching off our geyser (electric water heater) during the day? I still don’t know, but at least it feels like I have better insight into our electricity usage. Along with the added benefit of being able to remotely check the amount of units left and get notifications when we are close to running out of electricity.

The next step would probably be to try and measure the geyser energy usage directly, which would give cleaner signal (and maybe add some AI to control the geyser 😂).