2023.3: Some history stats get sudden drops after upgrade

v6ak · March 2, 2023, 1:51pm

After upgrading to 2023.3, I’ve noticed some strange behavior of some history stats sensors. They get some sudden drops, which is not what I expect from a sensor with a fixed duration and end=now(). Some sensors seem to be unaffected, but maybe the issue just hasn’t occurred yet.

There are definitions of the troublesome sensors:

  - "duration":
      "minutes": !!int "20"
    "name": "bathroom fan cooldown need"
    "state": "on"
    "entity_id": "switch.bathroom_fan"
    "end": "{{ now() }}"
    "type": "ratio"
    "platform": "history_stats"

  - "duration":
      "hours": !!int "24"
    "name": "fridge humidity ok last 24h ratio"
    "state": "on"
    "entity_id": "binary_sensor.fridge_humidity_ok"
    "end": "{{ now() }}"
    "type": "ratio"
    "platform": "history_stats"

History of those sensors:

I had a hypothesis that the key difference is that some history stats are based on a sensor that rarely changes (so the issue doesn’t appear that frequently), while some change frequently (so there are more opportunities for this bug). However, this is currently not the case of the binary_sensor.fridge_humidity_ok. This sensor is true as long as the fridge humidity is under 60 %, so it doesn’t change that frequently. Actually, it has dropped even during the period where binary_sensor.fridge_humidity_ok was continuously on.

I’ve looked at the changelog, but there is no mention of history stats. Has anyone any idea what’s going on?

EDIT: Update: The issue seems to be bidirectional. I’ve seen a history stats sensor suddenly increasing to 100%, although it should have been just 5 %.
Also, I might have found the key for troublesome sensors. Maybe all troublesome sensors are type: ratio and troublefree sensors are type: count. I don’t think I use type: time.

EDIT 2: After updating to 2023.3.1, it looks like the fridge-related sensor got fixed. But I am not sure if it is fixed just temporarily by the reboot, or fully by some code fix. I don’t see any relevant commit at Commits · home-assistant/core · GitHub .

EDIT 3: The PR Fix check on non numeric custom sensor device classes by jbouwh · Pull Request #89052 · home-assistant/core · GitHub might be related, as the source of both history stats sensors is non-numeric…

bartlomiejwulff · March 4, 2023, 7:21am

Hi there,

I have the same problem since the update to 2023.3. It’s the case for sensors which are updating frequently and it’s getting fixed temporarily after reboot of HA.

I’m already using 2023.3.1, the issue still persists.

v6ak · March 4, 2023, 9:42am

I haven’t seem the issue with 2023.3.1 yet (even though I was experiencing it several times a day with 2023.3.0), but if you see the issue persists, maybe it was fixed by the restart (temporarily) rather than by the update (permanently).

nerodoxus · March 8, 2023, 6:58pm

I have the same problem, moreover, it seems the sensor keeps right now cumulative value instead of resetting at midnight.
My config is:

- platform: history_stats
  name: Filip PC dzisiaj online
  entity_id: device_tracker.pc_filip
  state: "home"
  type: time
  start: "{{ now().replace(hour=0, minute=0, second=0) }}"
  end: "{{ now() }}"

Home Assistant 2023.3.1
Supervisor 2023.03.1
Operating System 9.5

v6ak · March 9, 2023, 9:50am

I’ve experienced the issue with 2023.3.1, too. Both with fridge and with number of cleanings last few days. The latter sensor is type: count, so even those are affected. Also, it seems that both started behave wrong approximately at the same time.

I’ve upgraded to 2023.3.2, but I don’t see a relevant item in the changelog: Commits · home-assistant/core · GitHub

markist · March 12, 2023, 8:41am

I have noticed a similar error as well:

- platform: history_stats

    name: KinderzimmerPlayingZeitProWoche

    entity_id: media_player.emil

    state: "playing"

    type: time

    end: "{{ now() }}"

    duration:

      days: 7

should give the time playing in the last 7 days, after the update it stopped working and drops to 0.

Interestingly, in InfluxDB it continues to be correct:

v6ak · March 12, 2023, 1:30pm

It’s interesting that the values in InfluxDB are correct:

That might be useful for developers who want to debug that.
It could be an usable workaround – use InfluxDB and read the value from there. I am not sure if this is suitable for 1GiB RAM devices, though…

fridolin · October 28, 2023, 5:03pm

Have you been able to figure this one out?
I have a similar issue (Link), but I have no clue concerning a possible reason/solution.