Power Monitoring with Home Assistant: Tracking What Your Home Lab Actually Costs

I used to wave away questions about what my home lab cost to run with a confident “oh, not much”. Then I put a meter on it. The rack idles at 140 watts, which doesn’t sound like a lot until you do the maths: 140W is roughly 1,226 kWh a year, and at my tariff that’s about £370 just to keep the lights blinking. Measuring it didn’t make it cheaper, but it stopped me lying to myself, and it surfaced a couple of genuine surprises. The whole exercise takes an evening and one cheap smart plug, and the data it produces is the kind you can actually act on rather than the vague guilt of a quarterly bill that lumps the lab in with the kettle and the tumble dryer.

Getting a number into Home Assistant

You need a meter that reports power draw and something to read it. The cheapest credible option is a smart plug running local firmware — a Tasmota or ESPHome flash on something like a Sonoff or Shelly. Avoid cloud-only plugs; you want the data on your own broker, not Tuya’s.

A Shelly Plug S, for example, exposes its power reading over its local HTTP API and integrates natively. If you want to build your own sensor rather than buy one, an ESP board flashed with ESPHome and a clamp or inline current sensor does the same job and reports straight into Home Assistant over its native API — I go through that build in ESPHome: building custom sensors for Home Assistant. For a Tasmota-flashed plug, the values arrive over MQTT, and a template sensor pulls the wattage out:

1
2
3
4
5
6
7
8

mqtt:
  sensor:
    - name: "Rack Power"
      state_topic: "tele/rack_plug/SENSOR"
      value_template: "{{ value_json.ENERGY.Power }}"
      unit_of_measurement: "W"
      device_class: power
      state_class: measurement

The two fields that matter for the Energy dashboard are device_class: power and state_class: measurement. Get those wrong and Home Assistant will refuse to integrate the reading into kWh, and you’ll spend an hour wondering why your shiny dashboard is empty.

Why local firmware and not the cloud app? Two reasons. The obvious one is privacy — a cloud plug phones its manufacturer’s servers with a timestamped log of exactly when your machines draw power, which is a surprisingly detailed picture of your household. The less obvious one is reliability: the day Tuya has an outage or deprecates an API, your “monitoring” evaporates, whereas a Tasmota plug publishing to your own MQTT broker keeps working whether or not the manufacturer still exists. Owning the data end to end is the entire point of doing this at home rather than reading a number off an app.

From watts to money

Home Assistant can integrate instantaneous power into cumulative energy, but it’s cleaner to use a plug that reports a lifetime kWh total directly. If yours only gives you watts, the Riemann sum integration bridges the gap:

1
2
3
4
5
6
7

sensor:
  - platform: integration
    source: sensor.rack_power
    name: rack_energy
    unit_prefix: k
    round: 2
    method: trapezoidal

That produces a sensor.rack_energy in kWh that only ever climbs. Feed that into the Energy dashboard (Settings → Dashboards → Energy → Add Consumption). Set your tariff in the same place — a flat rate, or a more elaborate cost-tracking sensor if you’re on a time-of-use plan and want to know whether your nightly backup job is sneaking into the cheap window.

A word on why the integration method matters. trapezoidal averages consecutive readings, which is the right call for a value that drifts up and down like power draw; the older left and right methods bias the result depending on which end of each interval they sample, and over a month that bias adds up to a real error in your kWh total. If your reported energy looks suspiciously high or low compared with what your actual electricity bill says, the integration method and the reporting interval of the plug are the first things to check. A plug that only reports every 30 seconds will miss short spikes entirely, which for a mostly-idle lab is fine but for a machine that bursts hard on a schedule can undercount.

The surprises

Three things jumped out once I had a week of data.

First, idle is most of the bill. My lab almost never does anything strenuous, so the 140W floor — drives spinning, fans turning, a couple of NVMe pools, the switch and the UPS — accounts for the overwhelming majority of the cost. Chasing peak efficiency on workloads that run for ten minutes a day is pointless when the baseline runs 24/7.

Second, one machine was a pig. An old Xeon box I kept “just in case” was pulling 65W on its own to do nothing. I’d been telling myself it was free because it was already paid for. It was costing me £170 a year to sit in standby. It’s now off, sitting in a cupboard as a cold spare, and I haven’t missed it once in months. The lesson generalises: “already paid for” is a sunk cost, and an idle server keeps charging rent in watts long after the purchase price stopped mattering. A machine has to earn its idle draw with something you actually use, or it should be off.

