Home Assistant Utility Meter Tariffs: Peak and Off-Peak Configuration

Quick Summary (TL;DR)

Use Home Assistant Utility Meter to split one reliable cumulative grid-import energy sensor into separate peak and off-peak kWh registers. Define the supplier’s actual time windows, create a tariff-aware meter, and use a time automation to set its active tariff. Calculate money from each accumulated energy register and the corresponding contractual unit rate. Do not mistake the Utility Meter tariff select entity for a price feed: it chooses which counter receives new energy, while the prices must be supplied separately.

For the example used throughout this guide, off-peak is 00:30–05:30 local time and peak applies at all other times, every day. This is an illustrative schedule, not a recommendation for a particular UK supplier; substitute your own actual tariff windows, weekend rules, tax treatment and timezone. Home Assistant stores the counters across restarts, but the start of a counter’s first billing cycle is incomplete and missed measurements cannot automatically be reconstructed. Use a reliable energy meter AliExpress price and validate against the utility bill before trusting financial totals.

If you only need a visual dashboard, first implement the two counters and their tariff switch. For automation of EVs, water heaters or appliances, keep load management separate from accounting, and use native safety protections; see our price-aware automation guide (forthcoming). This page is a detailed configuration and quality-control tutorial, not a forecasting or dynamic-trading strategy.

What Utility Meter actually does — and what it does not

A cumulative source energy sensor reports how much electricity has been imported in total, normally in kilowatt-hours (kWh). Suppose it reads 12,050.4 kWh at noon and 12,052.1 kWh an hour later. A correctly configured utility meter calculates the 1.7 kWh increment and assigns it to the tariff active when the source reports that increment. Each tariff gets its own counter, so you can see both energy totals for a day, week or month. These counters are virtual accounting buckets; they do not change the supplier’s physical meter or the contract.

The integration supports daily, monthly and other reset cycles; tariff sensors are persistent across normal Home Assistant restarts. With tariffs configured, it creates a select entity for the active tariff and one counter sensor per tariff. You must change the select at the correct contract boundary yourself, typically with an automation. A timetable mistake will allocate valid kWh to the wrong bucket even if the source sensor is perfectly accurate. A price mistake will apply the wrong money rate to correctly allocated kWh. Diagnose those two problems independently.

Component	Home Assistant example	Purpose	Common misconception
Physical import sensor	`sensor.grid_import_total_kwh`	Cumulative grid energy purchased	Instantaneous watts are not the same input
Tariff-select entity	`select.grid_import_daily`	Chooses current tariff bucket	Not a supplier price sensor
Peak meter	`sensor.grid_import_daily_peak`	Peak kWh for current cycle	Does not multiply by price automatically
Off-peak meter	`sensor.grid_import_daily_offpeak`	Off-peak kWh for current cycle	Does not ensure an EV charges then
Cost template	`sensor.grid_import_daily_cost`	Estimate from kWh and prices	Not a legally authoritative bill
Energy dashboard	Grid-import long-term statistic	Visualise purchased energy and cost	Do not add both source and derived kWh as separate purchases

Official documentation: Home Assistant Utility Meter describes tariff counters, select entities, reset periods and actions; Integrating your electricity grid explains the physical metering and Energy dashboard assumptions. Keep those pages handy because entity naming and helper interfaces may change between releases.

Before buying or configuring hardware: verify the energy source

The most important input is a single, dependable sensor representing cumulative grid import at the electricity supplier’s billing boundary. A dashboard displaying “house consumption” may include solar self-consumption and battery discharge that have never crossed the utility import register. Conversely, a signed net-flow sensor can show a negative reading during solar export. Either case can produce incorrect purchased-energy totals if handed straight to Utility Meter.

Use a device with a documented energy counter, an appropriate integration and sufficient update reliability. Some smart meters expose import registers through an approved supplier interface; DIN-rail meters and compatible CT devices can provide local readings if installed correctly. CT installations and mains wiring belong to a competent electrician. CT ratio, phase alignment, direction and meter location matter more than refreshing a dashboard every second. For a three-phase property, establish whether your source adds phase imports in the same way that the retail meter bills them.

Source type	Suitable for tariff allocation?	Check before use	Buying implication
Supplier import-register kWh	Usually the best reference when accessible	Refresh interval, timestamp, cumulative semantics	May need an approved gateway
Locally integrated DIN-rail import energy meter AliExpress price	Yes, if it matches the bill boundary	Phase support, proper installation, calibration	Professional installation and enclosure
CT meter with cumulative import kWh	Often suitable	CT orientation, sign, phase pairing, gaps	Select approved CT set and correct rating
Total home load kWh	Usually no for import billing	Includes solar/battery contributions	May be useful for load analytics only
Signed grid power in watts	Only after appropriate energy integration	Power-to-energy integration, direction, resets	Not an immediate drop-in replacement
Per-device smart plug AliExpress price kWh	Not for whole-home supplier billing	Only measures attached appliance	Useful for appliance comparisons

