Energy Dashboard showing bogus values

Just because other people make the same (or similar mistakes) does not make the way you have your sensors set up correct.

I tried to help. If you don’t want to be helped then good luck.

OK!
After the thread here was derailed, let me start from scratch and document the problem again.
Maybe someone who observes the same can speak up, or someone who understands how the Dashboard works can propose an explanation.

.
.
During the past months I had several occasions where the Energy Dashboard (and only the Dashboard) showed nonsense Values for a single hour.
In the first case I tried to fix the values stored in the Database and broke the DB in the process.
So I started over, but this time build my own counters which now proof (besides common sense) that what the Dashbord is telling is not only bogus, but also only affects the Dashboard.

The general Setup:
image
But I have this over several Versions since early december. Its essentialy a day-0 issue.

A Shelly 3EM provides Power Measurement for all 3 phases.
This Numbers are summed up and then split by a template Sensors into Power from Grid and Power to Grid.
For both Sensors exist left Rieman Sum Helpers, which provide the Energy Values used in the Dashbord for Energy to Grid and Energy from Grid.



Details on the Template Sensors see here: Shelly 3EM 3-phases Energy sensor - #166 by Zarox666

A Shelly 1PM measures the production of the Solar Panels, Its power value is also feed into a left Rieman Sum which in turn is listed in the Dashboard for the Production.

2 Shelly Plug S measure the power that goes into the UPS and into the Battery-Charger connected to the UPS Battery. Here the Energy values provided by the two Shellys are summed up in a template sensor and this is provided to the Dashboard as Energy to Battery.


A Shelly 1PM measures the output from the UPS and is used in the Dashbord directly.

.
.
Case 1: 15kWh into battery

The UPS is a 330VA APC with a 55Ah Battery. So the values are physicaly impossible.
The “UPS Energy Loss” Consumer is the Delta between “UPS Energy to Batttery” and “UPS Output”.
So if there would have been suddently 15kWh going into the battery, but only the normal 2.3kWh out of it, this would have exploded as well.
Here is the “UPS Energy to Battery” sensor for the day in question:

.
.
Case 2: 2.5kWh from Solar Panels during the night.

The corresponding Sensor during the interesting timeframe:

So where is that Solar Energy on the Dashboard coming from??

.
.
While Investigating I found something noteworthy in an completely unrelated Sensor but during the same hour.
The Energy Values of Both Shelly Plug S that measure what goes into the UPS have dropped to 0.
Hence the “UPS Energy to Battery” Sensor also dropped to 0 and started counting upwards from there again.

I have no clue yet why this happend but its a completly unrelated Measurement so it does not serve as an explanation what happend to the Solar production.

.
.
It seems
@fridayAr Shelly 3EM 3-phases Energy sensor - #176 by fridayAr
@Rachdingue Energy integration and utility meters

Are hitting simmilar / same? Issues. But they need to speek for their experiences and implementation details themself.

.
.
Any hints / clues / ideas on-topic are very welcome.

I still need to check everything that was written in this thread, hadn’t time for that yet, but if you are talking about random values which aren’t tracked by any sensor then, yes, I still have the same problem:

Did you change something from your solution, from the other thread?

I only changed the availablity check to is_number instead of the not ‘unavailable’ that I hade before as @tom_l correctly pointed out there are other non-numeric states.

This is a good suggestion but it wont work for germany. Our energy on every phase is calculated together before importing or exporting:
e.g.:
Phase 1 → 1000W
Phase 2 → -1200W
Phase 3 → 300W

100W imported NONE exported. Thats why you need to sum them. If you just check if Phase 2 is exporting and neglect to check the others you won’t get the correct value.

Can we please not derail this thread again?

The WHY the acumulation is required has been discussed in great detail in the thread about the Shelly 3EM so lets keep this thread about how and why the Dashbord shows stuff that is not seen in the corresponding Sensors.

I also wanted to reply to you but you were faster.

I think my problem is another then yours because in my case I can see a sudden increase in m energy exported:


So in my case it seems to be a configuration error, or is it the same?

