in my case would I just add that in to customize yaml file?
"sensor.*current_power*":
last_reset: '1970-01-01T00:00:00.000000+00:00'
state_class: measurement
in my case would I just add that in to customize yaml file?
"sensor.*current_power*":
last_reset: '1970-01-01T00:00:00.000000+00:00'
state_class: measurement
For those wanting to dig a little further into their Energy visualisation not working, you can use the “SQLite Web” addon to look under the covers at the statistics and how it works. It appears some entities from plugins will have all the appropriate attributes to appear in here, if yours aren’t, check the posts above that mention last_reset:
attributes:
last_reset: '1970-01-01T00:00:00+00:00'
To get started, you will need to install the SQLite Web addon and open it, you should see something like the following after choosing statistics_meta, then content.
statistics_meta appears to be a master lookup table of all your entities that statistics are being collected on, in my case I am interested in #8:
If you then choose statistics - content you will probably see lots of entries however, I have used the query function command: SELECT * FROM "statistics" where metadata_id = 8
to pull up all entries associated with my solar feed in - there is only one because I have been trying to get my OpenEnergyMonitor configuration working despite the lack of documentation.
If you want to reset the statistics of an entity, you can do it here also, because I have been using a “smart plug” in a variety of places I wanted to reset it so it has clean data for the energy integration.
First: I manually locate it’s ID via statistics_meta and find out it is #2.
Then go to the “Query” tab and to make sure I have everything as correct as possible, I type in:
SELECT * FROM "statistics" where metadata_id = 2
and click execute.
DANGER
If that shows the results that I am expecting, to deleted it, I slightly change the command to:
DELETE FROM "statistics" where metadata_id = 2
and click execute.
It then appears that statistics are generated hourly so that is why you need to wait 2 hours for the visualisation to show any information, but if you go in via the SQLite Web addon you should be able to see some sort of value after 1 hours (on my system it shows as on the hour)
To make this slightly more discoverable, this post is about:
OpenEnergyMonitor (emoncms), EnergyManagement, Statistics, SQLite Web, database cleaning
I see what you have done differently.
You have named the first 2 power sensors as energy.
I am just going to highlight the lines that do not match each other in the config you posted here today.
template:
- sensor:
name: Grid Export Energy
- sensor:
name: Grid Import Energy
sensor:
source: sensor.grid_export_power
source: sensor.grid_import_power
This had made your source in the bottom 2 integration sensors invalid as they dont match the sensor names in the top 2 sensors.
You just need to update the first 2 sensors to these names to get this working properly.
- sensor:
name: Grid Export Power
- sensor:
name: Grid Import Power
Please revisit my original post which has the correct configuration.yaml lines Energy Management in Home Assistant - #309 by del13r
Thank you, it wil, just have to modify it so that I also have low tariffs during the weekend.
Hello,
I have Toon Zon and it not delivering a total amount kWh, only what I produce daily.
So this is my graph, it there a way to work around this issue.
Peter
So I went back and scrapped everything and copied in your code mentioned in your link. Updated the SR which I have changed to dummy for this forum.
template:
- sensor:
name: Grid Export Power
state_class: measurement
icon: mdi:solar-panel
unit_of_measurement: W
device_class: power
state: >
{{ [0, states('sensor.envoy_dummySR_current_power_production') | int - states('sensor.envoy_dummySR_current_power_consumption') | int ] | max }}
- sensor:
name: Grid Import Power
state_class: measurement
icon: mdi:transmission-tower
unit_of_measurement: W
device_class: power
state: >
{{ [0, states('sensor.envoy_dummySR_current_power_consumption') | int - states('sensor.envoy_dummySR_current_power_production') | int ] | max }}
sensor:
- platform: integration
name: Grid Export Energy
source: sensor.grid_export_power
unit_prefix: k
unit_time: h
- platform: integration
name: Grid Import Energy
source: sensor.grid_import_power
unit_prefix: k
unit_time: h
I then went to developer screen and filter for grid and got the following output.
I am not sure how the last_reset got in there currently as I only have the code as above added. If it is required can someone advise where exactly it should be placed?
I’m unsure if this has been answered further down the post (I’m still reading it) but I believe you must add the _cost
sensors in your recorder, that’s what seemed to work for me, I had a couple of days of no cost, then I added the sensors to my recorder and they showed up.
Great. Export will sort itself out when the sun comes up again and the export state is above 0. Mine did the same
After some trouble finding the right settings the energy dashboard is running now.
This extension is a really good work - Thank you
I am using a solar system with an integrate 5kWh-battery form SENEC (HACS-Integration) which is providing one entity for charge and discharge (+/- values). So far I have not found a good way how to integrate that. Currently e.g. all charging is shown as house consumption.
A further extension to integrate batteries and may be in a special way electric car would be great.
Further I struggled so far to adapt the dashboard completely to German language and frienly names for the entities.
Try configuring utility_meter
in configuration.yaml with those sensors (and configuring state_class
and device_class
), then the sensor will appear in Energy
Wow, this looks great! I just tried to add the entities from SolarEdge and DSMR Reader (which I prefer to keep because it’s near perfect), but the values I see in the Energy dashboard don’t match those from the SolarEdge integration and DSMR Reader. For instance, according to the energy dashboard, my High tarriff usage is -4.06 kWh and the High tariff return is 5.33 kW. This is actually 0,302 KWh and 2,467 KWh. The low tariff usage however does match the value from DSMR.
Consider this feedback, I will try again later to figure some things out
Nice work guys!
Malosaa, I have the same error message, did you manage to find a solution?
It looks like recorder does not start up in the right way, possibly due to this. My statistics are empty in db.
Logger: homeassistant.components.recorder
Source: util/dt.py:133
Integration: Recorder (documentation, issues)
First occurred: 12:12:00 (1 occurrences)
Last logged: 12:12:00
Error while processing event StatisticsTask(start=datetime.datetime(2021, 8, 11, 9, 0, tzinfo=datetime.timezone.utc)): argument 1 must be str, not int
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/components/recorder/__init__.py", line 623, in _run_event_loop
self._process_one_event_or_recover(event)
File "/usr/src/homeassistant/homeassistant/components/recorder/__init__.py", line 632, in _process_one_event_or_recover
self._process_one_event(event)
File "/usr/src/homeassistant/homeassistant/components/recorder/__init__.py", line 738, in _process_one_event
self._run_statistics(event.start)
File "/usr/src/homeassistant/homeassistant/components/recorder/__init__.py", line 721, in _run_statistics
if statistics.compile_statistics(self, start):
File "/usr/src/homeassistant/homeassistant/components/recorder/util.py", line 303, in wrapper
return job(instance, *args, **kwargs)
File "/usr/src/homeassistant/homeassistant/components/recorder/statistics.py", line 154, in compile_statistics
platform_stats.append(platform.compile_statistics(instance.hass, start, end))
File "/usr/src/homeassistant/homeassistant/components/sensor/recorder.py", line 284, in compile_statistics
stat["last_reset"] = dt_util.parse_datetime(last_reset)
File "/usr/src/homeassistant/homeassistant/util/dt.py", line 133, in parse_datetime
return ciso8601.parse_datetime(dt_str)
TypeError: argument 1 must be str, not int
My energie provider calculates my kWh usage using a price with 5 digits value, for example 0,17776 Euro/kWh.
I cannot enter this ‘cost’ in the energy settings, I have to round this myself first at 2 digits (0,18)
2 remarks:
When you do enter a value manually with 5 digits, HA accepts this but nothing is calculated.
When you use the up and down arrows is the costs field, that is when you see you must enter a valid 2 digit value. That input checking should be fixed, OR
Even better: have HA accpet more than 2 decimals as a cost value, so use the correct value in calculation (and round it AFTER calculations, or only in the GUI)
That would result in the accurate value.
Just joined the energy: crowd tonight, and have been playing around. Whilst I haven’t got everything working yet, it shows a heap of potential! Well done devs!
Have managed to get my TP Link plugs added, and they seem to be working fine.
Add a +1 to getting the Tesla Powerwall integration updated so that it can output energy as well. I’ve managed to manually convert some values and add them with the integration sensor, but just reading this thread I’ve realised that I’ll have to tweak the template sensors tomorrow for the grid export, as I need to use the sensor.powerwall_site_now attributes for “energy_exported_(in_kW)” and “energy_imported_(in_kW)”.
And being nighttime, I haven’t managed to test the Fronius API yet! That’ll be on the list for the weekend.
Also a +1 to seeing a battery added in due course too, once the dust settles.
Thanks for the assistance
Do you use the day consumption sensors? Then try sensor.dsmr_reading_electricity_delivered_2 and 1
Thanks! I think I got it: I’ve changed all four to the reading variants of the sensor, which tracks the actual counters instead of today’s consumption. The energy chart looks more credible now. The confusing bits are the large delays between the Energy Dashboard and both data sources (DSMR reader and SolarEdge) plus the negative value of ‘High tariff returned’ which is now -9.11 for about 10 minutes (should be 9,97).
Yes.