How long has my device been running on a specific day?

[FutureTense]

I have a device that’s controlled by a switch called myRelay. This switch in turn is controlled by many different methods. Automations, timers, scripts or even manually controlled by HA Lovelace dashboards and GoogleHome. I have a few automations that ensures myRelay is not allowed to be “on” indefinitely. If it’s turned on, one of those automations will make sure it’s turned off.

I want to know on any given calendar date (without time) specified as input (from 00:00:00 to 23:59:00 for that date) how many seconds was myRelay on for.

From the HA GUI, the Log looks like it has this information. That is I can see when the relay was turned on, the. When it was turned off. Subtracting the two, I get the number of seconds for that on/off pairing. Repeat for the rest of the on/off pairings, I get the number of seconds on for that 24 hrs.

My question is how I can programmatically do this?

[NathanCu (Nathan Curtis)]

Look up history stats.

History Stats

You’ll create the appropriate history sensor and call it as necessary

Else there’s the new recorder.get_statistics that allows dB read

[FutureTense]

@NathanCu

Else there’s the new recorder.get_statistics that allows dB read

Are you referring to this?

SQL

[NathanCu (Nathan Curtis)]

This
Recorder - Home Assistant.

Im using it in the dB history function for my LLM

I use the call heavily here you can probably ripoff a lot of syntax…

Friday's Party: Creating a Private, Agentic AI using Voice Assistant tools

New tool RC: REQUIRES 2025.6.x or better (recorder.get_statistics) History CRUD - because someone went and made recorder.get_statistics and I could not be happier… Yep it’s exactly what it say s it is - AI access to the history stats. NOW - WARNING - this one’s a tool that’s a LOT open ended, it’s prerelease so the docs suck and - yes there are surprises. It will not be 100% but shouldn’t be destructive. I handled attempts to create, edit or delete history. YOU WILL have to walk the LLM th…

[FutureTense]

Btw, creating a sensor did the trick for finding the time of my device on for today, but I’m afraid it won’t do much for prior days. So I was going down the rabbit hole and trying to use get_statstics.

action: recorder.get_statistics
data:
  statistic_ids:
    - sensor.energy_meter
    - sensor.water_usage
  start_time: "2025-06-10 00:00:00"
  end_time: "2025-06-11 23:00:00"
  period: hour
  types:
    - sum
    - mean
  units:
    energy: kWh
    volume: L
response_variable: consumption_stats

But I have no idea where to place it. I’m still caught in a world between using !include directives and using the GUI for creating automations, etc.

My configuration.yaml has this leftover from a few years ago:

recorder:
  db_url: !secret db_connection
  purge_keep_days: 10
  

Does this have any relation as to where I define stuff for get_statistics?

Before I go too far I need to ask; I only want to save how much time that device was on, PER DAY. Since this is a single floating point number, I should easily be able to save years of data without a DB performance hit? I mean 3 years is 1095 rows, so it’s not that large

[NathanCu (Nathan Curtis)]

Read the documents for the recorder integration. Basically answers all of that.

Recorder

By default it keeps 10 days. That looks like some kind of override. But to… What is now the default? But like I said read the doc stem tk stern first for recorder.

[mekaneck (Rick)]

The recorder.get_statistics action will get data from the statistics table in your history database, which will have data retained indefinitely. As noted in the docs, statistics are only retained for sensor entities which meet a few requirements. Therefore the on/off state of a switch entity isn’t going to be in there. Instead, that info is only available in the states table, which you have configured to retain data for 10 days.

As you already mentioned, the new “history_stats” sensor you created only starts working the moment you created it. It doesn’t calculate information in the past. However, you only have 10 days of data available that you could possibly get the data from.

Yes the data is there, and yes you could probably write some SQL commands to pull the data out and calculate what you want. But I would just give up on those 10 days and let your new sensor do the heavy lifting from this point forward.

The important thing to do at this point is ensure your new history_stats sensor is properly configured to retain statistics in the format you want.

[FutureTense]

So even with my config of 10 days, it should retain that sensor data longer than that?

[FutureTense]

Although I setup my sensor, when I’m trying to display that with Lovelace

  - entity: sensor.feeder_on_today

It’s display that as hh:mm eg (0h 3m)

I’ve spent a couple hours trying to find a way to display h:m:s and keep going in a circular google loop. Is there a way to use templating or something else to display this duration to include seconds?

[mekaneck (Rick)]

@FutureTense

So even with my config of 10 days, it should retain that sensor data longer than that?

It will retain the hourly statistics for that sensor indefinitely. You will want to customize the sensor so that it has state_class: total_increasing so that the statistics are useful. Then, you can use a statistics graph card on your dashboard to show the daily “on” time of the relay (or weekly, or hourly, or whatever interests you). The “note” on the history_stats docs page mentions this.

@FutureTense

Is there a way to use templating or something else to display this duration to include seconds?

You will need to choose a card that supports templates. There may be other card options but I know very little about dashboards and someone else will hopefully chime in.

[rekenaar]

Hi, using a mushroom template card:

{{ timedelta(hours=states(entity)| float(0))  }}

(note - you can show the seconds, but a history stats does not update every second)