power consumption missed during reboot/maintenance | Home Assistant | Page 1

green prairie Nov 18, 2025, 6:24 AM

#

Hi,
I just had a maintenance stuff to do.... and to my surprise, HA did'nt recover the way i expected.
I expected the red curve: A straight line to jump to the real actual consumption (when HA is back ).
=> I had to manually adjust consumption to not have "negative consumption".

Which is even stranger. Looks like HA was able to read cunsumptions, and re-sync values on all zigbee sockets, BUT NOT from the "power clamp" (wifi) ?
All are strictly increasing.

Thx.

#

The power clamp recovered the way i expeced:

green prairie Nov 18, 2025, 8:27 AM

#

I repeated the issue by letting a heater on and shutdown HA for 10 minutes ...
I will try again without "always_available" .....

#

Same issue.... then may-be "net consumption" ???

green prairie Nov 18, 2025, 9:06 AM

#

Same issue ....
i don't fnd the right combo.
It never resume/recover at the right point ( the REAL consumption).
Looks like it continues from the last known consumption.
( in my case consumption while HA was down is: LOST ... always!)

#

If someone has the right settings..... Thx to share 😉

shy rivet Nov 18, 2025, 9:58 AM

#

In the first picture, what entities are we looking at? Are those the direct entities from the device? Or utility meters?

green prairie Nov 18, 2025, 10:15 AM

#

Those are utility meters ( based on hour, it is peak or offpeak ) .
it is defined like this :

  hourly_energy:
    source: sensor.power_clamp_energy
    name: Hourly Energy meter
    cycle: hourly
    periodically_resetting: true
    tariffs:
      - peak
      - offpeak

#

OH, is it possible that HA do not know/remember if we are peak/offpeak when we reboot ?

shy rivet Nov 18, 2025, 11:36 AM

#

I think that's because of periodically_resetting is set to true. That's not referring the utility meter cycle but resetting of the sources entity. I think when that's set to true, the state after becoming available is ignored.

green prairie Nov 18, 2025, 1:01 PM

#

You mean the first valid sample is always ignored ???? I such case the system cannot know how much i consumed while HA was offline !!!!!!

shy rivet Nov 18, 2025, 1:46 PM

#

Then simply not set periodically_resetting to true 😅 Just leave it default/false.

green prairie Nov 18, 2025, 2:15 PM

#

Ok, removed it. Same issue.... No big bump in power consumption after HA hast started. 🙁

green prairie Nov 18, 2025, 3:10 PM

#

Also tested to disable the device for 5 minutes.... My HA doesn't resync with real consumptions!

#

Looks like HA is only addind delta between consecutive valid consumptions...

green prairie Nov 18, 2025, 4:45 PM

#

Welll, after 10h+ .. I havn't found .
HA is still losing consumption during reboot.
Whatever i tested, ...
HA can't track a stupid increasing counter.

green prairie Nov 18, 2025, 6:21 PM

#

To make sure a created a new energy meter like this:

  powerclamp_energy:
    source: sensor.power_clamp_energy
    name: PowerClamp Energy meter
    cycle: hourly

=> It's ot working. => so it's not related to "peak" /" off-peak"
=> After a "plateau" ( HA was down), energy consumption is not recovered ( no bump/ big step). => cosumption lost !!!!

#

green prairie Nov 18, 2025, 7:24 PM

#

YOUHOOOOOOO, I'vot it working!!!!!!!!
Crazy long journey.

I created a trigerred template sensor to save only valid changes ( excluding uknown, unavailable)
I created a new "energy meter" on this sensor.

#

Blue line ( the old one), cyan, this solution:

#

new sensor:

### filtered powerclamp
- trigger:
    - trigger: state
      entity_id:
        - sensor.power_clamp_energy
      not_to:
        - unknown
        - unavailable

  sensor:
    - name: "power_clamp_energy_filtered"
      device_class: energy
      state_class: total_increasing
      unit_of_measurement: "kWh"
      icon: mdi:calendar-blank-outline
      state: >
        {{ states('sensor.power_clamp_energy') | float  }}

