How To Prevent Entity From Resetting To 0?

Hi There,

I have a manual MQTT entity configured that gets data for an entity I have configued for my Gas Meter. This gives me the kWh consumption,

However for some reason the entity is setting to 0, I believe possibly this is the MQTT data being sent is reading 0 at these odd points for some reason and it’s not HASSIO randomly resetting it to 0.

But the issue with this is, that the energy consumption dashboard then sees the meter as using the entire 0 to current kwh value as the consumption for that period. Like so.

Ideally I need some help on making it so HASSIO either keeps the previous value if the reading is super low (<100) Or lower than the previous reading.

The MQTT configuration for this entity is below.

  - platform: mqtt
    name: "Home Gas"
    state_topic: "SMART/HILD/"
    last_reset_topic: "SMART/HILD/"
    last_reset_value_template: homeassistant.util.dt.utc_from_timestamp(0)
    unit_of_measurement: 'kWh'
    device_class: energy
    state_class: total_increasing
    value_template: "{{ value_json['gasMtr']['0702']['00']['00']|int(base=16) * value_json['gasMtr']['0702']['03']['01']|int(base=16) / value_json['gasMtr']['0702']['03']['02']|int(base=16) }}"
    icon: 'mdi:fire-circle'

Here’s an example of the “value_json” if it helps in debugging the above.


Thanks in advance.

I have a similar issue with my SMA solar inverter. Every week or so it goes offline momentarily in the middle of the night (no idea why - it has non persistent logs!) and this changes the kWh counter to a low value then 0, then back up to the normal > 4000kWh count when it comes back online. This introduces a massive spike in energy use in home assistant. I have created a filtered version of the raw sensor (sensor.total_yield) to fix the issue:

  - sensor:
      - name: "total_yield_filtered" 
        icon: "mdi:counter"
        unit_of_measurement: "kWh"
        state: "{{ states('sensor.total_yield')|float(0) }}"
        availability: "{{ states('sensor.total_yield')|float(0) > 4000 }}"

This filtered sensor is then used in a utility meter that is fed to the energy dashboard (as I want access to the daily total). But you could feed the filtered sensor directly to the energy dashboard.


Possibly template a check for the invalid value, then return ‘unknown’ if true? I do the exact opposite for my power sensor - but it may give you an idea:

Actually Tom’s filtered sensor is probably neater… :slight_smile:

  - platform: rest
    name: "Current Power"
    value_template: >
        {% if value_json.Body.Data.PAC is defined %}
            {{ value_json.Body.Data.PAC.Value }}
        {% else %}
        {% endif %}
    unit_of_measurement: 'W'
    force_update: true
1 Like

Thank you for this, I’ve added it in with just a slight adjustment.

- sensor:
    - name: "gas_filtered" 
      icon: "mdi:counter"
      unit_of_measurement: "kWh"
      device_class: energy
      state_class: total_increasing
      state: "{{ states('sensor.home_gas')|float(2) }}"
      availability: "{{ states('sensor.home_gas')|float(2) > 100 }}"

Obviously changing the sensor to my gas meter as expected, but the main one was having to add in the device class and state class so that the energy dashboard could have it allocated.

I’ll give it 24 hours to confirm. It looks like this should be ideal.

1 Like
  - platform: mqtt
    name: "EB3 Import"
    unique_id: EB3_TotEneImp
    state_topic: "tele/edpbox3/SENSOR"
    value_template: >-
        {% set x = value_json.EB3.TotEneImp|float(default=-1) %}
        {% if x > 0 %}
          {{ x }}
        {% else %}
          {{ states('sensor.eb3_import') }}
        {% endif %}
    unit_of_measurement: "kWh"
    device_class: energy
    state_class: total_increasing

Yeah I guess the classes must have been taken care of by the utility meter in my case.

That worked perfect @tom_l , it looks like the entity did the same and reset at around 2ish again in the morning. But the filtered didn’t (meaning the dashboards reading as expected).


1 Like

I missed one of the other energy sensors I was using and this happened again last night.

The good news is that the sensor I did filter has worked.

I have found the PR that introduced this behaviour and have opened an issue to hopefully get this fixed in the integration so that we don’t have to filter the energy sensors.

Anyone tried to fix the data in the database afterwards? So that you can go back in the dashboard and don’t see the spikes any more.

My SMA integration obviously also suffers from this, but also seen it before on my Envoy installation.

Happy to see SMA pr is merged. Hopping we get the patch release before the new year, so we can start with good data.

You may find some help in this community guide: