Sorry for triple post, have been working on my energy views
This is a great idea - I’ve taken this approach and applied it to my monthly billing. As you’ll see, I’ve done this in a similar way to you but laid it out in a way that I found easier to work with.
Have also after scratching my head for a while, worked out how to get the last billing period calculating too:
- name: Monthly Energy Total Cost #calculating energy cost for this billing period.
device_class: monetary
state_class: measurement
unit_of_measurement: AUD
state: >
{% set peak = states('sensor.monthly_energy_peak') | float %}
{% set p_tariff = states('input_text.peak') | float %}
{% set shoulder = states('sensor.monthly_energy_shoulder') | float %}
{% set s_tariff = states('input_text.shoulder') | float %}
{% set offpeak = states('sensor.monthly_energy_offpeak') | float %}
{% set o_tariff = states('input_text.offpeak') | float %}
{% set buyback = states('sensor.monthly_energy_export_buyback') | float %}
{% set b_tariff = states('input_text.feedin') | float %}
{% set daily = states('input_text.daily') | float %}
{% set reset = state_attr('sensor.monthly_energy_offpeak','last_reset') |as_datetime %}
{% set days_in = ((now() - reset)).days %}
{{ (peak * p_tariff + shoulder * s_tariff + offpeak * o_tariff + buyback * b_tariff + daily * days_in) | round(2) }}
- name: Last Month Energy Total Cost #calculating energy cost for previous billing period
device_class: monetary
unit_of_measurement: AUD
state: >
{% set peak_last = state_attr('sensor.monthly_energy_peak','last_period') | float %}
{% set p_tariff = states('input_text.peak') | float %}
{% set shoulder_last = state_attr('sensor.monthly_energy_shoulder','last_period') | float %}
{% set s_tariff = states('input_text.shoulder') | float %}
{% set offpeak_last = state_attr('sensor.monthly_energy_offpeak','last_period') | float %}
{% set o_tariff = states('input_text.offpeak') | float %}
{% set buyback_last = state_attr('sensor.monthly_energy_export_buyback','last_period') | float %}
{% set b_tariff = states('input_text.feedin') | float %}
{% set daily = states('input_text.daily') | float %}
{% set last_month = now().month - 1 if now().month - 1 >= 1 else 12 %}
{% set last_year = now().year - 1 if now().month == 1 else now().year %}
{% set reset = state_attr('sensor.monthly_energy_offpeak','last_reset') |as_datetime %}
{% set last_reset = reset.replace(year=last_year, month=last_month) %}
{% set last_days = (reset - last_reset).days %}
{{ (peak_last * p_tariff + shoulder_last * s_tariff + offpeak_last * o_tariff + buyback_last * b_tariff + daily * last_days) | round(2) }}
Thanks @Muppetteer
This code is really great.
I will soon be replacing my automations with your code.
Currently running them both in parallel for a few days to check the code works.
I see there is a breaking change from HA 2022.08 with the metering tariff command/service. I tried to change from the previous “service utility_meter.select_tariff” but couldn’t get it to work properly.
My code from your earlier posts is like this j
utility_meter:
daily_energy:
source: sensor.grid_import_energy
name: Daily Import Meter
cycle: daily
tariffs:
- peak
- go
daily_energy_export:
source: sensor.grid_export_energy
name: Daily Export Meter
cycle: daily
tariffs:
- export
daily_energy_gas:
# source: sensor.gas_consumption_today
source: sensor.grid_gas_power
name: Daily Gas Meter
cycle: daily
tariffs:
- standard
daily_garage_solar:
source: sensor.garage_solar_production
name: Garage Solar Meter
cycle: daily
and for one of the automatons the automation like this:
alias: Switch to the STD Tariff for metering functionality
description: >-
This automation only changes the metering tariffs that I set up in the Octopus
folder
trigger:
- platform: time
at: "04:30:00"
condition:
- condition: state
entity_id: input_boolean.go_tariff
state: "on"
action:
- service: utility_meter.select_tariff
data:
tariff: peak
target:
entity_id: utility_meter.daily_energy
mode: single
I did change just the services line before, but then my meters didn’t reset. I need some time to look in to it further using the information that you linked me to.
I made the changes in the automation to switch to each tariff (now called “option”) and today they seemed to switch over ok, but for the actual meters, do I need to change the “tariff” to “option” as well? The strange thing today is that my peak meter recorded energy usage, but my cheap rate “go” meter did not record any energy used even though there was usage during that tariff time slot…
All utility meter does is allow you to have an odometer of how much energy was used when the state of the utility meter was set to that tariff at that time.
I have an automation that uses the select :: option to set the tariffs on a utility meter. The automation Trace shows successful execution but the tariffs are not updated.
Do you have any ideas about what the problem can be?
This kind of stuff is exactly what I’ve been looking for as I work through my plan for a solar setup!
My energy plan gives free power between 9pm and Midnight so will be looking to see if the Paladin can take advantage of that.
I’m a little surprised the Paladin is not a bit “smarter” in terms of automation and control to trigger something like a “top up” using an external source like Home Assistant…
From what I understand, the paladin started life as an off grid device.
Paladin began it’s life in 2011 when exporting to the grid was expensive and time consuming to get approval. What started as an off-grid device migrated to on-grid PV when this became easier and export feed in tariffs were $0.28/unit. With the slashing of the export buy price, we went into full manufacture of Paladin.
From the posts on the Facebook group, it seems Ken is very reluctant to introduce any sort of wireless connectivity to the Arduino based appliance due to various security and button/interface concerns.
At this point, it’s a box that measures if excess solar power is being pushed to the grid and redirects that power to the hot water system if the temp sensor is below 73 degrees. That’s it’s sole function really.
As I said, I’ve made mine smart by adding a sonoff wireless relay to give me some control over the appliance and I’m really happy with it now I’ve done that.
@del13r Thanks for this and your other post on the Energy dashboard - it has helped a lot.
However I have run into a wall when it comes to reporting the costs/income. I have followed your examples (up to a point) but while I get the data reported, I am not seeing any statistics history.
For example, where you set up template sensors to identify your time-of-day tariffs, I have a single tariff so tried a shortcut - and maybe that’s where I have come undone in not being able to see the $ history. Where you set up the various tariffs I just used one:
Initially I set up “Number” Helpers that allowed me to set the import/export tariffs in the dashboard without changing the configuration file.
The variation using the number helper gave an entity called: “input_number.grid_feed_in_tariff”. (This replaced the “sensor.grid_tariff_import_price”) That gave the same result - a calculation right at this point in time, but no history.
The individual components each have a history but when the tariff is multiplied by the sensor measuring the energy I get zip.
Given that other similarly named sensors are showing up with history, I am scratching my head. The only thing I can think of is it baulking at a sensor that is generated by a sensor that is generated by another sensor.
I also set up a sensor (similar to your total cost) to give me a continuing energy cost/income:
This gives me a number but no history. Instead of putting all elements in again I tried to use the two sensors I created in the previous post (Grid Solar FIT V2 Today & Grid Import Cost V2 Today) along with the network supply charge and it would not even compute that.
I have copied a few other people’s formats and it has me stumped.
Yes my history is set up with nothing excluded (or “included”).
It is working for every other sensor I expect to work, so I am now going through and copying your config almost line for line - just changing some sensor names to keep it separate from my usual set-up.
