Total hours a given device is turned on in the current (past) day?

good evening!

I’m trying to collect some data about how many hours my kids spend watching TV and videogaming. I totally trust them but…u know…let’s collect some data for a rainy day :smiley:

Creating some binary_sensor tracking when the devices are turned on won’t be a problem (using nmap for the console and the media_player entity for the tv)

I’m a bit puzzled on how I could create a metric for summing up all the given time intervals, let’s say on a daily base, and essentially create a weekly rolling average from the daily data.

it would be totally easy on a grafana (or something) dashboard, but i was wondering if it could be done on native too.

do you have some suggestions here?

tnx allot for your support!

I use History Stats to convert the ‘on’ state to hours, then have Utility Meters based on that to accumulate daily or weekly values.

Tnx! look very promising…but I was not able to make it working. Actually, this sensor:

is the code below wrong? :open_mouth:

- platform: template
      friendly_name: Stato TV
      value_template: >
        {{ is_state("media_player.sony_kd_49xf8577", "playing") }}

- platform: history_stats
  name: TV accesa oggi
  entity_id: binary_senor.tv_playing
  state: "on"
  type: time
  start: "{{ now().replace(hour=0, minute=0, second=0) }}"
  end: "{{ now() }}"

If you are just starting out with template sensors you should be using the current format… not the legacy format shown in you example.

Also, you had a small typo in your History Stats sensor.

  - sensor:
      - unique_id: tv_playing
        name: Stato TV
        state: >
          {{ is_state("media_player.sony_kd_49xf8577", "playing") }}

  - platform: history_stats
    name: TV accesa oggi
    entity_id: binary_sensor.tv_playing
    state: "on"
    type: time
    start: "{{ today_at() }}"
    end: "{{ now() }}"

Tnx for the suggestions (actually I had the typo only on the snipped here, not in the real code…so this was not the issue unfortunately. But i’ll keep debugging)

about the new format…what a shame! i was not aware of that :expressionless: migrating all my stuff on the new format looks annoying…

But let’s say I will…since I’ve all my code in different files, ie.

sensor: !include includes/sensors.yaml
binary_sensor: !include includes/binary_sensors.yaml

are these mapping (relationships with the root configuration file) still valid? In other words, is it safe to just change the format inside the various included files, without worries of the rest?

(I think the answer is probably “hell, no”)

  - sensor: !include sensor.yaml
    binary_sensor: !include binary_sensor.yaml

This seems to work :slight_smile:

I’ve always just used Packages so I could easily break config parts up into whatever groupings make sense.