In Home Assistant Developer Tools → States, watch the source value over several hours of normal consumption. It should generally increase, retain a consistent unit and agree approximately with the meter’s visible register. Under solar export conditions the import total should not decrease. Where there is a reliable cumulative imported-energy entity, prefer that over inventing a counter from instantaneous readings. If you only have watts, first build and validate a separately documented energy integration and then feed its accumulated kWh to Utility Meter.

A compatible energy statistic normally carries the energy device class, total or total-increasing state class, and a supported energy unit. These matter to long-term statistics and the Energy dashboard. The Utility Meter helper itself can consume source readings that meet its requirements, but a visually plausible state value is not proof that its statistics or historical gaps are correct. Our Energy dashboard sensor configuration guide explains import and export entity boundaries; bill verification guide covers independent checks.

Choose a tariff model before writing YAML

A simple two-rate contract consists of an ordered set of time windows and two monetary rates. But the time definition is not necessarily “cheap at night”. Some suppliers offer weekend off-peak rates, seasonal windows, special EV registers or fixed daylight-saving definitions. Others change the retail schedule after a contract renewal. The supplier’s current contract terms determine the schedule, not the generic label “Economy 7” or “night rate”.

Contract pattern	Required tariff logic	What a naive two-trigger rule misses
Daily night window	Two transitions on every local day	Overnight window crossing midnight
Weekday peak; weekend all off-peak	Weekday and weekend-aware selection	Saturday and Sunday plus Monday transition
Three rates	Peak, shoulder, off-peak buckets	A second low-price period or shoulder block
Seasonal rate windows	Date/season-aware schedule	Summer or winter contract changes
Different public-holiday rules	Holiday calendar from authoritative source	National and regional holidays
Dynamic 15/30/60-minute settlement prices	Timestamped interval data and consumption	Utility Meter two-rate buckets are not a substitute for interval accounting

Copy the actual off-peak start and end times into a small written specification. Include the time zone used by the supplier, whether weekends differ, and what happens on the two daylight-saving transition days. For the worked build below, the period is every day from 00:30 inclusive until 05:30 exclusive, interpreted in Home Assistant’s local time. We use this simple case so that the configuration remains auditable. A different contract will require adapting the boundary logic.

Method A: create Utility Meter helpers in the interface

For most installations the graphical user interface is the quickest path. Open Settings → Devices & services → Helpers → Create helper → Utility Meter. Use the cumulative grid-import sensor as the input. Create a daily helper named “Grid Import Daily” with two supported tariffs named peak and offpeak. Repeat with a monthly helper named “Grid Import Monthly”, also selecting the same original cumulative source; do not feed the daily helper into the monthly helper, because resets introduce another layer of interpretation.

Choose the source: a verified cumulative grid-import energy entity, not current power and not total household demand.
Select reset cycle: daily for daily cost breakdown, monthly for calendar-month tracking; both can observe the same source independently.
Enter tariff names: use stable lower-case tokens such as peak and offpeak on both meters.
Save and inspect: find the resulting select entities and the per-tariff sensors under Developer Tools → States.
Verify real entity IDs: Home Assistant may suffix an existing or conflicting ID; never assume an example entity ID was assigned exactly.
Test manual selection: change peak/off-peak and confirm which counter increments during a small measured load, then restore the correct tariff.

The helper provides accounting entities; it does not automatically know the supplier’s tariff schedule. Create the switching automation described below. If your Home Assistant installation was configured with legacy YAML meters, do not make duplicate helpers using the same names until you understand which sensors and long-term statistics the dashboard references. Duplicate entities often acquire _2 suffixes and make an otherwise correct automation silently address the wrong select.

Method B: YAML configuration for daily and monthly meters

The example below is suitable for the configuration.yaml integration layout, assuming the physical entity really is sensor.grid_import_total_kwh. Replace that placeholder with your actual energy meter AliExpress price. These two independent utility meters read the same source and maintain daily and calendar-month peak/off-peak totals. Do not paste this over an existing utility_meter: section without merging it: a YAML file should not contain two competing top-level keys with the same name.

utility_meter:
  grid_import_daily:
    source: sensor.grid_import_total_kwh
    name: Grid Import Daily
    cycle: daily
    tariffs:
      - peak
      - offpeak

  grid_import_monthly:
    source: sensor.grid_import_total_kwh
    name: Grid Import Monthly
    cycle: monthly
    tariffs:
      - peak
      - offpeak

This produces tariff selectors such as select.grid_import_daily and select.grid_import_monthly, with sensors like sensor.grid_import_daily_peak and sensor.grid_import_monthly_offpeak in a typical installation. Inspect the actual registry names. The first cycle starts only when the helper is created: a monthly sensor deployed on the seventeenth will not retroactively reproduce consumption from the first sixteen days. It is normal for the first month to be incomplete; validate from the beginning of a full cycle.

Keep delta_values: false for a genuinely cumulative kWh source: the integration uses differences between successive cumulative readings. Set it to true only when the incoming values are incremental energy quantities for each update rather than running totals. Treat net_consumption with care, because it allows negative differences: a source that occasionally reports negative or reset values can badly distort an import-only accounting system when configured as a net meter. Always verify exactly what the device publishes.

Automate the off-peak boundary with select.select_option

Home Assistant’s documented way to change tariff is the standard select.select_option action targeting the utility meter select. The following automation uses two daily time triggers. At 00:30 it selects the off-peak tariff; at 05:30 it selects peak. Both daily and monthly buckets change together. The trigger.id expression is deliberate: it avoids hidden assumptions about which trigger fired.

automation:
  - id: grid_import_tariff_daily_switch
    alias: Grid import - select peak and offpeak tariff
    description: Use actual supplier time windows in local Home Assistant time.
    triggers:
      - trigger: time
        at: "00:30:00"
        id: offpeak
      - trigger: time
        at: "05:30:00"
        id: peak
    actions:
      - action: select.select_option
        target:
          entity_id:
            - select.grid_import_daily
            - select.grid_import_monthly
        data:
          option: "{{ trigger.id }}"
    mode: single

This is a valid simple timetable when Home Assistant runs continuously and the rate windows really match the example. It does not cover every failure. If the server is offline at 00:30 and restarts at 02:00, the missed clock trigger will not necessarily execute later. The tariff select can remain stuck on peak until the next transition. That causes incorrect historical allocation of energy during the outage and after recovery. Add the startup-and-periodic reconciliation below so the active tariff matches the current clock, and explicitly flag any meter-history gap rather than assuming lost kWh can be recovered.

Make the tariff selection restart-safe

A robust arrangement does not rely exclusively on edge triggers at the exact boundary. Every time Home Assistant starts, and at a modest periodic interval, it should calculate which tariff ought to be active now. This does not rewrite the history of readings accumulated while offline. It merely prevents the wrong selection from persisting after recovery. A periodic check every five minutes is a pragmatic watchdog, not a precise tariff timestamping engine. Use the primary boundary triggers above for accurate online changes.

automation:
  - id: grid_import_tariff_reconcile
    alias: Grid import - reconcile current tariff
    description: Correct selection after restart or a missed clock trigger.
    triggers:
      - trigger: homeassistant
        event: start
      - trigger: time_pattern
        minutes: "/5"
    actions:
      - variables:
          expected_tariff: >-
            {% set n = now() %}
            {% if (n.hour == 0 and n.minute >= 30) or
                  (1 <= n.hour < 5) or
                  (n.hour == 5 and n.minute < 30) %}
              offpeak
            {% else %}
              peak
            {% endif %}
      - repeat:
          for_each:
            - select.grid_import_daily
            - select.grid_import_monthly
          sequence:
            - condition: template
              value_template: >-
                {{ states(repeat.item) not in
                   ['unknown', 'unavailable', expected_tariff] }}
            - action: select.select_option
              target:
                entity_id: "{{ repeat.item }}"
              data:
                option: "{{ expected_tariff }}"
    mode: single

For commissioning, test both boundary times with the automation trace, then deliberately restart Home Assistant at a time inside the off-peak window and verify both tariff selects. The watchdog changes only entities whose state differs from the expected tariff; this avoids unnecessary writes every five minutes. If selectors are unavailable on startup, a later periodic run can correct them. For a timetable with weekdays, seasons or public holidays, the template must be expanded carefully; this example is specific to one daily off-peak interval.

The selected price bucket is a state, not a record of the supplier’s authoritative intervals. If your meter only updates every ten minutes and reports a single cumulative increment spanning the 05:30 boundary, the system cannot always know exactly how much of the reported increment occurred before and after 05:30. For higher accuracy, obtain finer-grained interval readings or supplier settlement data. No amount of automation YAML can infer the true within-interval load shape from one coarse increment.

Check dates, weekday rules and daylight-saving transitions

Most time-based Home Assistant triggers interpret the configured local time using the Home Assistant instance’s timezone. Check Settings → System → Home information → Time zone before commissioning. A timezone mismatch of one hour shifts the entire tariff allocation, regardless of how accurately the energy meter AliExpress price measures consumption. Suppliers may define charge windows using the local civil clock or a different formal settlement convention, so read the tariff definition before translating it into Home Assistant triggers.

Timing condition	What happens	Test or mitigation
Home Assistant timezone wrong	Triggers shifted relative to contract	Verify region and timezone setting
Server stopped during tariff switch	Previous tariff may remain active	Startup and periodic selection reconciliation
Spring-forward DST transition	Some civil times do not occur	Choose contract-authoritative boundary treatment
Autumn-back DST transition	Some civil times repeat	Check supplier interpretation and stored UTC interval data
Weekday-only rate	Simple daily trigger misclassifies weekends	Add weekday-aware rule and Monday recovery
Overnight tariff crossing midnight	Peak/offpeak arithmetic spans calendar days	Make end boundary explicit
Sensor updates slowly	Increment can straddle tariff boundary	Use faster/billing-aligned data or qualify accuracy
Contract renews	Automation remains on obsolete times	Calendar reminder plus documented change process

An especially misleading test is checking only that the current tariff selector looks right at noon. That proves nothing about whether the 00:30 and 05:30 transitions ran, or whether repeated local times were handled appropriately on the daylight-saving change. Save a timestamped series of selector states for commissioning. The official automation troubleshooting guide describes local-time and trigger configuration issues; compare the Home Assistant clock with the supplier’s contract, not with an assumed UK or continental timezone.

For a UK tariff that follows GMT year-round, civil-time schedules defined as Europe/London are not necessarily equivalent during British Summer Time. Some retail contracts instead explicitly follow clock changes. Similarly, the word “night” does not imply that a seven-hour discount is literally 00:00–07:00 every day. Model the written clock rule precisely and test both transition dates before claiming invoice-grade tariff separation.

Cost calculation: kWh buckets multiplied by their correct prices

A Utility Meter registers energy, not money. To estimate the variable electricity charge, multiply each tariff’s consumed kWh by its corresponding money-per-kWh rate, then sum. Keep import rates in one chosen unit, for example pounds per kWh. If a bill quotes pence per kWh, divide the pence value by 100 first. A value of 28 in a GBP/kWh calculation instead of 0.28 introduces a hundredfold error.

Our example rates are £0.28/kWh peak and £0.12/kWh off-peak, plus a hypothetical £0.55/day standing charge. They are illustrations only, not current market quotations. For a sample day with 9 kWh peak and 7 kWh off-peak, the variable cost is 9 × £0.28 + 7 × £0.12 = £3.36, and with one £0.55 standing charge the estimated daily total is £3.91. Be careful with tax: if the illustrative rates already include VAT, do not add VAT to them again.

Cost component	Example calculation	Result	Interpretation
Peak energy	9 kWh × £0.28/kWh	£2.52	Purchased electricity during peak
Off-peak energy	7 kWh × £0.12/kWh	£0.84	Purchased electricity during cheap period
Variable total	£2.52 + £0.84	£3.36	Before other charges
Standing charge	1 day × £0.55/day	£0.55	Not a reason to shift an EV schedule
Estimated total	£3.36 + £0.55	£3.91	Invoice may have other components
All 16 kWh at peak, comparison	16 × £0.28	£4.48	Variable-only reference case
Variable saving versus all peak	£4.48 − £3.36	£1.12	Illustrative shift benefit

This example is deliberately straightforward. Many bills involve minimum standing fees, debt repayment, capacity charges, meter-specific fees, discounts, taxes, solar export credits and rounding conventions. Do not hide such items inside the off-peak or peak energy rate if you later use that rate to decide whether moving an extra kilowatt-hour is economical. Keep billing estimates and marginal scheduling prices conceptually separate.

Create a basic daily cost sensor

A template sensor can calculate a total daily energy cost from the two accumulated counters. The following example intentionally excludes the standing charge so that it exposes a clearly named variable energy cost. The template will only have the right result if the counters exist and the example entity IDs match. It reports unavailable if either counter is unknown or unavailable, rather than quietly turning missing data into zero.

template:
  - sensor:
      - name: Grid Import Daily Variable Cost
        unique_id: grid_import_daily_variable_cost
        unit_of_measurement: GBP
        state: >-
          {% set peak = states('sensor.grid_import_daily_peak') %}
          {% set offpeak = states('sensor.grid_import_daily_offpeak') %}
          {% if is_number(peak) and is_number(offpeak) %}
            {{ ((peak | float) * 0.28 +
                (offpeak | float) * 0.12) | round(2) }}
          {% else %}
            {{ 'unavailable' }}
          {% endif %}

Use GBP as the currency unit for this illustration, not kWh or W. Replace the constants when your supplier revises the contract; for a tariff that changes in mid-month, static rate constants and historical monthly energy buckets cannot by themselves reproduce the whole invoice. You would need sub-period energy totals or time-aligned interval accounting for the dates before and after the price change. For euro contracts substitute the correct units and contract prices, and check what the local integration expects for currency entities.

This template gives a continuously updated estimate for the current day. When the daily utility meters reset at midnight, the value resets too. If you require a historical daily cost record, rely on Recorder/statistics appropriate to the entity or store the completed daily bill estimate in a dedicated, properly managed historical system. Do not try to reconstruct missing historic tariff assignment merely by multiplying the day’s combined imported kWh by whichever rate is active now.

Monthly estimates and a standing-charge calculation

Monthly peak and off-peak Utility Meter sensors can be calculated with the same formula, but the fixed charge needs a different time basis. For example, a constant daily charge paid for thirty chargeable days is 30 × £0.55 = £16.50, irrespective of whether those days were sunny or whether Home Assistant happened to be offline. If the monthly counter resets on the first day and the supplier bills from the tenth to the ninth, these periods are misaligned. Configure a matching billing cycle or reconcile your calendar-month analysis to the supplier statement manually.

You can maintain an input_number or template constant for each tariff price and update the values through the UI, but that does not automatically preserve historic price changes. The requirement becomes more complex for suppliers that alter prices seasonally or provide multiple mid-month discounts. The safe default is to treat daily cost as a current-tariff estimate, then perform billing reconstruction from timestamped readings where the contract changes during a cycle.

Monthly invoice component	Required source	Potential mismatch
Peak imported kWh	Monthly peak Utility Meter counter	Wrong boundary or meter reset
Off-peak imported kWh	Monthly off-peak Utility Meter counter	Missed selector transition
Peak energy charge	Peak kWh × applicable signed rate	Rate changed during month
Off-peak energy charge	Off-peak kWh × applicable signed rate	VAT or unit conversion
Daily standing fee	Contract rate × billable days	Not the same as kWh charge
Export credit	Separate grid-export register and export rate	Import/export netting incorrectly
Fixed discounts and levies	Supplier terms	Omitted invoice lines
Bill period and timezone	Supplier meter read dates	Calendar month differs from contract

An additional subtlety: do not use the monthly totals from a utility meter designed for net energy if your utility company separately bills imported kWh and credits exported kWh. A system that imports 400 kWh and exports 150 kWh has two transactions, not an arbitrary single 250 kWh purchase. See our double-counting guide for PV and home-battery boundaries.

Worked example: calculate the actual value of shifting a load

Suppose an EV needs 12 kWh delivered to its battery before a morning commute. The household can charge at peak rate £0.28/kWh or off-peak £0.12/kWh. The basic electricity price difference is £0.16 per purchased kWh. However, the vehicle may need roughly 13 kWh from the AC grid to deliver 12 kWh into the battery, depending on charging losses and conditions. With 13 purchased kWh, shifting the charge from peak to off-peak saves an illustrative 13 × £0.16 = £2.08. It does not matter for that comparison whether the standing charge is £0.55/day, because the charge is normally payable on both schedules.

Now add household competition for the low-cost period. A water heater, another EV and background loads may already be using much of the available electrical supply. Tariff tracking can show which hours are cheap, but it does not enforce supply headroom, fuse limits, charger minimum currents or cylinder thermostat protections. These remain the responsibility of a correctly specified charger or heater controller. A general-purpose Home Assistant automation must not replace certified dynamic load management or overtemperature safeguards.

Scenario	Energy moved	Unit price difference	Gross variable saving	Caveat
EV AC charge shifted	13 kWh	£0.16/kWh	£2.08	Check departure, conversion losses, charger limits
Immersion heating shifted	4 kWh	£0.16/kWh	£0.64	Check thermostat, hygiene and standby losses
Dishwasher with supported delay timer	1.2 kWh	£0.16/kWh	£0.19	Only if safe to delay and manufacturer-supported
Heat pump space heating	6 kWh electrical	£0.16/kWh	£0.96 theoretical	COP and heat losses may change after preheating
Small standby load	0.1 kWh	£0.16/kWh	£0.02	Potentially not worth control complexity

These figures are upper-level illustrations for unchanged energy purchases, not promised savings. Real savings are the difference in total consumption and total cost between the two schedules, with any additional losses and different efficiencies included. Shifting a heat-pump cycle can worsen performance if hotter water is demanded; using a battery to arbitrage rates can lose energy to round-trip inefficiency. Home Assistant’s price-aware scheduling is addressed in our EV tariff scheduling guide and solar surplus control guide.

Day-by-day commissioning: validate the counters before controlling loads

Commission the meter and tariff selector as an accounting system first. During a low-risk test day, record the grid meter cumulative import reading at 00:25, 00:35, 05:25 and 05:35. Compare it with the two daily Utility Meter counters and the selector state. If a large measured load straddles the switch, an imperfect split can result from an energy sensor whose updates are not aligned to the tariff boundary; capture device timestamps or shorten the measurement interval if supported. Do not try to hide that error by recalibrating the displayed kWh arbitrarily.

Day 0: Record meter make, sensor source, cumulative kWh, timezone, actual tariff document and charge rates. Back up Home Assistant.
Day 1: Configure the daily Utility Meter and manually check peak/offpeak selection; no automated high-power loads yet.
Day 2: Enable both transition triggers, verify their traces and check that a load during each interval increments the correct counter.
Day 3: Add restart reconciliation, restart Home Assistant within a known tariff interval and verify selection.
Days 4–7: Compare source kWh increase with the sum of tariff-counter increases, allowing for normal cycle resets.
Days 8–14: Compare sampled tariff totals and calculated charges with the supplier’s interval information when available.
First full billing cycle: Check energy by tariff and invoice components, then sign off any remaining known difference.

A commissioning log should include Home Assistant version, the actual entity IDs, supplier contract reference, test timestamps and residual errors. That information makes troubleshooting far faster after an update or change of electricity supplier. If the system is used for reporting savings publicly, show the data completeness and assumptions, not only an attractive currency graph.

Daily reconciliation: why total source kWh must equal the tariff sums