I would guess that I used the wrong state_class but I somehow can’t get my head around the difference and when to use them

  # ---- Netz Total Power Summed ---- #
sensor:
  - name: "Netz Total Power"
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >
      {{ ([ states('sensor.shellyem3_channel_a_power'),
            states('sensor.shellyem3_channel_b_power'),
            states('sensor.shellyem3_channel_c_power') ]
            | map('float') | sum) | round(2) }}
    availability: >
      {{ states('sensor.shellyem3_channel_a_power')|is_number and 
      states('sensor.shellyem3_channel_b_power')|is_number and 
      states('sensor.shellyem3_channel_c_power')|is_number }}
  # ---- Netz Total Power Summed ---- #
  # ---- Add all PV which aren't monitored by the 3em ---- #
  - name: "Netz Total Power with pv"
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >
      {{ states('sensor.Netz_Total_Power') | float 
      - states('sensor.pv_east_side_energy_power') | float }}
    availability: >
      {{ states('sensor.Netz_Total_Power')|is_number and 
      states('sensor.pv_east_side_energy_power')|is_number }}
  # ---- Add all PV which aren't monitored by the 3em ---- #
  # ---- Netz Total Power Einspeisung ---- #
  - name: "Netz Total Power Returned"
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >
      {% if float(states('sensor.Netz_Total_Power_with_pv')) < 0 %}
      {{ 0 - float(states('sensor.Netz_Total_Power_with_pv'))}}
      {% else %}
      {{ 0 }}
      {% endif %}
    availability: >
      {{ states('sensor.Netz_Total_Power_with_pv')|is_number }}
  # ---- Netz Total Power Einspeisung ---- #
  # ---- Netz Total Power Verbrauch ---- #
  - name: "Netz Total Power Consumed"
    unit_of_measurement: "W"
    device_class: power
    state_class: measurement
    state: >
      {% if float(states('sensor.Netz_Total_Power_with_pv')) > 0 %}
      {{float(states('sensor.Netz_Total_Power_with_pv'))}}
      {% else %}
      {{ 0 }}
      {% endif %}
    availability: >
      {{ states('sensor.Netz_Total_Power_with_pv')|is_number }}
  # ---- Netz Total Power Verbrauch ---- #

I am having the Code Files open anyway. I will share them in the Shelly Post so you can compare.

Well it more or less seems to be the same. I honestly can’t tell what is wrong. I changed the availability check tonight, so I can’t tell if this will fix this problem in my case.

But I can’t tell what your problem could be. Your case seems to be even more confusing.

I honestly thing about getting a tasmota device just for reading the import and export data of my electricity provider meter device, just to get the data more easy. Other people don’t seem to have this problem.

Just so you know:
I didn’t get any strange values anymore, but I reworked my calculation according to this post:

I just used the new format. My values for export aren’t bogus anymore by using the utility_meter for daily and the is_number function.

Yes correct,
he basically did the same as I did. The Counters I build myself are rock solid and have never failed while the Dashboard did multiple times:

But that is not the point of this Thread.
The Dashbord shows bogus values despite the corresponding source sensor not showing these bogus values.
Yes there are ways around it, such as building your own counters and ignoring the broken energy dashboard as I suggested allready some weeks ago.
But that cannot be the idea behind the dashboard, can it? That can hardly be the quality standard we strive for?

But from the reaction by the moderator here I get the impression that there should not be what cannot be. So instead of looking into the issue, the requested insights that have been provided got ignored and instead one is told that you do not need to recalculate the Values from a Shelly 3EM anyway (which is oviously bogus for most of us). And that statement is complelety besides the point, as the Values that failed so far were from the Solar Panels and the Battery and not from the Shelly 3EM.
However if you point to the thread with the lengthy discussion why it is needed you are told that you dont want any help anyway.

Or as friend of mine put it: Never use Home Assistant for anything that affects your comfort your money or your security.

Well… I might get layed off later this year so I might have time to reverse engineer this and fix it myself (in case I get more repros). Not sure if I should share the fix here… I get the impression its not welcome.