Device screwed utility meter when jumping to 0 for a short time

Configuration
1

As per title, the utility meter caught a spike in the source sensor when for some reason it reset.

image
image1655Ă—793 33.3 KB

shelly3em_energia_totale is the device measuring the total energy

Pompa_di_calore_giornaliero is the utility meter that resets daily

As you can see at a certain point the source sensor jumped to 0 and then recovered for some reason, but the utility meter interpreted that jump as a real consumption

image
image567Ă—844 34.6 KB

The sensor is defined as the sum of the energy measured on the 3 phases in configuration.yaml

  - platform: template
    sensors:
      shelly3em_energia_totale:
       unit_of_measurement: 'kWh'
       value_template: "{{((states('sensor.faseA_energia')|float(0)+states('sensor.faseB_energia')|float(0)+states('sensor.faseC_energia')|float(0))/1000) |round(3)}}"

How can I prevent this?

2

You have to add an availability template to the energy sensor shelly3em_energia_totale to make sure all required sensors are available themselves, because now your template sets them to 0 when unknown (due to the float(0) filters in there).

       availability: >-
         {{ has_value('sensor.faseA_energia') and
            has_value('sensor.faseB_energia') and
            has_value('sensor.faseC_energia') }}

You can use the statistics tab in the developer tools to correct the error you just had in your statistics.

1 Like
3

That is the root cause however there are other improvements you can make too. First of all being you should not be using the legacy template sensor platfrom for new sensors, you should be using the newer template sensor integration. While the legacy sensor platform is still supported it will not be getting new features, like state_class that allows you to see data older than 10 days.

example of new format (it’s not much different)

# configuration.yaml

template:
  - sensor:
      - name: Shelly3em Energia Totale
        unique_id: shelly3em_energia_totale
        unit_of_measurement: 'kWh'
        device_class: energy
        state_class: total
        state: "{{ (states('sensor.faseA_energia')|float + states('sensor.faseB_energia')|float + states('sensor.faseC_energia')|float)/1000 }}"
        availability: >
          {{ has_value('sensor.faseA_energia') and
             has_value('sensor.faseB_energia') and
             has_value('sensor.faseC_energia') }}

Notes:

You no longer need to specify defaults for your float() filters. The availability template is checked first and if one of the values is not a number the whole sensor will be marked unavailable. This fixes your spike problem as noted above.

I have removed the round() filter as adding the unique_id now allows you to set and change any rounding you like whenever you want from the frontend. Click on the entity in your dashboard (or Devices & Services → Entities) click the cog icon in the pop-up card and set the “Display Precision” option.

The device_class adds a nice icon among other things.

The state_class generates long tern statistics so you can see history older than 10 days.

Having a valid device_class, state_class and unit_of_measurement means you can now use this entity in your energy dashboard. So you may no longer need the utiltiy meter.

1 Like
4

Thanks, however, I’ve removed the erroneous data points in the statistics, but the utility meter sensors hasn’t corrected itself, not even after a restart

There was a big data point of 162kWh which I have removed

image
image517Ă—713 30 KB

but the step is still there

image
image1410Ă—603 28.8 KB

5

It won’t. The utility meter uses state data as it changes, not statistics, not historical data. It does not retroactively correct itself if you change past state history. It only updates as the source sensor changes in real time.

The only way you can correct that is in Developer Tools → Actions. Use the Utility Meter Calibrate action to set the value to whatever you want.