Checklist
Is your feature request related to a problem? Please describe.
No, not directly. This is not related to a bug or malfunction that I am aware of. It is a feature request based on my use case.
Describe the solution you'd like
Feature proposal: Annual base charge for calculated cost sensors
First of all
Thank you for developing and maintaining Utility Meter Next Gen. I really like this integration. For my electricity cost tracking in Home Assistant, it is currently the only solution I have found that properly fits what I need.
I searched for quite a while before finding this integration, and overall I am very happy with it. This is not meant as criticism, but as a small feature suggestion based on my own use case.
What I wanted to achieve
I use Utility Meter Next Gen to calculate my electricity costs. The variable energy price per kWh is already handled very well. What I was missing for a complete cost overview was the fixed annual base charge from my electricity tariff.
A simplified example would be:
- Energy price:
0.30 €/kWh
- Annual base charge:
130 €/year
What I wanted was for this base charge to be included in every calculated cost sensor I choose to use. So not only for one specific period, but also for hourly, daily, monthly, yearly or any other available reset cycle.
Why I looked into this
I first discussed the idea with AI to better understand how this could be handled. From what I understood, the existing calibration approach can be applied to a selected period, for example only to the daily meter. For my use case, I wanted the fixed annual base charge to be distributed automatically across all selected periods.
So instead of building several helper constructions or manually combining values in my dashboards, I wanted the existing calculated sensors themselves to represent the real cost:
Electricity cost = consumption cost + proportional base charge
That way, my dashboards and ApexCharts can continue using the existing sensors. I do not need a second structure, additional template sensors or extra calculations in the dashboard.
Calculation idea
The user enters the annual base charge once, for example 130. The integration then distributes this value automatically depending on the selected reset cycle.
Examples:
Hourly = annual base charge / 365 / 24
Daily = annual base charge / 365
Weekly = annual base charge / 52
Monthly = annual base charge / 12
Bi Monthly = annual base charge / 6
Quarterly = annual base charge / 4
Half Yearly = annual base charge / 2
Yearly = annual base charge
With 130 €/year, this would roughly be:
Hourly = approx. 0.015 €
Daily = approx. 0.36 €
Monthly = approx. 10.83 €
Yearly = 130 €
The base charge is not added as one full amount at the beginning of the period. Instead, it is accumulated proportionally during the current period. For example, an hourly sensor reaches the full hourly share at the end of the hour, a daily sensor reaches the full daily share at the end of the day, and so on.
The simplified formula is:
calculated value = consumption_kWh × energy_price + proportional base charge
Behaviour when the base charge changes
If the annual base charge is changed later, the existing history should not be recalculated retroactively. The new value should only apply from that point forward:
- old base charge until the change
- new base charge after the change
- existing history remains unchanged
This is the behaviour I would expect for tariff or price changes in general.
What I added technically
I implemented this as an optional field:
If the value is 0 or empty, the integration behaves as before. So this should remain backwards compatible.
The main areas I changed were:
-
const.py
Added constants for the new option and attributes.
-
schemas.py
Added a number field for the annual base charge.
-
config_flow.py
Added handling and storage for the new option value.
-
__init__.py
Added the value to the config/options structure and migration with default 0 for existing entries.
-
sensor.py
Added the actual calculation logic: proportional accumulation, reset handling, restore-state handling and attributes for checking the values.
-
strings.json, translations/en.json, translations/de.json
Added UI text for the new field.
For easier review, I marked the relevant changes directly inside the attached code files. The added or modified sections are surrounded by clear markers like this:
#################### ANNUAL BASE PRICE PATCH START ####################
...
##################### ANNUAL BASE PRICE PATCH END #####################
These markers are only meant to make the changes easier to find and review in the shared files. They are not part of the intended final code style if this feature were integrated upstream.
Tested in my Home Assistant setup
I tested the change in my own Home Assistant system with real sensor values. In Developer Tools, the new attributes are visible, for example:
annual_calc_base_price: 129.6
annual_calculation_base_price: 129.6
annual_calculation_base_price_last_update: ...
current_period_calculated_value: ...
I manually checked hourly and daily values against the expected calculations, and they matched the displayed sensor values. Small differences can occur due to rounding, still-running periods or slightly different update times.
Why I would like to suggest this upstream
At the moment, I have to manually re-apply or merge this change after integration updates. That works, but it is quite a bit of maintenance and could lead to problems after future updates.
So I would like to share this as a possible feature suggestion. Maybe my approach can help to integrate this type of annual base charge calculation directly and cleanly for all selected periods.
From my point of view, an optional annual base charge in the calculated cost sensors would be a useful addition for users who want to show their real electricity costs including fixed base fees per hour, day, month and year.
I can also add a screenshot from my setup to show why I needed this and how it looks in practice.
Just as a note: I am not a programmer myself. I worked out the idea, the calculation logic and the example implementation with the help of ChatGPT/GPT-5.5 and Codex, and tested it in my own Home Assistant setup.
I understand that this does not automatically mean the code is the best or cleanest way to integrate this officially. So I do not want to present it as a finished perfect solution, but rather as a working approach, a small idea, or a possible starting point.
You obviously know much better how something like this should be integrated properly into the project. My main goal was to explain my use case clearly and show that the calculation itself works in practice.
Describe alternatives you've considered
I considered using template sensors or doing the calculation directly in my dashboard/ApexCharts, but that would require additional helper structures and repeated manual calculations.
I also looked at the existing calibration option, but from what I understood it is mainly useful for applying a value to one selected period. My goal was to have one annual base charge automatically distributed across every calculated cost sensor/reset cycle I choose to use, such as hourly, daily, monthly and yearly.
That is why I tried to add this directly to the existing calculated sensor logic instead.
Additional context
init.py.txt
config_flow.py.txt
const.py.txt
manifest.json.txt
schemas.py.txt
sensor.py.txt
strings.json.txt
translations__de.json.txt
translations__en.json.txt
Checklist
Is your feature request related to a problem? Please describe.
No, not directly. This is not related to a bug or malfunction that I am aware of. It is a feature request based on my use case.
Describe the solution you'd like
Feature proposal: Annual base charge for calculated cost sensors
First of all
Thank you for developing and maintaining Utility Meter Next Gen. I really like this integration. For my electricity cost tracking in Home Assistant, it is currently the only solution I have found that properly fits what I need.
I searched for quite a while before finding this integration, and overall I am very happy with it. This is not meant as criticism, but as a small feature suggestion based on my own use case.
What I wanted to achieve
I use Utility Meter Next Gen to calculate my electricity costs. The variable energy price per kWh is already handled very well. What I was missing for a complete cost overview was the fixed annual base charge from my electricity tariff.
A simplified example would be:
0.30 €/kWh130 €/yearWhat I wanted was for this base charge to be included in every calculated cost sensor I choose to use. So not only for one specific period, but also for hourly, daily, monthly, yearly or any other available reset cycle.
Why I looked into this
I first discussed the idea with AI to better understand how this could be handled. From what I understood, the existing calibration approach can be applied to a selected period, for example only to the daily meter. For my use case, I wanted the fixed annual base charge to be distributed automatically across all selected periods.
So instead of building several helper constructions or manually combining values in my dashboards, I wanted the existing
calculatedsensors themselves to represent the real cost:That way, my dashboards and ApexCharts can continue using the existing sensors. I do not need a second structure, additional template sensors or extra calculations in the dashboard.
Calculation idea
The user enters the annual base charge once, for example
130. The integration then distributes this value automatically depending on the selected reset cycle.Examples:
With
130 €/year, this would roughly be:The base charge is not added as one full amount at the beginning of the period. Instead, it is accumulated proportionally during the current period. For example, an hourly sensor reaches the full hourly share at the end of the hour, a daily sensor reaches the full daily share at the end of the day, and so on.
The simplified formula is:
Behaviour when the base charge changes
If the annual base charge is changed later, the existing history should not be recalculated retroactively. The new value should only apply from that point forward:
This is the behaviour I would expect for tariff or price changes in general.
What I added technically
I implemented this as an optional field:
If the value is
0or empty, the integration behaves as before. So this should remain backwards compatible.The main areas I changed were:
const.pyAdded constants for the new option and attributes.
schemas.pyAdded a number field for the annual base charge.
config_flow.pyAdded handling and storage for the new option value.
__init__.pyAdded the value to the config/options structure and migration with default
0for existing entries.sensor.pyAdded the actual calculation logic: proportional accumulation, reset handling, restore-state handling and attributes for checking the values.
strings.json,translations/en.json,translations/de.jsonAdded UI text for the new field.
For easier review, I marked the relevant changes directly inside the attached code files. The added or modified sections are surrounded by clear markers like this:
These markers are only meant to make the changes easier to find and review in the shared files. They are not part of the intended final code style if this feature were integrated upstream.
Tested in my Home Assistant setup
I tested the change in my own Home Assistant system with real sensor values. In Developer Tools, the new attributes are visible, for example:
I manually checked hourly and daily values against the expected calculations, and they matched the displayed sensor values. Small differences can occur due to rounding, still-running periods or slightly different update times.
Why I would like to suggest this upstream
At the moment, I have to manually re-apply or merge this change after integration updates. That works, but it is quite a bit of maintenance and could lead to problems after future updates.
So I would like to share this as a possible feature suggestion. Maybe my approach can help to integrate this type of annual base charge calculation directly and cleanly for all selected periods.
From my point of view, an optional annual base charge in the calculated cost sensors would be a useful addition for users who want to show their real electricity costs including fixed base fees per hour, day, month and year.
I can also add a screenshot from my setup to show why I needed this and how it looks in practice.
Just as a note: I am not a programmer myself. I worked out the idea, the calculation logic and the example implementation with the help of ChatGPT/GPT-5.5 and Codex, and tested it in my own Home Assistant setup.
I understand that this does not automatically mean the code is the best or cleanest way to integrate this officially. So I do not want to present it as a finished perfect solution, but rather as a working approach, a small idea, or a possible starting point.
You obviously know much better how something like this should be integrated properly into the project. My main goal was to explain my use case clearly and show that the calculation itself works in practice.
Describe alternatives you've considered
I considered using template sensors or doing the calculation directly in my dashboard/ApexCharts, but that would require additional helper structures and repeated manual calculations.
I also looked at the existing calibration option, but from what I understood it is mainly useful for applying a value to one selected period. My goal was to have one annual base charge automatically distributed across every calculated cost sensor/reset cycle I choose to use, such as hourly, daily, monthly and yearly.
That is why I tried to add this directly to the existing calculated sensor logic instead.
Additional context
init.py.txt
config_flow.py.txt
const.py.txt
manifest.json.txt
schemas.py.txt
sensor.py.txt
strings.json.txt
translations__de.json.txt
translations__en.json.txt