In terms of payback I have been calculating the savings from solar, my case is complicated as my buy/ sell prices change every 30 minutes.
Solar Savings =
energy self consumption * buy price +
energy export * sell price
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.
For those interested in specifically what holidays apply to what country/province, go to
https://github.com/dr-prodigy/python-holidays/tree/master/holidays/countries
Hi @del13r
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
Now I’m seeing this in HA notifications:
Any guidance on how to change that service line and the utility meter code to work again?
As always thanx very much
See for the solution plus example (choose select.select_option service instead of the utility_meter.select_tariff service.) the following post.
1 Like
Thank you @Janneman
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.
Hi,
Check these examples if you are stuck.
I had to change to yaml view, by pressing the 3 dots on the right, so I could fit it all on the screen.
Thanx @del13r
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…
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
Hi,
Your Utility meter uses
as a source.
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.
Here is my timeline for my utility meter
Maybe check yours to see if your automations are working correctly
You can actually see the graph for each tariff to verify its working as well.
1 Like
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?
For anyone struggling with the updates to utility meter, please view the example taken directly from
https://www.home-assistant.io/integrations/utility_meter/#advanced-configuration
2 Likes
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.
1 Like
On the paladin there is a mod you can do to trigger top up with a timer
https://www.facebook.com/groups/1108024512629017/permalink/5060442320720530/
I’ve taken it a step further and got a wifi relay so I can remotely trigger it with home assistant
https://www.facebook.com/groups/1108024512629017/permalink/5235351189896308/
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 http://www.paladin.nz/about.html
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.
- name: Grid Tariff Import Price
unit_of_measurement: AUD/kWh
state: >
{{ 0.3142 }}
- name: Grid Tariff Export Price
unit_of_measurement: AUD/kWh
state: >
{{ 0.13 }}
So I could use that to see my cost or income at any point using this (test version)
- name: Grid Solar FIT V2 Today
device_class: monetary
state_class: measurement
unit_of_measurement: AUD
state: ${{ ((states('sensor.grid_tariff_export_price') |float ) * states('sensor.daily_energy_export') |float )| round(2) }}
- name: Grid Import Cost V2 Today
device_class: monetary
state_class: measurement
unit_of_measurement: AUD
state: ${{ ((states('sensor.grid_tariff_import_price') |float ) * states('sensor.daily_energy_import') |float )| round(2) }}
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.
Any ideas why?
Cheers.
The only reason why you would not have history is you have either:
- explicity excluded the new sensors from the recorder
- turned off recorder for all sensors except the ones you specify.
What does your recorder config look like?
Here is mine for example
recorder:
exclude:
entities:
- sensor.mqtt_consumption
- sensor.mqtt_production
- sensor.mqtt_export_power
- sensor.mqtt_import_power
Please see this for more information regarding the recorder
Also, what does your history config look like?
This link for history integration
I thought that too but can’t see anything that stands out.
recorder:
auto_purge: true
auto_repack: true
purge_keep_days: 10
exclude:
entities:
- sun.sun # Don't record sun data
- sensor.date
- sensor.suntriggerstudy
- sensor.time
# remove day-of-week exclusion
# - sensor.dayofweek
entity_globs:
- sensor.weather_*
- sensor.drcc_a64_*
- sensor.steve8_*
- sensor.steves_ipad_6th_gen_*
# - sensor.bom_*
# - sensor. Glances_*
- sensor.suntrigger*
event_types:
- call_service # Don't record service calls
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:
- name: Grid Net Total Energy Cost Today
device_class: monetary
state_class: measurement
unit_of_measurement: AUD
state: $'{{ (states('input_number.grid_daily_supply_charge') | float + ((states('input_number.grid_energy_import_tariff') |float ) * states('sensor.daily_energy_import') |float ) - ((states('input_number.grid_feed_in_tariff') |float ) * states('sensor.daily_energy_export') | float ))| round(3) }}'
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.
Well I have now tried multiple variations and so far what seems to make a difference is to set up the Utility Meter to measure the daily energy import or export (kWh) under YAML, not via the Helper menu (sub-menu of Settings). The only difference is in the YAML version I set the Tariffs option.
If I compare the two, I get the same kWh readings, but it appears the way the UI version is handled in the maths equation of the Template Sensor is different.
I will let it run for 24 hours and then I will add a Tariff to the UI version and see what happens. Maybe I am dreaming and need to triple check my settings, but I now have three variations running and only one is giving me history - the YAML Utility Meter!
EDIT:
Well I feel like a goose. After much trial and error, I found I had two problems:
1. Extraneous characters in my maths/state code; and
2. I hadn’t twigged to the obvious, that when I set up a new sensor, it will return an error in a formula until it has some data. So setting up a new solar generation sensor after sunset will most likely return “unknown” results on an equation until tomorrow. If only I had just waited 12 hours.
I did spend a bit of time working out how I want naming conventions, because quite a few of my sensors across HA don’t conform to any pattern. So as I was re-doing my energy set-up based on @del13r advice, I started re-naming or creating them like this:
sensor.
grid
_power ##(instant import W)
_energy ## kWh importing Currently all-time: sensor.grid_import_energy
_daily # Utility Meter single kWh EXISTS in config already
_tou ### Utility Meter parent of below
_peak ### use "peak" for single tariff instead of daily?
_shoulder
_offpeak
_supply_charge # $
_tariff # single $/kWh eg $0.3142
_tou ## used in automation if TOU
_peak ## if TOU - use "peak" for single tariff?
_shoulder
_off-peak
_cost # single tariff calculated by above (kWh * tariff)
_daily
_peak ## if TOU - use "peak" for single tariff instead of "daily"?
_shoulder
_off-peak
consumption
_power ##(instant W)
_net ##(instant production minus import W)
I thought this would be a simple & quick process, but so far I am up to 35 sensors (including allowing for future ToU and capped exports) I’m sure there are a couple I have missed- but there might be some I can collapse. I haven’t started on planning naming conventions for battery sensors yet!
I did start with explanatory names like “sensor.grid_energy_import_daily” but the names started getting too long and related-sensors weren’t grouped. I identified tier-1 names like “grid”, “solar” & “consumption” to allow a quick search of all “children” sensors.
1 Like