#

New utility meter:


  test_powerclamp_energy:
    source: sensor.power_clamp_energy_filtered
    name: test_powerclamp_energy
    net_consumption : true
    cycle: hourly

#

entities are equivalent,.... yes i have a stupid icon ( 🙂 )

#

filtered value seems to be slightly delayed compared to the original value:

#

=> may be the original value change too early => utility meter don't see the change ( huge step/bump).
On the other hand, the utility meter see the step in "filtered value", and track consumption as expected.... (?????)

shy rivet Nov 18, 2025, 9:16 PM

#

@green prairie Might be hard to break it even so much time spend 😄 But I'm suspecting the periodically_resetting change is just not working 😄 Because I did a test here and it is indeed that. Made two utility meters with same source. One with periodically_resetting and one without.

#

With / true:

#

Without / false:

#

So just recreating instead of changing the utility meter but with periodically_resetting: false probably alone is already enough

green prairie Nov 19, 2025, 2:46 AM

#

<music level =100% loop=infinite> INXS: Devil inside >
🙂

1. periodically resetting is defaulted to true. So there is a high chance it is the most widely used setting, and the most tested. ( but may be the Doc is not up-to-date 🙂 )
1. if changing is not working and it requires to create a new utility meter... then most ppl will never succeed to have it working
  -3) Oh oh, ... guess what .... I cannot delete some utility meter .. they are deleted in "developper tools" .... but stays on the screen ... flat and not increasing, but not "unavailable" !!!!!! .
1. I will try your solution again, but at 19:21, a new utility meter did not worked. but i have to re-test forcing to false.
1. may be we are facing to two sides of the same bug. I'm happy we both found a fix/work-arround. ( to be continued )

PS: youtube automatically played " Nifra - A state of trance 1247 guest mix" ... That's a sign: The inverted murphy's law will strike. ( if something good could happens, it will). Time to me to use the BFG: => "delete where" sql statement

green prairie Nov 19, 2025, 3:12 AM

#

deleted entity found in table :

public.states_meta

green prairie Nov 19, 2025, 4:25 AM

#

Good news: i created a new energy sensor with periodically_resetting: false:

  tst_bug_energy:
    source: sensor.power_clamp_energy
#    source: sensor.power_clamp_energy_filtered
    name: tst_bug_energy
    cycle: hourly
    periodically_resetting: false

And this is also working !!!!! 🙂 ...
So both tricks works.
I went into the code already and some PR, and it has "a long story"... 😉

green prairie Nov 19, 2025, 7:43 AM

#

Let's try a reboot of proxmox... not shutting down HA in a usual and clean way..... BAM!

#

But in this case the "filtered sensor" is corrupted... => the issue is somewhere else...

shy rivet Nov 19, 2025, 8:01 AM

#

Bit weird that periodically resetting is default true in the UI. As it is false by default in yaml.
Yeah, agreed. And you already found the bug? NICE!
You removed it from yaml? After that, if it is still in HA you should have a "Delete" button in the options of the entity.

green prairie Nov 19, 2025, 8:14 AM

#

I suspect HA to have been shooted by proxmox ...
i increased the shutdown timeout to 300 secs....( we will see)
I also set the "commit interval" of the recorder to zero. => i don't think it's a good idea to keep stuffs in memory. It's part of postgres job !
Result: KO . We have something more interesting:

green prairie Nov 19, 2025, 8:38 AM

#

green prairie Nov 20, 2025, 7:42 AM

#

PROBLEM solved here: https://discord.com/channels/330944238910963714/1440877546353721505
Issue was that HA (supervised) was not cleanly shutting down. ( I added ha core stop when stopping hassio.service)

#power consumption missed during reboot/maintenance