Our apartment came with a refrigerator. It was alright, it made things cold, it kept them cold. It was also incredibly noisy, and no matter how much I fiddled with its settings, the compressor was always running and any ice cream left in the deep freeze part got rock solid.¹

When I hooked up one of my smart plugs to it, I soon learned why: one of the two compressors was running all the time. This lead to a huge block of ice forming on the back of the main compartment, and the deep freeze section icing up really quickly. I suspect that the thermostat may have been busted and contributed to the issue, but after trying to repair a dishwasher, getting cut about 10 times on my hands and losing, I had zero interest in attempting another home appliance repair on my own.

The refrigerator was the UPO Jääkarhu (jääkarhu means polar bear in Finnish), and the manual that the previous owner had still kept around had July 1995 on it, meaning that the refrigerator was about the same age as I am: 30 years old. Not bad at all for a home appliance!

I shopped around for a new refrigerator and got a decent one that’s about the same size, except newer. I won’t mention the brand here because they didn’t pay me anything and this post really isn’t a refrigerator review, but it was in the low-to-midrange class, sporting a “no frost” feature, and could be bought for about 369 EUR in Estonia in the summer of 2025. Based on some napkin math, I assumed that within a few years, the electricity savings will cover the upfront cost of buying the new refrigerator, assuming that it doesn’t break down.

After letting it run for a while, I had some data!

Turns out that the old one consumed 3.7x more electricity compared to the new one.

Here are some typical daily power consumption numbers:

• old refrigerator: 2.6 kWh
• new refrigerator: 0.7 kWh

The difference is more noticeable if we zoom out a bit.

Moving from ~78 kWh to ~21 kWh consumed each month is nice. Around the time we replaced the refrigerator, we also got a working dishwasher, and with those two combined I saw a solid 10-20% decrease in the overall power usage of the whole apartment. We went from using 334 kWh in June to 268 kWh in July, 298 kWh in August and 279 kWh in September.

Remember that napkin math I made earlier? If we assume about 57 kWh savings per month, and an average electricity price of 17 cents per kWh (based on actual rates during August 2025), it will take about 38 months or a bit over 3 years for the new refrigerator to pay off in the most pessimistic scenario. The pay-off will likely be larger if we account for energy prices usually rising during winter.

Don’t worry about the old refrigerator, we gave it away to a person who needed one for their new home in the short term as a stopgap until they get further with renovation work. Even got some good chocolate for that!

The only point of concern with this change is that I don’t really trust the new refrigerator to last as long as the old one. The previous one was good for 30 years if you look past the whole ice buildup, heat and noise, but with the new one I suspect that it’s not going to last as long.

At least my new refrigerator doesn’t have a Wi-Fi-connected screen on it!

I use Uptime Kuma to check the availability of a few services that I run, with the most important one being my blog. It’s really nice.

Today I wanted to set it up on a different machine to help troubleshoot and confirm some latency issues that I’ve observed, and for that purpose I picked the cheapest ARM-based Hetzner Cloud VM hosted in Helsinki, Finland.

Hetzner provides a public IPv6 address for free, but you have to pay extra for an IPv4 address. I didn’t want to do that out of principle, so I went ahead and copied my Docker Compose definition over to the new server.

For some reason, Uptime Kuma would start up on the new IPv6-only VM, but it was unsuccessful in making requests to my services, which support both IPv4 and IPv6. The requests would time out and show up as “Pending” in the UI, and the service logs complained about not being able to deliver e-mails about the failures.

I confirmed IPv6 connectivity within the container by running docker exec -it uptime-kuma bash and running a few curl and ping commands with IPv6 flags, had no issues with those.

When I added a public IPv4 address to the container, everything started working again.

I fixed the issue by explicitly disabling the IPv4 network in the Docker Compose service definition, and that did the trick, Uptime Kuma made successful requests towards my services. It seems that the service defaults to IPv4 due to the internal Docker network giving it an IPv4 network to work with, and that causes issues when your machine doesn’t have any IPv4 network or public IPv4 address associated with it.

Here’s an example Docker Compose file:

name: uptime-kuma
services:
  uptime-kuma:
    container_name: uptime-kuma
    networks:
      - uptime-kuma
    ports:
      - 3001:3001
    volumes:
      - /path/to/your/storage:/app/data
    image: docker.io/louislam/uptime-kuma
    restart: always
networks:
  uptime-kuma:
    enable_ipv6: true
    enable_ipv4: false

That’s it!

If you’re interested in different ways to set up IPv6 networking in Docker, check out this overview that I wrote a while ago.

This post isn’t a detailed line-by-line tutorial on how to set up each individual piece of the setup as those types of guides tend to get out of date really easily, but if you know your way around Linux and the command line, then you can definitely replicate this setup on your own.

Over the past few years I’ve been interested in learning about how much energy my computing setup and home appliances use. I’ve used a simple digital energy meter before to get instantaneous readings, but that was not ideal for monitoring how an electrical appliance consumes power over a longer time period.

My friend bought a few smart plugs from athom.tech. After getting confirmation that they don’t suck, I went ahead and ordered some myself.

The smart plugs I bought were the EU style plug V3 variant. The shipping times in EU were reasonably fast, shipping in 9 days (and that included Christmas!).

The plugs ship with Tasmota pre-flashed. The plugs come with a small paper strip explaining the steps to take to connect the plug to your Wi-Fi network, and after that you can manage the plug in your browser.

