WTH doesn’t the energy dashboard work with watts as a source

[jeffbrown]

The energy dashboard requires multiple sensors to operate, including net kwh, consumed kwh, and returned kwh.

However, some metering devices may only provide power (watts) and net energy (kwh). In that scenario, an estimate of consumed and returned energy could be constructed by integrating power over time. It might drift but it’s better than nothing.

Aside: I can’t seem to figure out how to reconfigure the Energy dashboard now that I have set it up. I could probably find it by searching the documentation but why isn’t there an Edit or Settings button prominently located on that screen like on other dashboards?

[CChris (Christoph)]

to edit the energy-dashboard:

→ Settings → Dashboards → Energy
There you can add / remove entities for the Dashboard.

Calculation / guess of energy consumption based on W information from a Sensor:
HA provides some methods to calculate Wh or kWh from a Sensor that only provides W…

here’s the documentation how to do that (Rieman sum integral)

Integration - Riemann sum integral

[NCO3]

Hi Christoph,

I use this approach, but it does not seem to work:
What I did was:
I have created a yaml config for my base consumption (I switched off all devices I could to determine this consumption in Watts:

- platform: template # Grundlast in W (Sum of all NOT monitored devices )
  sensors:
    energy_consumption_base_w:
      friendly_name: Strom Grundlast [W]
      unit_of_measurement: "W"
      icon_template: "mdi:counter"
      device_class: power
      value_template: "{{ 185 | float(2) | round (0) }}"

I used this as the source for the kWh using Riemann (via UI), which I can use in the energy dashboard.

Unfortunately it’s not updated (as the base consumption is a constant value?).
Whenever I change the base consumption in Watts, it will be updated.

From my perspective it should be updated even though the source sensor is constant.
Or is there some misunderstanding from my side?

[CChris (Christoph)]

Hi, I haven’t yet worked with a Rieman energy calculation…
but can you maybe show how this sensor is configured?

Maybe, I can do some further tests with some of my sensors that provide a W value…

[NCO3]

Hi Christoph,

thank you, that would be greatly appreciated.
Because it’s configured by the UI the config is not visible (or is there any way?)
thus, I will create one in yaml to share.

[CChris (Christoph)]

So, I’ve just created a Rieman integral within the UI - and this is the result:

but honestly, I haven’t really done anything to determine what the correct methods for the calculation should be…

[NCO3]

Thank you.

I have created this sensor and will monitor it.

- platform: integration
  unique_id: energy_consumption_base_kwh
  source: sensor.energy_consumption_base_w
  name: "Strom Grundlast YAML [kWh]"
  round: 2
  unit_prefix: k
  method: left

Whenever I update the source entity, the Riemann is updatd as well.
I will monitor the yaml sensor behaviour if it’s nto updated but constant.

[seanomat]

To force an update of your integration-sensor in regular Intervalls add a time-trigger to your source template sensor and an attribute that changes every time, like a timestamp.

[NCO3]

@seanomat

that changes every time, like a timestamp

That sounds interesting.
So I would need to change this timestamp manually, I guess because the source is constant?

[seanomat]

Your source sensor (Power) would look something like this:

  - trigger:
      - platform: time_pattern
        minutes: "/1"
    sensor:
      - name: energy_consumption_base_w
        unique_id: energy_consumption_base_w
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        icon: mdi:flash
        state: "{{ 185 | float(2) | round (0) }}"
        attributes: 
          timestamp: "{{ now() }}"

Whenever the source-sensor changes (an attribute-change is also a state-change) the integration-sensor will update, so in this case every minute because the trigger of this sensor fires every minute and creates a new value for the attribute “timestamp”

[CChris (Christoph)]

So, my two rieman integral sensors where running for a few hours now…
Both are collecting and increasing… they are using the same source (which provices W) - but using different calculation methods (as far as I remember)

So - both are pretty equal, the difference in the total value is related to the time difference when I created the sensors…

Compared to the original source, which does reset at midnight, I think, that’s pretty accurate

only todays Wh usage…

[TheFes]

If you would just use {{ 185 }} as your template you would get the exact same result. You are now taking an integer, turning it into a float (with 2 as it’s default) and then rounding it to 0 digits

[NCO3]

Thank you so much for your support.
Much appreciated.
This is accepted in configuration.yaml.

template:
- trigger:
  - platform: time_pattern
    minutes: "/3"
  sensor:
  - name: energy_consumption_base_w
    unique_id: energy_consumption_base_w
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    icon: mdi:flash
    state: "{{ 185 | float(2) | round (0) }}"
    attributes: 
      timestamp: "{{ now() }}"

However, I have a separate sensors.yaml, but I struggle with transferring this, because the entry obviously need to start with sensor.

I played around with the format, but don’t get it.
(sorry, if this is trivial, but I migrated recently from openhab):

@CChris
Thanks for your verification.
I assume your source sensors change over time?
So, I guess this is the culprit (on my side), that Riemann only works on changing source sensor values.

@TheFes

If you would just use {{ 185 }}

That’s true and is obviously a relict from me fiddling around.
Thanks for pointing out.
However this does not make a difference re:my issue

[CChris (Christoph)]

I guess your seperate sensors.yaml will be included in the configuration.yaml in this way:

sensor !include sensors.yaml

Try the following:
create a new file - name it templates.yaml for example.
Inlcude it in the configuration.yaml in the same way as you did it for the sensor file.

template !include templates.yaml

Then, you can use the above code in the new file:

- trigger:
  - platform: time_pattern
    minutes: "/3"
  sensor:
  - name: energy_consumption_base_w
    unique_id: energy_consumption_base_w
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    icon: mdi:flash
    state: "{{ 185 | float(2) | round (0) }}"
    attributes: 
      timestamp: "{{ now() }}"

Please be aware that the “template:” has been removed and the code is starting with two spaces

[seanomat]

As chris already mentioned, this is the new way of defining template sensors:

Template

[NCO3]

Good Morning Christoph and thank you again.

I did as suggested.
Actually I just recognized that all my sensors are of type template

e.g.
- platform: template # Gas in m³
  sensors:

So, the issue that the trigger template not working with all the cascading entries (template, trigger, sensor) is in conflict with my templates starting with sensor because of

sensor: !include sensors.yaml

right?

So, I guess it’s a good idea to move these over to templates instead and use the sensors.yaml for “pure” sensors only.

Anyway:
The result is that the attribute is updated with the timestamp, and so is the Riemann sensor.

Thank you very much for your strong support, @CChris

[NCO3]

Thanks - I will check it out to be better prepared for the next challenge

[CChris (Christoph)]

there are many different situations where this can come from…
Mostly, related to changes within the last couple of releases - where key elements of the configuration have been restructured.

For example, manually configured integrations:

They usually start with:

sensor:
  - platform: your_integration

here’s an example from my sensors.yaml

# Systemmonitor
- platform: systemmonitor
  resources:
    - type: disk_use_percent
    - type: disk_use
    - type: disk_free
    - type: memory_use_percent
    - type: memory_use
    - type: memory_free
    - type: swap_use_percent
    - type: swap_use
    - type: swap_free
    - type: network_in
      arg: eth0
    - type: network_out
      arg: eth0

some time ago, the templates had the same structure…

sensor:
  - platform: template

Here’s the documentation which does describe the “new” templates…

Template

further down in the text, there is an area about “Legacy Templates” - which is the old format…

[NCO3]

Thanks for the explanation.
I will do my best to track these breaking changes.
It’s tricky though and I need to get some more experience with HA first.

Again - thank you for your support.
The forum here is really awesome - and the level of support and contribution among “home-automationers” is obviously massive (I just can speak about openhab / HA though).

[NCO3]

Good Morning Christoph,

sorry to bother you again - please allow one more question.

I am currently cleaning up my sensors (being templates actually) and move them to templates.yaml.

So for example this sensor:

- platform: template # Gas in kWh
  sensors:
    gas_meter_kwh:
      friendly_name: Gas gesamt [kWh]
      unit_of_measurement: "kWh"
      icon_template: "mdi:counter"
      device_class: energy
      value_template: "{{ states ('counter.gas_zahler_rohwerte') | float(0) * 0.01 * 11.5}}"

supposed to be transformed into this template:

# Gas in kWh
- sensor:
  - name: "Gas gesamt [kWh]"
    unique_id: gas_meter_kwh
    unit_of_measurement: "kWh"
    icon: "mdi:counter"
    device_class: energy
    state_class: measurement
    state: "{{ states ('counter.gas_zahler_rohwerte') | float(0) * 0.01 * 11.5}}"

This seems to work obviously, but creates a problem:

If I create the template with the same name (to keep the historic data in place) HA will automatically rename it to gas_meter_kwh_2 - even though I removed the entry from sensors.yaml of course.
Furthermore HA restores gas_meter_kwh indicated by this in the UI:

Is there any way to prevent this and force the new template to take over the place (and data of the “old” sensor?