I note that is reported as a Frontend issue. There are elements that need a backend change (as far as I can see the costs is calculated in the back end Energy integration) , so wonder if a core feature request would help.
Perhaps I cannot make the difference
Owner of front end should transfer to core
Phil
My solution using sensors (input numbers) and utility meters here:
Energy - How to account for daily standing charge? - Configuration - Home Assistant Community (home-assistant.io)
1 Like
Also voted for this feature.
I’m in the UK and we have a daily standing charge on the utilities.
Hopefully it will get implemented soon.
2 Likes
You could also try my fix here. It’s been working well for me for over a month now and is very easy to setup.
I did this but I wouldn’t call it easy to set up, not at least compared to how easy the energy dashboard is to set up. Adding in the time it took to find a solution that would work, and then creating the templates and automation, it was probably about 30 minutes. IMO that’s way too long/too much effort when you should just be able to enter the value in a box and press okay in <1 second…
1 Like
@j_ay - as I said in my comments. It’s a kludge to TRY to get something to work until there is a proper solution. Also are you sure you are looking at MY solution ? There’s no templates or automation in my solution.?? Just the creation of one sensor? And you do only enter the value in a box and press OK. So I’m confused by your comments.
Repost of my solution:
I basically created a sensor that uses 0.001kW per hour. Then I take the daily supply charge, multiply by 1000 and divide by 24. This give me an hourly static price I can use to multiply by the sensor to get an hourly supply charge.
So in detail the sensor looks like this.
- name: "Supply Charge"
unit_of_measurement: "kWh"
device_class: energy
state_class: total_increasing
state: >-
{{ (((as_timestamp(states('sensor.date_time_iso')) / 3600)-454585) | int) / 1000}}
attributes:
last_reset: '1970-01-01T00:00:00+00:00'
The formula for the sensor is basically the date & time in hours
(as_timestamp(states('sensor.date_time_iso')) / 3600)
minus an offset of hours since 1 Jan 1970 00:00.(Unix Epoch) In my case this was 454585 but it will be different depending on the time you start the sensor.
I take the integer and divide this by 1000 to get the smallest possible unit (1Wh). So this sensor now increments by 1Wh every hour forever. This will get added to your hourly grid consumption but this value should be negligible and well within the margin of error of most measuring devices.
Once I created the sensor I added it to the energy config screen under Grid Consumption as below
Note: The static price used is 1000 times the actual price for 1 hour supply.
In my case I pay 105.1400 cents per day supply charge, so when I adjust this to an hourly static price I get 1.051400 *1000/24 = 43.81 (you can only use 2 decimal places in the config price)
It’s not perfect but I hope it works for others.
PS. You could easily use this same approach for a “daily” sensor but I wanted to spread the cost across hours in the day so I can compare it to another system I have that does something similar.
2 Likes
I use the following template to approximate my daily electricity cost including the monthly standing charge (I say approximate as I have assumed there are 30 days in a month and figured that this would be close enough):
The unit rate per kWh and standing charge in GBP/month are stored in input_numbers entities.
energy_cost_today:
friendly_name: Energy Cost Today
unit_of_measurement: £
value_template: "{{ (states('sensor.energy_usage_day_std') | float * states('input_number.std_tariff') | float / 100.0) | float + ((states('input_number.standing_charge') | float / 30.0) | float ) | round(2) }}"
Thsi might be a useful workaround for some people.
2 Likes
Oh I wasn’t talking about your specific instructions, I did something very similar though and did find it quite awkward (your’s doesn’t look much cleaner!) ‘Kludge’ or no, my point was that it’s silly that this isn’t a feature yet.
1 Like
+1 for this…
In the UK, my utility provider is similar, but has one rate for the first 2kWh used, then switches to another tariff for the remaining.
I’ve had to create some Helpers and automations to switch the sensor I’m using for the cost based off this…
So the cut off is 2kWh for the first Tariff
Then switches to Tariff two if over the cut off
1 Like
Plus 1 for daily standing charge option- used by energy companies in Ireland.
That looks great. How well does it feed into the energy dashboard?
Feeds in perfectly. I use the daily cost and usage which isn’t to far out to what my provider is showing.
1 Like
My energy dashboard (this is based on @sean.mcgee’s solution, but modified to be 0.001kWh per daily charge instead of 1kWh… so it doesn’t skew the charts):
how you did it, we have the same system in my country and I need to know how for my project.
As above.
I added two helpers to set both tariffs.
Another helper to set the “first target value” ( for me, its the first 2kwh at high price, then remaining at low price)
I then have a template to switch over to tariff two once the 2kwh has been reached
can you explain to me step by step, which type of helper u are used and what you did with automation because just I used home assistant from week ago
Hi, apologies for the late reply but I’ve done a step by step ‘how-to’ - HERE
Please let me know your thoughts… Hope it helps!
Unfortunately, i am getting an error
2022-05-08 19:37:00 WARNING (MainThread) [homeassistant.helpers.template] Template warning: 'as_timestamp' got invalid input 'unknown' when rendering template '{{ (((as_timestamp(states
('sensor.date_time_iso')) / 3600)-1652016564) | int) / 1000}}' but no default was specified. Currently 'as_timestamp' will return 'None', however this template will fail to render in Ho
me Assistant core 2022.6
My template is:
- name: "Fixed Charges"
unit_of_measurement: "kWh"
device_class: energy
state_class: total_increasing
state: >-
{{ (((as_timestamp(states('sensor.date_time_iso')) / 3600)-1652016564) | int) / 1000}}
attributes:
last_reset: '1970-01-01T00:00:00+00:00'