A template to show Zigbee devices with flat battery

With a lot of battery-powered ZigBee devices on my home network (thermostats, contact sensors, remote controls, etc) it’s useful to have an Home Assistant dashboard with the status of all the batteries, to change the ones before the device goes off.

Simple task, with an Entities Card:

type: entities
title: Battery level
state_color: true
entities:
  - type: section
    label: Remote controls
  - entity: sensor.switch_01_ikea_e1743_battery
  - type: section
    label: Thermostats
  - entity: sensor.thermo_001_battery
    name: Living room
  - entity: sensor.thermo_002_battery
    name: Parents room

With the following result:

Home Assistant Battery dashboard

But this approach has three main drawbacks:

  • Every time a new devices is added to the network, the card needs to be updated
  • Even if the colors help to identify at a glance the batteries that need to be replaced, the search is still a manual process
  • It cannot be automated, for example sending a message every time a battery goes under a certain level

Templates to the rescue

Here a Markdown card with a template that identify all the entities in the system tracking battery level, find the ones with a value below a certain number, and list them:

type: markdown
content: |
  {#- Find all the battery sensors -#}
  {%- set sensors = expand(states.sensor)
    | rejectattr('state', 'in', ['unavailable', 'undefined', 'unknown'])
    | selectattr('attributes.device_class', 'defined') 
    | selectattr('attributes.device_class', '==', 'battery') 
    | rejectattr('entity_id', "search", "keepout_8p")
    | selectattr('attributes.unit_of_measurement', 'defined') 
    | selectattr('attributes.unit_of_measurement', '==', '%') 
    | list %}
  {#- Show only the entities with a battery level below a certain threshold -#}
  {%- for s in sensors -%}
  {%- if s.state | int(0) < 30 -%}
    {{ s.attributes.friendly_name + ": " + s.state }}
    {#- s.entity_id can be used too #}
  {% endif -%}
  {% endfor -%}
title: Devices with low battery level

With this final result:

Home Assistant Markdown card

Let’s look at the code block by block.

Find all the entities measuring a battery level

  {#- Find all the battery sensors -#}
  {%- set sensors = expand(states.sensor)
    | rejectattr('state', 'in', ['unavailable', 'undefined', 'unknown'])
    | selectattr('attributes.device_class', 'defined') 
    | selectattr('attributes.device_class', '==', 'battery') 
    | rejectattr('entity_id', "search", "keepout_8p")
    | selectattr('attributes.unit_of_measurement', 'defined') 
    | selectattr('attributes.unit_of_measurement', '==', '%') 
    | list %}

First, the expand() command returns all the sensors in the system, then a series of Jinja 2 filters are applied to remove unavailable, undefined and unknown entities, find all the entities with a battery device class, remove entity_id of my phone (keepout_8p) and find all the remainig entities with the % as unit of measurement of the battery.

Find all the battery level below a certain threshold

  {#- Show only the entities with a battery level below a certain threshold -#}
  {%- for s in sensors -%}
  {%- if s.state | int(0) < 30 -%}
    {{ s.attributes.friendly_name + ": " + s.state }}
    {#- s.entity_id can be used too #}
  {% endif -%}
  {% endfor -%}

A simple check for all the sensors found previously, to identify if there are battery levels below a certain threshold. To be sure a comparison between numbers is done, the state value is parsed as integer, and then compared with the threshold level. Once the entity is identified, the message to show is assembled, chaining different property of the sensor.

A template sensor with the devices

To get the information, but inside an sensor, it could be useful to create a template sensor. The logic is the same:

 template:
  - sensor:
      - name: ZigBee devices battery to change
        unique_id: zigbee_devices_battery_to_change
        state: >
          {#- Find all the battery sensors -#}
          {%- set sensors = expand(states.sensor)
            | rejectattr('state', 'in', ['unavailable', 'undefined', 'unknown'])
            | selectattr('attributes.device_class', 'defined') 
            | selectattr('attributes.device_class', '==', 'battery') 
            | rejectattr('entity_id', "search", "keepout_8p")
            | selectattr('attributes.unit_of_measurement', 'defined') 
            | selectattr('attributes.unit_of_measurement', '==', '%') 
            | list %}
          {#- Show only the devices with a battery level below a certain threshold -#}
          {%- for s in sensors -%}
          {% if s.state | int(0) < 30 %}
          {{ s.attributes.friendly_name + ": " + s.state }}
          {#- s.entity_id can be used too -#}
          {% endif -%}
          {%- endfor -%}

The Community Commitment Curve to architect community engagement

“How to use the Community Commitment Curve to architect community engagement” is a comprehensive session aimed at helping individuals and organizations create and sustain vibrant developer marketing communities.

The session will provide insights into the concept of the Community Commitment Curve, a strategic framework designed to map and optimize community engagement.

(Developer Marketing Alliance webinar, 11 Oct 2023)

A playbook for a successful developer community operations team

Shared lessons learned from years of hands-on experience in community building, including:

  • Defining “Community Operations”: Demystifying the role and establishing its significance within an organization.The core building blocks of a Community Operations team.
  • The power of data-informed decision-making for community strategy.
  • The Metrics That Matter: Identifying KPIs that go beyond vanity metrics to justify the existence, and impact, of a community program.
  • Actionable steps to build a high-performing Community Operations team

(DevRelCon London 2023Slides)

Leadership Lessons From A Team of Community Builders

Good managers are made, not born. It makes no difference for a team of community builders, with added complexities such as remote working, high burnout risk, unclear career path, etc. I’ll share my stories covering topics like hiring, setting a vision, building and tracking metrics, managing a remote team, keeping work-life in harmony, scaling, etc – while working in the context of a community team.

(Community Rebellion Conference, June 2023)

Slides, with a lot of speaker’s notes

Scaling communities through chapters

Alfredo Morresi and Van Riper have over a decade of experience at Google in developer relationship and community management. They will talk about their experiences in the context of the Google Developer Groups, a meta community program born in 2009 that has grown to 1,000+ chapters across 140 countries.

They discuss how to build a program at that scale with benefits for the company, benefits for the developer community, and benefits for the world.

(link to the video and transcript)

A Playbook for a Successful Community Operations Team

When a community program grows, it moves from a one-person band role, to a team of people, to a team of teams. And Community Operations is often one of the first teams formed. When to start one, and how to scale it? What are its key responsibilities? It’s just about data, dashboards and automations, or is there something more? In this session, I shared my best learnings in leading a dev community operations team in Google, the most embarrassing failures and “the road head”.

(CMX Summit, Sept 2022)

Here are the slides, with lot of info in the speaker’s notes too.