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.
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?
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).
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.
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.
does pihole_queries_todayreference 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.
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 %}'
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?
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 %}