During a complete measurement period with no lost updates and correct meter semantics, the increase in the underlying source import register should agree with the sum of energy allocated to peak and off-peak buckets, apart from rounding and initialisation effects. For a daily cycle this is easier to check after both the source and the helper have been operating for a full day. For a monthly counter you can compare the sum of the two tariff registers to the net source increase since that billing-cycle start. The reconciliation proves that energy was not simply lost or double-counted by the helpers; it does not prove that the energy was assigned to the correct tariff period.

Consider a source reading that rises from 18,230.0 kWh to 18,247.3 kWh in one day: purchased energy was 17.3 kWh. If peak records 11.8 kWh and off-peak 5.5 kWh, the two counters sum to 17.3 kWh and pass the total-energy check. But if the off-peak window is misconfigured by an hour, both totals may still sum correctly while the final bill is wrong. A stronger check also compares the per-tariff numbers with the utility’s own tariff registers or interval export.

Check	Expected result	Failure suggests
Total import source delta versus sum of tariffs	Approximately equal for complete period	Missing updates, wrong source semantics, startup/reset effect
Tariff select around each boundary	Correct selection at exact contractual time	Timezone, trigger, unavailable select
Physical utility tariff registers versus Home Assistant	Consistent within agreed tolerance	Tariff allocation wrong despite correct total
Peak/offpeak cost formula	Energy × corresponding price	Unit conversion or price error
Daily totals over a month versus monthly helper	Consistent with same cycles	Initialisation, missing days, billing period misalignment
Recorded tariff history during restart	Selector corrected after startup	Reconciliation logic not firing
Import and export registers kept separate	No inappropriate netting	Solar or battery boundary mistake

Always distinguish measurement precision from billing equivalence. A three-decimal-place sensor is not necessarily accurate to 1 Wh, and a low-cost CT may drift with load current or power factor. The correct reference is a stable utility meter or sufficiently reliable measurement standard. If the Home Assistant installation is just for household understanding and EV scheduling, agree an acceptable cost-estimate error instead of chasing false numerical precision.

Common failure: counter jumps, resets and missing readings

Most field errors begin in the underlying energy sensor. If a smart plug loses its accumulated register during firmware reset, a Utility Meter may interpret the next reading according to its periodically_resetting and net_consumption settings. The official integration documents both. Do not enable every “reset protection” switch indiscriminately: the right behaviour depends on whether the source genuinely restarts its counter, emits signed net values, or drops to an invalid state and later recovers.

Home Assistant Recorder and long-term statistics have their own retention and data-quality constraints. A current state may look fine even if an earlier day lacks accurate readings. Use History and Statistics views alongside the physical meter. If the supplier has a delayed interval API, expect late corrections rather than assuming every midnight aggregate is definitive. Some missing intervals cannot be repaired from a new current cumulative reading because the split between cheap and expensive periods is unknowable.

Symptom	Likely explanation	Recommended investigation
Off-peak always zero	No tariff switch, wrong entity ID or source not moving	Check select, automation trace and actual sensor names
Peak and off-peak both increase together	Duplicate meters or wrong interpretation of source	Check per-tariff entities and input sensors
Monthly lower than daily sum	First incomplete month, missed inputs, mismatch in cycles	Compare period start dates and recorder history
Off-peak appears expensive	Prices reversed or currency unit wrong	Check signed contract and money-per-kWh scale
Cost suddenly drops at midnight	Daily helper reset, template reads current cycle	Show prior-day total separately
Wrong tariff after restart	Missed exact boundary trigger	Enable state reconciliation automation
Very large spike after reconnect	Counter rollover, reset or statistics corruption	Inspect raw meter states before changing templates
Dashboard doubles grid imports	Both source and derived tariff sensors configured as imports	Use one consistent energy accounting basis
Clock-change anomaly	Ambiguous or missing local civil times	Compare source timestamps and supplier interval rules
Negative import reading	Net grid-power/energy fed into import-only calculation	Use cumulative import register instead

Where the user-facing chart shows zero cost during an outage, that is not evidence of free electricity. A missing price or energy sample should be treated as unknown, not silently converted to zero. If a template does not have both tariff counters, mark the result unavailable, which is why the YAML template earlier checks is_number. For actual control of loads, consider the supplier’s or charger’s built-in schedule when Home Assistant cannot reliably verify the rate or deadline.

Do you need a smart meter, a CT clamp or a dedicated gateway?

Utility Meter itself is software already available within Home Assistant. It does not require a specific branded “tariff meter” as long as a suitable cumulative energy source is available. That is a strong argument against buying duplicate hardware merely to obtain a peak/off-peak chart. First audit what the inverter, existing smart meter or DIN-rail energy meter already reports. The incremental budget may be zero if a stable import-energy entity is already exposed locally.

A direct supplier meter interface may provide official import registers and sometimes contract tariff periods, but cloud polling can be delayed or subject to authentication. A locally integrated energy meter can give faster data and offline reliability; however it adds installation costs, and it is unlikely to become the supplier’s legal settlement meter. A whole-home CT system may monitor several circuits but depends on correct CT ratios, placement and calibration. A plug-in electricity monitor is easier to install, yet it only measures the attached load and does not create whole-property billing totals.