Updating the firmware to the latest version is easy and doable in the web GUI with just a few clicks.

The software stack

My initial goal with these plugs was to visually monitor the power consumption of a few devices, such as my home server, router, workstation setup and the electric water heater.

The power meter data is collected to an existing Prometheus instance on my home server. If you’re not sure what Prometheus is, then think of it as a tool that periodically reads metrics from different sources, saves them to disk and allows you to later query and manipulate that information.

I run multiple instances of this tasmota-power-exporter solution on my server, one per plug, which get scraped once per second by the Prometheus instance. It is possible to also make the plugs themselves export these metrics, but I didn’t fancy building Tasmota firmware myself, yet.¹

I already had a Grafana instance running on my home server, so I reused that to show a few basic graphs for the power meter setup.

Free tech tip: make sure to change the min step setting to 1 second to get the most detailed data points on your graphs.

Observations and findings

So, what have I learned after running this setup for almost 4 months?

Water heater

It shouldn’t come as a surprise that the electric water heater uses up the most power. The one we have is a 30L one, just enough for a quick shower or two or for washing a large load of dishes.

Typical power usage: 4.51 kWh/day.

Minimum observed: 0.56 kWh/day, happens usually when nobody is at home

Maximum observed: 11.1 kWh/day, a lot of washing and showering happened on that day

Home server setup

I run all my home server workloads off of a Zimaboard. One of its big selling points for me was its super low power consumption. When idling, the Zimaboard can use about 2 W, typical power usage with all my services running was about 7 W and the maximum power consumption was around 15 W.

The Zimaboard was actually using less power than my internet modem/router box (which is hot garbage by the way). The ISP-provided box used 12-14 W at all times, regardless if it was operating in router or bridge mode.

At one point I temporarily switched my home server setup back to the ASRock Deskmini X300, mainly because I added some latency-sensitive workloads onto my home server setup and the Zimaboard was a bit too weak for those.

One thing that became really obvious from the power meter is that the Deskmini idle power consumption is horrible in comparison to the Zimaboard, coming in at around 15-20 W. This might be in part because my Deskmini doesn’t seem to expose any lower CPU power states than C3 while the Zimaboard exposed C-states all the way down to C10. I could not find a way to expose lower C-states in UEFI settings or the Linux kernel. Based on a quick remark in this video I believe that it should be possible to drop ASRock a message and receive a custom BIOS that enables some extra features, but that seems even more unlikely for a consumer-grade device such as this one.

I’ve added a panel to my usual Prometheus node exporter Grafana view that shows the server setup power consumption alongside other metrics. Higher CPU activity is clearly visible on the power consumption graphs.

Voltage

The Tasmota plugs also report current voltage values. I graphed them just for fun, but noticed that there is a sort of seasonality to the values. During the usual peak power consumption hours the voltage drops across the board.

This seems like a candidate for testing anomaly detection, as shown in this great GitLab article. I’ve used this concept at work and it works reasonably well for some metrics.

In other cases the voltage drops were caused by running appliances that use a lot of power, such as the water heater, electric kettle, electric stove or the microwave.

During cooking with an electric stove, the on-off cycles were also noticeable on the voltage reading on all of the plugs.

Workstation

I have one plug that reports numbers for everything that’s connected to my home office setup: monitor, USB-C dock, monitor light bar and anything that might be charging on the table.

The power consumption of this setup varies a lot. Sometimes I do a longer home office stint. Sometimes I recharge various devices.

The typical power consumption of the whole setup while doing something on my computer is around 45-60 W, with peaks near 90-110 W. For an ultrawide monitor, USB-C dock and my laptop I think this is a pretty good result. I’ve had desktop PC-s that have used just as much power at idle, and in the olden days there were incandescent light bulbs that used up more electricity than this!

Typical power usage: 0.95 kWh/day.

Minimum observed: 0.07 kWh/day

Maximum observed: 1.52 kWh/day

Charging

These plugs are also great for observing the charging patterns of various devices.

A laptop or a power bank charges faster at the beginning, but the speed drops off as the battery gets more full. At one point trickle charging seems to kick in until the device is fully charged.

This pattern is similar on most devices that I charge. The battery on my e-bike seems to be an exception to the rule, with a slighly increasing power consumption throughout, and a faster drop at the end of the charging cycle.

0.5kWh of power consumed for 60km of range with the “Turbo” preset on the bike doesn’t sound bad at all. Half a cent per kilometer!

Stability

The stability of the smart plugs is usually fine, but there are frequent cases where certain plugs don’t report back in time with the statistics. This may be a Wi-Fi access point issue, but annoying nevertheless.

I’ve had to completely power cycle two plugs a few times because they dropped off from the network completely and would not come back. Again, could be the fault of my Wi-Fi AP.

Future ideas

The plugs also provide a way to turn the devices on and off over different API-s (even over HTTP!), which is something I’d like to utilize either using something like Home Assistant, or a simple script that toggles certain devices on and off based on the current electricity price.

I haven’t gotten around to this part yet, but from my research it seems that the necessary integrations exist for Home Assistant.

Closing thoughts

Overall, I’m very happy with this setup. I can get reliable measurements for all sorts of computing setups from now on, which will make judging the power efficiency of the devices I use much easier. No more guesswork!

If you enjoyed this post, then I highly recommend giving this FOSDEM 2024 talk by Florian Quèze a listen. The talk also goes into details about measuring the power consumption of various devices in the speakers’ home and observations that they’ve made.