There’s a subtler version of this too. Older hardware isn’t just slower — it’s often dramatically less efficient per unit of work. That Xeon predated the aggressive idle power states modern chips use, so it couldn’t drop into a low-power floor the way a recent low-TDP CPU does. A newer, smaller machine can pay for itself in electricity alone over a couple of years while doing the same job faster, which is not an argument I expected the meter to hand me but there it was in the graph.

Third, the UPS lies a little. Conversion losses mean the wall meter reads higher than the sum of what’s plugged into the UPS. A double-conversion (online) UPS runs everything through its inverter continuously and can lose 8–12% to that overhead; a line-interactive unit is more efficient at idle but still isn’t free. Worth knowing if your numbers don’t add up — you’re not going mad, you’re just paying for the UPS’s own overhead. The honest, whole-picture version of this accounting — electricity plus the hours you sink in — is the argument I make in the real cost of self-hosting; the meter only measures the easy half.

When the numbers look wrong

A short troubleshooting list, because they will look wrong at some point:

• Energy dashboard stays empty. Almost always the state_class/device_class pair, or you fed the raw power sensor (W) into the dashboard instead of the integrated energy sensor (kWh). The dashboard wants a monotonically increasing total, not an instantaneous reading.
• kWh total jumps or resets. If Home Assistant restarts and your integration sensor loses its state, it can reset to zero and the dashboard sees a negative delta. Use a plug that reports its own lifetime total where you can; it survives restarts because the counter lives in the device, not in Home Assistant.
• Wall meter and plug totals disagree. Expected — the wall meter includes the UPS overhead and anything not on the metered plug. Meter at the wall for the true bill, meter per-machine to know where it goes, and don’t expect the two to sum neatly.
• Wattage flickers to zero. A flaky MQTT connection or a plug on the edge of Wi-Fi range drops readings, which the integration then treats as genuine zero-power intervals and undercounts. Fix the connectivity before you trust the totals.

Making the data nag you

A number you have to go and look at is a number you’ll ignore. I added a template sensor that turns this month’s consumption into a running cost, and a simple automation that pings me if the lab’s draw stays above a threshold for an hour — usually a sign something kicked off a runaway job or a fan controller failed.

1
2
3
4
5
6

template:
  - sensor:
      - name: "Lab Cost This Month"
        unit_of_measurement: "GBP"
        state: >
          {{ (states('sensor.rack_energy_monthly') | float(0) * 0.30) | round(2) }}

Drop that on your main dashboard. There’s nothing like watching a real money figure tick upward to cure the urge to leave three idle VMs running.

Acting on the numbers

Measurement is only half the exercise; the point is to change something. Once I could see where the watts went, a few moves paid off immediately.

The biggest lever is consolidation. Three lightly-loaded machines each drawing 40–60W at idle almost always cost more than one machine that carries all their workloads, because idle draw doesn’t scale down with utilisation — a box doing 5% of its capacity draws nearly as much as one doing 50%. Virtualising or containerising the small stuff onto a single always-on host and switching the rest off is the single highest-value thing metering reveals. This is the same logic behind not over-buying in the first place, which I unpick in the home lab upgrade trap: the machine you don’t run costs nothing to power.

The second lever is spinning disks. A rack of hard drives is a meaningful, constant draw, and much of it is spent keeping platters spinning for data nobody is reading. Moving cold storage to drives that spin down, or consolidating onto fewer larger disks, trims the idle floor directly. NVMe for the hot working set and a smaller number of large HDDs for bulk is both faster and cheaper to run than a big pile of older, smaller mechanical drives.

The third is scheduling. If you’re on a time-of-use tariff, pushing anything batch-shaped — backups, media transcodes, model training runs — into the cheap overnight window costs nothing and can shave a real slice off the bill. Home Assistant automations can start and stop containers or wake machines on a schedule, so the lab does its heavy lifting when electricity is cheapest and idles the rest of the day.

Is it worth it / who is this for

If your home lab is a single low-power mini PC, honestly, don’t bother — it’s costing you a few pounds a month and the meter won’t tell you anything you can act on. The juice isn’t worth the squeeze.

But if you’re running a rack, multiple machines, or anything with spinning disks and a UPS, metering is the most clear-eyed thing you can do. It cost me one smart plug and an evening of YAML, and it directly led to decommissioning a machine that was burning £170 a year for nothing. The verdict: for anyone whose lab has crept past “one box in a cupboard”, power monitoring pays for itself almost immediately — not in saved watts, but in the lies it stops you telling yourself.