> ## Content Index
> Fetch the complete content index at: https://blog.coopnet.us/llms.txt
> Use this file to discover other available public pages before exploring further.

# Pricing an always-on homelab load at the rate it actually pays
- URL: https://blog.coopnet.us/always-on-core-monthly-cost/
- Published: 2026-10-21T13:12:46.000Z
- Updated: 2026-10-31T16:52:24.000Z
- Description: The boxes that never turn off should be priced at my top tier, all in rate, not the dashboard's blended average, which always runs low. Average watts times 730 over 1000 gives kWh a month. In Home Assistant that's an Integral helper, a billing cycle utility meter and one template.
- Author: Renstur
- Tags: Home energy, home-assistant, energy, homelab-cost

Home Assistant has priced my house's grid import since August 2026\. It runs off one template sensor that knows my tariff's tiers and seasons, and the Energy dashboard multiplies every kWh by it.

That's the right price for the whole house. It's the wrong price for the boxes that never turn off, and the gap only goes one way.

## Three charges on the bill, and the one a server pays

My tariff has the usual residential shape. There's a fixed monthly customer charge, a cheaper first block of 400 kWh, and a higher rate for everything after it. On top sit surcharges and taxes, and they're percentages of the energy charge rather than flat fees.

The house uses up that first block in roughly the first week of each billing cycle. After that, every kWh comes in at the top tier.

So the question "what does the lab cost?" has a clean answer. If I unplugged it, the customer charge wouldn't move and the cheap block would still get used by the house. The only thing that would drop is top-tier kWh. That's the marginal rate, and it's the one an always-on load should be priced at.

## Why the dashboard's average is the wrong number

Divide a month's energy charges by the month's kWh and you get a blended rate. It mixes the cheap block in, so it always sits below the top tier.

With example rates of 10 cents for the first 400 kWh and 13 cents after, a 1,500 kWh month blends to about 12.2 cents. A server priced at 12.2 instead of 13 looks about 6% cheaper than it is.

Small. Always in the same direction, though.

I found this the slow way. When I re-derived my per-circuit costs, the house totals had been too high (a separate bug, below) while the per-circuit figures had been slightly too low, because they used a blended rate. Anything that answers "what if I removed this load" now uses the top tier.

## Getting from the tariff line to an all-in rate

The rate printed in the tariff isn't the rate on the bill. Because the surcharges are percentages, the right correction is a multiplier, not a fixed amount added per kWh.

In my case the all-in top-tier rate ran about 10.6% above the raw tariff line. I multiply each tariff rate by that factor in the template, which lands the summer top tier at about 13 cents. If the tariff or a surcharge changes, the factor has to change with it. Nothing in Home Assistant will tell me that.

## Turning watts into a monthly figure

A month averages 730 hours (8,760 divided by 12). The arithmetic is short:

```text
kWh per month = average watts x 730 / 1000
cost per month = kWh per month x marginal all-in rate

```

At an example rate of 13 cents per kWh:

| Average draw | kWh per month | Cost per month |
| ------------ | ------------- | -------------- |
| 50 W         | 36.5          | $4.75          |
| 100 W        | 73            | $9.49          |
| 150 W        | 109.5         | $14.24         |
| 250 W        | 182.5         | $23.73         |

Every 10 W running around the clock is about 7.3 kWh a month, just under a dollar at that rate. That's the number I'd keep in my head when deciding whether an old box earns its idle draw.

## Measuring the core in Home Assistant

The formula needs a real average, and that needs a power sensor on the core: a smart plug, or a circuit monitor on the branch that feeds it. Home Assistant's docs route a watts-only sensor through the Integral helper to get energy. The config below matches the 2026.10 docs, checked in October 2026.

Turn watts into kWh with an Integral helper (prefix `k`, time `h`):

```yaml
sensor:
  - platform: integration
    source: sensor.core_power
    name: core_energy
    unit_prefix: k
    unit_time: h
    round: 3
    max_sub_interval:
      minutes: 5

```

The default method is trapezoidal, which the docs call the most accurate when the source updates often. If your plug sits on one value for long stretches, they recommend `left`. `max_sub_interval` makes it keep integrating while the reading holds still.

Then a utility meter that resets with the billing cycle, not the calendar month:

```yaml
utility_meter:
  core_energy_cycle:
    source: sensor.core_energy
    name: Core energy this cycle
    cycle: monthly
    offset:
      days: 14  # example: cycle opens on the 15th

```

My billing cycle doesn't start on the 1st, and that matters for anything that compares against a bill. Two things I hit doing this through the UI in Home Assistant 2026.09\. The offset is only offered when you create a utility meter, not in its options afterwards, so a wrong offset means recreating it. And a new meter starts at zero; `utility_meter.calibrate` sets it to the real cycle-to-date value.

Last, the price:

```yaml
template:
  - sensor:
      - name: "Core cost this cycle"
        unit_of_measurement: "USD"
        availability: "{{ has_value('sensor.core_energy_cycle') }}"
        state: >
          {{ (states('sensor.core_energy_cycle') | float(0) * 0.13) | round(2) }}

```

Swap `0.13` for your own all-in top-tier rate. If your house doesn't always clear the first block, this is where tier logic would go.

## The fallback that billed every hour at the top tier

That `availability` line is there because of my own rate template. It read the month-to-date meter by entity name and used `| float(9)` as its fallback.

Then the meter got renamed. Asking `states()` for an entity that no longer exists returns `unknown`, the conversion failed, and the template quietly used 9\. Nine was above the tier threshold, so Home Assistant priced every hour at the top tier until I caught it. That overstated the bill by about $12 a month.

Fixing the template didn't fix the past. Home Assistant records cost as consumption happens, so those dollars stay wrong in history. The kWh were fine the whole time.

A default that picks the expensive answer is worse than no answer. `has_value()` lets the sensor go unavailable instead.

## The same load on a time-of-use plan

My tariff also offers time-of-use. On-peak is four weekday evening hours, roughly 12% of a month's hours. On-peak costs about 2.7 times the flat top-tier rate and off-peak about 0.6 times, in both seasons.

A flat 24/7 load spends most of its life off-peak. Weighted out, it averages about 0.85 times the flat marginal rate, so the lab alone would be roughly 15% cheaper on time-of-use.

That's arithmetic from the published tariff, not a bill I've seen. The lab also doesn't decide the plan. The whole house's evening peak does, and that plan came with a one-year commitment.

## What I'd tell myself

Price the boxes that never sleep at the top tier, all-in, and leave the customer charge out. The cost sensor is only as honest as the rate behind it, so make a missing input go unavailable instead of expensive.