Purchase option	When justified	Advantages	Limitations
Existing integrated smart-meter import sensor	Reliable cumulative grid kWh already present	No additional meter hardware	Supplier/cloud latency and permissions vary
DIN-rail meter with supported local interface	Need local billing-boundary monitoring	Stable, local, often detailed registers	Electrician, breaker panel space and cost
Whole-home CT monitor	Need import/export and circuit visibility	Often easier metering expansion	Phase mapping and non-billing-grade limitations
EV charger energy meter	Need charge-session analytics	Good for charging efficiency comparison	Not whole-property import
ESP32 plus approved measurement interface	Research and custom telemetry use	Flexible dashboards and protocols	Calibration, isolation and maintenance burden
Better Home Assistant host/storage	Existing device readings are good but logs unreliable	Improves recorder reliability and backup	Does not fix a wrong physical meter

For UK and EU shoppers, check regional conformity, phase count, meter interface, available Home Assistant integration, and whether the particular product is still supported by the manufacturer. A suitable hardware purchase is the one that supplies reliable physical kWh at the correct point; Utility Meter handles the allocation in software. Our home energy monitor comparison and DIN-rail meter guide cover hardware choices in more depth.

When a two-tariff Utility Meter is not enough

A peak/off-peak meter is ideal when the retail contract genuinely has a handful of recurring rate buckets and when your goal is accounting at those buckets. It is not a substitute for timestamped interval pricing. If an electricity supplier changes import prices every 15, 30 or 60 minutes, a two-bucket energy counter cannot reconstruct what each period cost. A dynamic-tariff customer should store a price series with start/end timestamps and compute cost against matching energy intervals. The utility meter can still show total imported kWh, but the money calculation needs different inputs.

Similarly, sophisticated export tariffs may pay different prices from the import tariff, and the billing periods might differ. Keep exports in their own measurement path. Households with solar panels, home batteries or vehicle-to-home systems should establish whether their tariff agreement pays on gross export, net import, or another defined quantity. Do not use a negative retail import price as an export credit unless the contract explicitly says that is how settlement works.

Requirement	Utility Meter tariffs	Separate interval-price model
Two fixed recurring rates	Strong fit	Usually unnecessary
Weekday/weekend three-rate plan	Possible with correct switching	Useful when contract logic becomes elaborate
Daily kWh by tariff	Strong fit	Can aggregate intervals to achieve same
15-minute variable retail rate	Poor fit if treated as two buckets	Required for accurate price × energy calculation
Forecast tomorrow’s cheapest charging windows	No forecast in Utility Meter	Needs forward prices and scheduling logic
PV export with separate rate	Use a separate export path	Needed if export price varies over time
Daily billing-cost estimate	Yes for stable fixed rates	Best for frequent rate changes
Grid protection and electrical load limiting	Not provided	Not provided: use approved device hardware

See our fixed, time-of-use and dynamic tariff sensor guide for the broader price-data architecture. This #070 tutorial assumes that the contract schedule is established, and it focuses on implementing and validating fixed tariff buckets. For tariff-driven home appliances, see the separate price-aware automation guide linked at the top.

Security, backups and maintenance

A tariff allocation system depends on accurate time, a trustworthy physical sensor, working integrations and intact database statistics. Use the Home Assistant backup mechanism and test that a recovery preserves automations and entity names. Keep device firmware current when security fixes apply, but review the integration’s breaking changes before upgrades. A firmware update that renames sensor.grid_import_total_kwh can break every cost calculation without producing an immediately obvious dashboard error.

Document the relevant assets: supplier tariff name and effective date, local timezone, physical meter ID, integrations, Home Assistant entity IDs, each utility meter reset cycle, the four selector/counter entity IDs, rates and tax assumptions, and a log of commissioning results. Review that record whenever you change provider, fit solar panels, add a home battery, or alter an EV schedule. Schedule a monthly 10-minute reconciliation using the actual supplier statement, rather than allowing a plausible graph to become a source of false confidence.

The software does not make the electrical installation safe. Do not replace certified EV load management, battery anti-islanding, cylinder thermostat and over-temperature protection, or boiler safeguards with an unverified generic Home Assistant schedule. If Home Assistant is used to coordinate loads, design the physical installation so that a controller reboot or erroneous tariff remains a scheduling inconvenience rather than a safety event.

A practical 14-day verification plan

