Help me configure sensors w/ templates? (specifically pi-hole)

Configuration
1

I just configured my HA instance to use my pi-hole server as a sensor. To do that, I modified configuration.yaml as such:

sensor:
  - platform: yr
  - platform: pi_hole
    host: pi.hole

This resulted in my “icon bar” showing the following:

I wanted to modify the labels that appeared underneath those icons and I wanted to add a Group for the pi-hole values. I know the Group would be redundant but I was mainly trying to explore & play around. I saw this article which pointed me at “templates” to do what I was after.

So I tried it, but all it does is add three new icons in addition to the three pi-hole ones already there. The new ones are blank.

Here’s what I’ve added to my configuration.yaml:

sensor:
  - platform: yr
  - platform: pi_hole
    host: pi.hole
  - platform: template
    sensors:
      pihole_queries_today:
        value_template: '{{ states.sensor.pihole.attributes.queries_today }}'
        friendly_name: 'Queries Today'
      pihole_percentage_today:
        value_template: '{{ states.sensor.pihole.attributes.percentage_today }}'
        friendly_name: 'Percentage Today'
      pihole_ads_blocked_today:
        value_template: '{{ states.sensor.pihole.attributes.ads_blocked_today }}'
        friendly_name: 'Ads Blocked'

Now, I’ve got some questions:

  1. The code I posted above came from that other HA Community article, BUT the variables it configures: pihole_queries_today, pihole_percentage_today and pihole_ads_blocked_today are different from what is listed on the pi-hole sensor page here which references dns_queries_today, ads_blocked_today and ads_percentage_today. Are those values supposed to match?
  2. How do I find out which value_template to use? As stated above, the pi-hole sensor page, that code from the community post and the code in github all have attributes that don’t agree in name (in code, I’m talking about MONITORED_CONDITIONS and ATTR_BLOCKED_DOMAINS).
  3. If I just want to change the caption (friendly name), do I even need the value_template or can I just set the friendly_name? I’ve tried that to, but it wasn’t working.

If there’s a good tutorial or wiki page that you can point me to, I’d greatly appreciate it (and will even edit/update it!). Most of the documentation & help I’ve found on these forums or the GitHub issues has been spot-on and very helpful. When it comes to templates though (and pi-hole, which is probably a niche sensor), I’ve had a rough time of getting good examples & explanations.

2

You can also put code in a “customize:” block as a child of “homeassistant:” to change friendly names without the need to deal with value_templates (unless you specifically need to create a separate sensor to isolate an attribute from pi_hole).

Also, check your states dev tool. That’ll show you the attributes that exist for your sensor.pihole. The format you have above is correct to create templates referencing attributes

{{ states.ENTITYID.attributes.ATTRIBUTE }}

where ENTITYID is something like “sensor.pihole” or whatever you glean from the states dev tool.

3

Thanks, @Ih8gates! I switched my stuff to use the customize block and it worked right away.

Regarding my original approach, and if you know the answer, when it said:

- platform: template
    sensors:
      pihole_queries_today:
        value_template: '{{ states.sensor.pihole.attributes.queries_today }}'
        friendly_name: 'Queries Today'

does pihole_queries_today reference an existing sensor or does it define a new sensor? I know it’s not important to what I’m doing now since Customize doesn’t really need it, I’m just trying to learn what’s going on.

4

That code block you have there defines a template sensor. So you can create sensors that are based on anything that can be represented as a template. For example, I have a “gloomy weather” sensor that triggers when it’s raining or >80% cloudy (or both).

In your example, it creates a sensor called “queries today” that’s valued from the queries_today attribute of the sensor.pihole entity.

Some other examples that might be helpful:

  - platform: template
    sensors:
      sunrise_display:
        friendly_name: Next Sunrise
        value_template: '{% if states.sun.sun %}{{ ((as_timestamp(states.sun.sun.attributes.next_rising)) | timestamp_local) [11:16] }}{% endif %}'
      sunset_display:
        friendly_name: Next Sunset
        value_template: '{% if states.sun.sun %}{{ ((as_timestamp(states.sun.sun.attributes.next_setting)) | timestamp_local) [11:16] }}{% endif %}'
5

That’s an excellent example, thanks!

And it’s funny you mentioned the gloomy-weather sensor, because I wanted to implement something exactly like that! Do you have any code to share? Otherwise it sounds like it could be a good sensor to practice with.

I’m still using the default yr weather provider and I’m in the US (Georgia). Do you have a recommendation for weather providers that work well for your gloomy weather detection?

6

This is still a work in progress, but I recently started using this sensor to trigger an automation that turns on a few indoor lights. I wanted to get something that’d be a good determination if it’s dark inside based on sun angle and cloud coverage. I’ll prob eventually get a sensor that senses brightness in a room, but this is working OK for now. I’m still dialing-in what the best numbers to use are. I used to use offsets from sunset, but this seems to work better.

It’ll be true if the sun is within 30 degrees of the horizon or if it’s 90% cloudy or if the sun’s within 40 deg of the horizon and it’s cloudy.

      turn_on_indoor_lights:
        friendly_name: 'Turn On Indoor Lights'
        value_template: >
          {% if (states.sun.sun.attributes.elevation | int < 30) %}true
          {% elif ( (states.sun.sun.attributes.elevation | int < 40) and (states.sensor.dark_sky_cloud_coverage.state | int > 50)) %}true
          {% elif (states.sensor.dark_sky_cloud_coverage.state | int > 90) %}true
          {% else %}false
          {% endif %}