Strange behavior of history stats/ uptime counting

I am monitoring my heating/ oil burner consumption by recording the uptime of the oil burner. The oil consumption is a function of burn time with known nozzle sizes.

I’m runnin HA OS on Raspberry Pi4 with all updates installed.

I have created the following counters in my configuration.yaml:

  - platform: history_stats
    name: Burner ON this month
    entity_id: binary_sensor.boiler_room_burner_monitor_1
    state: "off"
    type: time
    start: '{{ now().replace(day=1).replace(hour=0).replace(minute=0).replace(second=0) }}'
    end: "{{ now() }}"
  - platform: history_stats
    name: Burner ON this week
    entity_id: binary_sensor.boiler_room_burner_monitor_1
    state: "off"
    type: time
    start: "{{ as_timestamp( now().replace(hour=0, minute=0, second=0) ) - now().weekday() * 86400 }}"
    end: "{{ now() }}"
  - platform: history_stats
    name: Burner ON today
    entity_id: binary_sensor.boiler_room_burner_monitor_1
    state: "off"
    type: time
    start: "{{ now().replace(hour=0, minute=0, second=0) }}"
    end: "{{ now() }}"

I’m relatively new to HA, so the code was not “invented” by me, but more or less copied and modified from various discussions related to this kind of stuff.

The daily and weekly counters seem to be working OK, but last couple of days there has been quite strange behaviour with the monthly counter, see below snapshot from Grafana:

Grafana_graafissa_portaat

The reading has dropped during 2 last nights almost exactly the same time, abt. 4:10 AM. Last night the drop was considerably larger than the previous. These 2 instances are the only ones so far showing this behaviour. Ihave been using these counters for some 3 weeks now without any (other) problems.

How can this be??? Shouldn’t the counter be adding new values to previous ones, not to subtract in any condition???

The origin could be e.g. the daily counter reseting itself, but this should happen around midnight, not 4:10 AM??? Or some mechanism is feeding negative values??? These counters are not set by any of my own automations etc. apart from what is configuration.yaml, only monitored.

Any ideas?

I am not sure that it will help, but you could try this:
Replace:

start: '{{ now().replace(day=1).replace(hour=0).replace(minute=0).replace(second=0) }}'

By:

start: '{{ now().replace(day=1, hour=0, minute=0, second=0) }}'

A question: it looks like you are tracking the “off” state of the oil burner, and not the “on” state. Why is that?

What is your recorder set at? It has to be longer than 30 days for the month to work. I suspect the drop in value is the recorder purging old values.

1 Like

Thank You for the reply. That change also occurred to my mind, since the others are of that format as well. I will try it.

Last night it made it again. Seems to be that db retention policies etc. are OK.

Is there any chance, that that sentence:

now().replace(day=1)

…starts to behave oddly after 10th day of the month? The first time I logged this was 11th of October

What comes to the off-state monitoring, story is the following:
When i wished to start monitoring oil consumption one night, I first checked what kind of stuff I have at hand. Needed to transfer on/off data somehow to HA. Burner itself gives 230V alternate current output for hourcounters, which I needed off course to modify. I had some zigbee presence detectors, which are no good for this kind of applications due to several reasons, even though it would probably possible to monitor lightness changes in burner indicator, senso accuracy and reporting interval etc. is not good. Found also some othe stuff not so useful for this.

However, I also found one Xiaomi door/window sensor, which is based on detecting the magnet. That I could use for monitoring. So I connected a spare 230VAC/12VDC power to burner, used that to drive a normal car relay, and since that has a coil (=magnet) inside, I used xiaomi sensor to detect that. Could probably use the inbuild coil-actuted oil valve inside the housing of the burner as well, but because it operates on AC, I did not want to test how the sensor reacts to magnetic alternating field.

Anyway, now I have on/off information, which is accurate enough. However, that sensor gives “on” when the door is opened (= no magnet present) and that’s why the signal needs to be reverted.

Yes! That must be it.
See this snippit from the recorder page:
Recorder_Purge

1 Like

Thanks guys! I’m sure You have nailed it!

However, I need to continue working, its 11:00 in the morning in Finland :slight_smile: Have time to check that in the evening again.

OK, the following should do it, I suppose…

recorder:
  purge_keep_days: 35 

Probably triples my home-assistant_v2.db size, but it would probably be no problem, unless it slows down system too much.

1 Like

Yup, seems to be working now. Thanks.

As said db size is not going to be a problem, unless it slows down too much. I just made both my systems bootable from 240GB SSD. Smaller ones would have done the trick also, but these were on sale and practically cost the same than smaller ones.

Actually it seems to be that smaller than 120-128 GB are hard to find these days…

What comes to native SQLite db engine and should one move to MariaDB etc. for some reasons (?) is probably another discussion…