Stage	Test	Pass condition
Day 1	Check import kWh source against meter	Stable, monotonic and correctly located
Day 2	Manually select each tariff	Correct counter starts accumulating new increments
Day 3	Observe 00:30 trigger	Off-peak select active at contractual start
Day 4	Observe 05:30 trigger	Peak select active at contractual end
Day 5	Restart during off-peak	Reconcile automation restores off-peak
Day 6	Temporarily disable source feed in test window	Unavailable handled; no fabricated zero cost
Day 7	Compare source delta with tariff sum	Energy totals reconcile within agreed tolerance
Day 8	Validate currency and pence conversion	Formula consistent with tariff paperwork
Day 9	Check standing charge separately	Fixed fee not accidentally applied per kWh
Day 10	Inspect recorder/history	No unexplained missing data or spikes
Day 11	Inspect timezone and DST assumptions	Matches contract and Home Assistant region
Day 12	Check PV import/export boundaries	Only purchased grid energy assigned tariffs
Day 13	Recalculate sample day by hand	Daily cost equals sum of tier products
Day 14	Review and save baseline	Configuration and residual uncertainty documented

A two-week exercise will not span a daylight-saving change or an entire monthly billing cycle, so those checks require later follow-up. If supplier interval reports are available, an independent comparison over several boundary periods is far more persuasive than a simple cumulative-total match. Once the accounting layer is validated, consider introducing noncritical load scheduling—but retain the equipment’s own protections and an explicit manual override.

Frequently asked questions

Does Utility Meter automatically detect my electricity supplier’s peak hours?

No. Tariff entries create selectable accounting buckets. An automation or external source must select the correct bucket according to your supplier’s contract. Unless another integration specifically supplies contract rules, Home Assistant cannot infer your rate windows from the tariff names.

Should I feed Utility Meter watts or kWh?

Use a suitable energy sensor in kWh or another supported energy unit, generally a cumulative grid-import register. An instantaneous power sensor in W or kW is not itself cumulative energy. If necessary, first integrate power into energy with a separately validated method.

Can I use both a daily and monthly Utility Meter?

Yes. Configure separate daily and monthly helpers from the same validated source. Both should have the same supported tariff tokens and should be changed together. The first current period may be incomplete after initial creation.

Why is my off-peak sensor zero?

Check whether the corresponding tariff selector has ever been set to offpeak, whether the source actually increased in that interval, whether the right entities were targeted and whether the helper existed before the interval began.

What happens when Home Assistant restarts during cheap hours?

The counters are persistent, but an exact boundary trigger may be missed during downtime. Add startup and periodic tariff reconciliation. Energy imported while measurements were unavailable may not be allocatable accurately to the missing period.

Can I just use the currently selected tariff rate to estimate today’s bill?

No. Multiply the peak kWh bucket by its peak rate and the off-peak kWh bucket by its own rate. Multiplying the entire day’s purchased energy by the currently selected price misprices the other period.

What if my supplier charges pence per kWh?

Convert to pounds per kWh when the output is GBP: 28 p/kWh is £0.28/kWh. Similarly, check EUR/MWh versus EUR/kWh and whether tax is already included.

Can the Energy dashboard use my two tariff counters?

Home Assistant’s Energy dashboard generally works from appropriate consumption and return-to-grid energy statistics. Avoid configuring both the original import source and derived tariff counters as independent purchased-energy connections, which could double count. You can display tariff counters and calculated costs elsewhere.

Is the monthly utility meter identical to my supplier invoice?

Not automatically. Supplier billing periods can differ from calendar months; a tariff may have standing charges, taxes, export credits, manual adjustments and meter settlement corrections. Treat Home Assistant values as estimates until reconciled.

What changes on the daylight-saving clock change?

Some local clock times are missing or repeated. The right interpretation depends on the supplier’s published schedule, Home Assistant timezone and timestamped energy data. Compare the supplier’s authoritative period rules rather than assuming every local day has 24 hours.

Can I switch tariff buckets on a weekday schedule?

Yes, but you need a schedule that correctly handles weekends, holiday rules and overnight transitions. Simple daily examples cannot be copied unmodified to a weekday-only or seasonal contract.

Do I need a new smart meter for this?

Not necessarily. If you already have a reliable cumulative grid-import energy entity, Utility Meter is software-only. Buy new metering hardware only if the current source is inaccurate, unavailable or measured at the wrong boundary.

Does this automation control my EV charger or hot-water heater?

No. It only allocates measured electricity to tariff counters. Load scheduling is a separate control task requiring supported device interfaces, departure or hygiene deadlines, manual override and independent electrical safeguards.

Should I use this method for a dynamic 15-minute electricity tariff?

Not as a complete billing calculation. A 15-minute tariff needs time-aligned per-interval prices and energy readings; a two-rate bucket loses the information needed to allocate each changing rate.

Why do my daily cost totals drop to zero at midnight?

A daily Utility Meter resets on its configured cycle. The derived daily cost therefore resets. Preserve completed periods through recorder/history or a dedicated billing log if long-term daily totals are required.

Can I recover past off-peak usage if my meter was offline?

Only if an independent authoritative interval data source preserves the timing of past consumption. A later cumulative total establishes energy used since the previous reading but not reliably the split before and after the tariff boundary.

Official documentation and further reading

Editorial note: All rates, example tariff hours, kWh readings, equipment purchase choices and savings estimates in this article are illustrative. The definitive inputs are your retailer’s contract, the physical metering arrangement and the current Home Assistant documentation. This guide does not replace electrical installation instructions or an approved device safety controller.