Could you clarify this?
These two sensors will get you the accumulated energy to/from the grid since the meter was installed at your place.
smartmeter_energy_ac_consumed
smartmeter_energy_ac_sold
So if you feed those into utility sensors with daily/monthly/yearly cycles you should get precise readings for energy.
Its the beginning of a new month so my Monthly Stats sorted itself.
Still not able to reset the yearly stats. I tried zero-ing the utility sensor value in core.restore_state and also calling the utility sensor reset service but but they are still showing the old values.Will probably wait longer and see if it resets it.
More than happy to run with the current settings to provide feedback. What are the sensors that you would like me to monitor?
I have also had a hard time “fixing” utility sensors. My monthly sensors got screwed up last month and I could not fix it. But it corrected itself this month.
Did you try resetting by adding a “dummy” tariff to your utility sensors?
I am currently testing some changes in sensor.py to see if it looks better. I think I also found two bugs in the code. So I will push my changes to my fork in a day or two and then maybe you can try that and if it works for you too I can prepare a pull-request for it.
There are some tricky parts to this API though. Fronius handles the API endpoints differently when the inverter is not working. In some endpoint(s) the key(s) are always present but their values may be 0 or null. And in other endpoint(s) they never include the key(s) at all if the inverter is off.
Yes i did, i added the dummy tariffs under the sensor cycles.
### yearly data ###
# calculate yearly energy used
house_energy_year:
source: sensor.energy_used_hour
cycle: yearly
tariffs:
- peak
- offpeak
# calculate yearly energy consumed from grid
grid_consumed_energy_year:
source: sensor.fronius_smartmeter_energy_ac_consumed
cycle: yearly
tariffs:
- peak
- offpeak
# calculate yearly energy sold to grid
grid_sold_energy_year:
source: sensor.fronius_smartmeter_energy_ac_sold
cycle: yearly
tariffs:
- peak
- offpeak
And i use the automation to call the reset.
trigger:
- platform: time
at: '09:00:00'
- platform: time
at: '21:00:00'
action:
- service: utility_meter.next_tariff
entity_id: utility_meter.house_energy_year
- service: utility_meter.next_tariff
entity_id: utility_meter.grid_consumed_energy_year
- service: utility_meter.next_tariff
entity_id: utility_meter.grid_sold_energy_year
No worries, let me know once the changes has been pushed out.
On a different note. I am thinking how to extract and store a sensor for ‘yesterday’s reading’ for comparison and costing calculation. Any idea?
You could play with the Mini Graph Card for Lovelace.
That card allows you to create graphs like this if you just want to see some visual history over multiple days:
I used it for a while but it had some limitations that I did not like. So for now I am creating some graphs with Grafana that I am pulling into Lovelace since I am anyway storing all the data in Influxdb. It allows for greater flexibility and you can easily create single graphs with multiple entities that “overlaps” (e.g. one bar that can show all the four energy sensors I have today below the graphs).
You can also see 3 Influxdb sensors in my package that I am using for pulling in “peak” power consumption per day/7-days/total. That could also be an option.
That said, I am nowhere near satisfied with what I am displaying today. But I am slowly improving it. So if you have ideas/solutions to what can be done i’m interested
You should try calling the “reset” service instead of “next_tariff”. The tariff is only needed to activate the reset service.
- service: utility_meter.reset
entity_id: utility_meter.house_energy_year
- service: utility_meter.reset
entity_id: utility_meter.grid_consumed_energy_year
- service: utility_meter.reset
entity_id: utility_meter.grid_sold_energy_year
This is probably too much for me at the moment. Don’t really have much spare time due to other commitments.
Was thinking of an easier way just to record today’s readying at 11:59:59 and input it to a sensor for ‘yesterday’s reading’.
Tried that and didn’t work. I ended up new sensors for the yearly readings. (Appending _2 to all the yearly sensors) a cheat quick fix.
### yearly data ###
# calculate yearly energy used
house_energy_year_2:
source: sensor.energy_used_hour
cycle: yearly
# calculate yearly energy consumed from grid
grid_consumed_energy_year_2:
source: sensor.fronius_smartmeter_energy_ac_consumed
cycle: yearly
# calculate yearly energy sold to grid
grid_sold_energy_year_2:
source: sensor.fronius_smartmeter_energy_ac_sold
cycle: yearly
I had some fun playing with automation and notifications today. I realized that I was closing in on our first MWh sold and I thought it would be nice to have a notification for every MWh that is sold and one for every MWh that is produced by the panels.
- alias: "[Energy] Push notification for each MWh sold"
trigger:
platform: template
value_template: '{{ states("sensor.fronius_smartmeter_energy_ac_sold") | round(0) % 1000 == 0 }}'
condition:
- condition: template
value_template: '{{ (as_timestamp(now()) - as_timestamp(states.automation.energy_push_notification_for_each_mwh_sold.attributes.last_triggered | default(0)) | int > 300)}}'
action:
- service: notify.<your notify entity>
data:
title: 'Yet another MWh sold!'
message: 'The solar panels keeps delivering :)'
data:
push:
badge: 1
thread-id: 'ha-solar-panel-notifications'
apns_headers:
'apns-collapse-id': 'ha-solar-panel-mwh-sold'
You can have a lot of fun with HA
Nice…
I finally managed to get my dummy sensor working for storing my end of day readings. It will kick in at 11:59:40 everyday under automation and act as ‘yesterday’s stats’ for comparisons.
Note: ignore the values. It is still showing zero as the automation hasn’t kicked in yet. Still trialling it.
If I could only find a lovelace card that allows you to create bar graphs where the bars are “overlayed” for each day then I could ditch the influxdb/grafana setup. I am using the mini-graph-card but that one can only do “stacked”, which is not the same as “overlayed”, and side-by-side.
The biggest problem with lovelace is finding all the nice cards that are really useful and also kept up-to-date.
I noticed my stats for ‘yesterday’ resets back to zero after i restart HA.
Any idea why?
What kind of sensor are you using for storing the old state? Sounds like you are storing it in a sensor that does not preserve state.
I’ve create input_number to store the reading from today (from automation) then template sensor to read the input_number and used as yesterday’s reading.
I think i need to use integration sensor but i’m not too sure how to write it.
input_number:
yesterday_energy_produced:
name: Total Energy Produced Yesterday
unit_of_measurement: "KWh"
min: 0
max: 9999
initial: 0
icon: mdi:solar-power
trigger:
- platform: time
at: '23:59:50'
action:
- service: input_number.set_value
data_template:
entity_id: input_number.yesterday_energy_produced
value: "{{ states.sensor.fronius_day_energy.state }}"
- platform: template
sensors:
yesterday_energy_produced:
value_template: >
{{ (float(states.input_number.yesterday_energy_produced.state)) | round(2) }}
icon_template: 'mdi:solar-power'
unit_of_measurement: 'kWh'
friendly_name: "Yesterday's Energy Produced"
Remove this line. With that line you are telling the sensor to start at 0 after a restart
If you skip it then it will restore it’s last state.
I have documented my setup and the cards I have used. I redid all the rest sensors and used the Fronius component. I also used most of the things you have done @nilrog. I put it all here below so maybe this could help someone. I can be hard to read all this thread to get started. I would really like to use the dual gauge card as well as some other cards but they does not work in the latest HA version. Looking forward to see more nice ideas here. And thaks for everyone who gave me inspiration.
I am still not done with the dashboard but have most of the things to get started now.
Ahhh. Easy. Will give that a try. Thanks.
Nice writeup
Will read it more in detail later. But it should make things a lot easier to setup for those who haven’t been part of this discussion.