Get the value of current month energy consumed from PV

Hi.
I have a sensore which store the difference from inverter’s daily yield sensor and power meter’s export sensor energy. Practically, this difference is the energy consummed by my house from PV. And the value is ok, is the same as the Huawei Fusion Solar application displays.
Now, as long as this value resets every day, how do I calculate the value of consumption from PV in the current month, in a template sensor?

I tried to make an utility meter using my sensor, but it accumulate this sensor, which is not a good thing, as long as my sensor does not display the current consummed energy, but it is also an accumulation of the energy consummed in the day.

So, each time the energy sensor for PV consumtion is updated with the new value practically the utility meter will accumulate the accumulation of the sensor, and this will increase drastically.

Is there a way to access the history_stats or something to get the max(value) of each day in current month for my sensor?

PS: In Energy board, if the filter is set for current year, the graphic will display each month values. The tooltip displays the value I need. How can I get that value from the history, or sql, or something?

The utility meter with a monthly cycle is exactly the integration you should use.

It sounds like you had erroneously set delta_values: true when it should have been false (or not defined as this is the default). Try it again without this option set.

And the only way to access the energy statistics displayed on the Energy dashboard is with an SQL sensor that reads your database. The values for display in the Energy dashboard do not have entities you can access.

If I set the Delta values to true, indeed it will add the current value to the last value. However, If I don’t set it, it will increase the value somehow correctly, but in the end of the day, the sum of the maximum values of the days till current day + current day is not equal with the value displayed by this sensor. This sensor displays a greather value.

In the morning, before my PV’s starting generating energy I calibrate my sensor with the value displayed by Fusion Solar app in the energy consumed from PV area. Then I let the sensor accumulate. In couple of hours the value set as calibration + the value of the sensor displaying realtime consumption from PV is smaller than this utility meter. Something is wrong in how the utility meter accumulates data.

No there really isn’t. I have many, they all accumulate correctly.

You can not add energy and power. They are different things.

I think I didn’t make me clear.

My sensor:

sensor:
  - platform: template
    sensors:
      energie_consumata_in_zi_din_panouri:
        unique_id: "energie_consumata_in_zi_din_panouri"
        friendly_name: "Consum în zi din panouri"
        unit_of_measurement: "kWh"
        value_template: "{{ (states('sensor.inverter_daily_yield') | float(default=0) - states('sensor.energie_exportata_in_zi') | float(default=0)) | abs | float}}"

energie_consumata_in_zi_din_panouri, translated in English is energy_consummed_in_day_from_solar

energie_exportata_in_zi, translated in English is energy_exported_in_day, which is an utility meter, based on power_meter_exported sensor, which resets daily.

So, my sensor accumulates the energy consumed by my house, but resets daily, as long as inverter_daily_yield resets daily. The value displayed by this sensor is real, as it is exactly the same that Fusion Solar application display to me.

This is my sensor I want to accumulate in a month.

This is sensor history for yesterday:

This is how it looks in Fusion Solar:

So, the sensor accumulates correct data. But is daily, and I want to display it also monthly.

Ok… I’ve see now that my accumulation sensor (the difference between inverted_daily_yield and power_meter_exported) have some spikes at the end of the day and I don’t know why:

Maybe I must stop collecting data when inverter stops yield and starts collecting in the morning. Hmmmm… Very strange!

It’s not just at the end of the day. Look at the 19th of March. Something very wrong there.

Yes, I’ve saw… Probably, the issue is how those two sensors, from inverter and from power meter are read.

I’ve modified my difference sensor as this:

sensor:
  - platform: template
    sensors:
      energie_consumata_in_zi_din_panouri:
        unique_id: "energie_consumata_in_zi_din_panouri"
        friendly_name: "Consum în zi din panouri"
        unit_of_measurement: "kWh"
        value_template: >
          {% set daily_yield = states('sensor.inverter_daily_yield') | float(default=0) %}
          {% set exported = states('sensor.energie_exportata_in_zi') | float(default=0) %}
          {% if daily_yield <= 0 or exported <= 0 %} 0 
          {% else %} 
            {{ (daily_yield - exported) | abs | float }}
          {% endif %}

I hope this should be ok.

I think sometimes power_meter_exported is read as zero value. This will get into an unwanted value in my difference between inverter_daily_yield and power_meter_exported values. So, for those cases I prefer the value of zero.
I will see for some hours to see hat happening.

Edited:
Something is wrong… I don’t know how to do it… maybe I start again to see what is going on with my energy difference sensor calculates, because definitelly is wrong. If the values from inverter and power meter are not read in the same time I’ll get wrong value for the difference. In this particullar case I must put some other value, which I don’t know what!

There are two issues with that template.

  1. You are using the legacy template platform that does not support a state_class.

  2. You need an availability template to make your template sensor unavailable unless both sensors have valid values, if one goes unavailable the float filter default will set it to 0, creating spikes.

See: Why an availability template is important for energy template sensors

I think I solved it, till now no spike and the values are correct, including the utility meter for month value. The issue was indeed in the calculation of difference, because of the availability of sensors.
Thank you for help.

1 Like