Hello and welcome again to another Home Assistant dashboard breakdown! Hopefully you'll enjoy this post and possibly be able to grab a few bits for your own HA setup! Lets delve in ...

Home Assistant System

The first column on the System dashboard shows details and stats for Home Assistant itself. The very first element shows HA uptime, version, last successful login and updates available in Supervisor (add-on store)

Uptime

To show the uptime of HA, I've created a sensor using the setup shown below. Once added, this will create a sensor called sensor.hassio_uptime.

sensor:
    platform: uptime
    name: Hassio Uptime
    unit_of_measurement: minutes

Version

This sensor will display the current version of HA, another simple sensor setup which will create sensor.latest_version.

sensor:
    platform: version
    source: hassio

Last Login

This sensor will display the last successful login including username and IP address. Handy if you've got several users or exposing HA over the internet (hopefully securely some how!). It creates a sensor called sensor.last_successful_authentication.

sensor:
    platform: authenticated

Updates

This sensor displays any pending updates within Supervisor (add-on store) by using the 'command line' platform. The sensor name for this one is sensor.supervisor_updates.

  platform: command_line
  name: Supervisor updates
  command: 'curl http://supervisor/supervisor/info -H "Authorization: Bearer $(printenv SUPERVISOR_TOKEN)" | jq ''{"newest_version":.data.version_latest,"current_version":.data.version,"addons":[.data.addons[] | select(.version != .installed)]}'''
  value_template: "{{ value_json.addons | length }}"
  json_attributes:
  - newest_version
  - current_version
  - addons

Once these are all setup, you can bundle them into an Glance card and display them like below ...

Host Stats

The next card down on the list shows the host system details for CPU, RAM and disk space. The sensor to pull this information uses the 'systemmonitor' platform which can also grab other details such as last boot time, network information and other CPU and RAM figures.

sensor:
    platform: systemmonitor
    resources:
          - type: disk_use_percent
            arg: /home
          - type: memory_use_percent
          - type: memory_use
          - type: swap_use
          - type: swap_free
          - type: swap_use_percent
          - type: load_1m
          - type: load_5m
          - type: load_15m
          - type: memory_free
          - type: last_boot
          - type: processor_use
          - type: network_in
            arg: eth0
          - type: network_out
            arg: eth0
          - type: ipv4_address
            arg: eth0
          - type: throughput_network_in
            arg: eth0
          - type: throughput_network_out
            arg: eth0
          - type: processor_use

In this element I've used the 'custom:mini-graph-card' in a 'horizontal-stack' card to display these details in a nice and clean graph format.

cards:
  - align_icon: left
    align_state: center
    entities:
      - sensor.processor_use
    font_size: 75
    icon: 'mdi:chip'
    name: CPU
    show:
      fill: false
    type: 'custom:mini-graph-card'
  - align_icon: left
    align_state: center
    entities:
      - sensor.memory_use_percent
    font_size: 75
    name: Memory
    show:
      fill: false
    type: 'custom:mini-graph-card'
  - align_icon: left
    align_state: center
    entities:
      - sensor.disk_use_percent_home
    font_size: 75
    name: Disk
    show:
      fill: false
    type: 'custom:mini-graph-card'
type: horizontal-stack

Count Sensor

This element doesn't display anything 'system critical' like the others, however it's more of an 'informational' card to show the amount of sensors, switches, automation etc that you currently have in HA. Another sensor setup using the following configuration below ...

sensor:
    platform: template
    sensors:
    #----- Count Automations
      count_automations:
        entity_id: sensor.date
        value_template: "{{ states.automation | list | length }}"
    #----- Count Scripts
      count_scripts:
        entity_id: sensor.date
        value_template: "{{ states.script| list | length }}"
    #----- Count Device Trackers
      count_device_trackers:
        entity_id: sensor.date
        value_template: "{{ states.device_tracker | list | length }}"
    #----- Count Binary Sensors
      count_binary_sensors:
        entity_id: sensor.date
        value_template: "{{ states.binary_sensor| list | length }}"
    #----- Count Sensors
      count_sensors:
        entity_id: sensor.date
        value_template: "{{ states.sensor | list | length }}"
    #----- Count Switches
      count_switches:
        entity_id: sensor.date
        value_template: "{{ states.switch | list | length }}"
    #----- Count Zones
      count_zones:
        entity_id: sensor.date
        value_template: "{{ states.zone | list | length }}"
    #----- Input Booleans
      count_input_booleans:
        entity_id: sensor.date
        value_template: "{{ states.input_boolean | list | length }}"
    #----- Input Numbers
      count_input_numbers:
        entity_id: sensor.date
        value_template: "{{ states.input_number | list | length }}"
    #----- Input Texts
      count_input_texts:
        entity_id: sensor.date
        value_template: "{{ states.input_text | list | length }}"
    #----- Input Selects
      count_input_selects:
        entity_id: sensor.date
        value_template: "{{ states.input_select | list | length }}"
    #----- Input Date Times
      count_input_datetimes:
        entity_id: sensor.date
        value_template: "{{ states.input_datetime | list | length }}"

Docker Stats

If you have HA in Docker or other applications which you want to monitor in HA, this component will pull the stats for these and provide handy details such as container status (running, paused, stopped), uptime etc. This requires the use of a custom component called 'monitor_docker' which you can easily grab via HACS or manually install into your 'custom_components' folder. Once added/installed, you need to add the following configuration as mentioned below and on their GitHub page here. You will need to amend the config below to include your Docker URL (url:) and list the containers you want to monitor.

monitor_docker:
  - name: HASS Docker
    url: !secret monitor_docker_HASS
    containers:    
      - homeassistant
      - addon_core_configurator
      - addon_core_ssh
      - hassio_multicast
      - hassio_cli
      - hassio_audio
      - hassio_dns
      - hassio_supervisor
      - Portainer
    monitored_conditions:
      - version
      - containers_total
      - containers_running
      - containers_paused
      - containers_stopped
      - containers_cpu_percentage
      - containers_memory
      - containers_memory_percentage
      - images
      - status
      - uptime
      - image
      - cpu_percentage
      - memory
      - memory_percentage
      - network_speed_up
      - network_speed_down
      - network_total_up
      - network_total_down      

It is worth mentioning that I couldn't get this to work until I made a change to the Docker service file (/lib/systemd/system/docker.service) and included the following line at the end of ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock to include -H tcp://0.0.0.0. The end results looks like this ...

[Unit]
Description=Docker Application Container Engine
Documentation=https://docs.docker.com
BindsTo=containerd.service
After=network-online.target firewalld.service containerd.service
Wants=network-online.target
Requires=docker.socket

[Service]
Type=notify
# the default is not to use systemd for cgroups because the delegate issues still
# exists and systemd currently does not support the cgroup feature set required
# for containers run by docker
ExecStart=/usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock -H tcp://0.0.0.0
ExecReload=/bin/kill -s HUP $MAINPID
TimeoutSec=0
RestartSec=2
Restart=always

...

Once that has been amended (if required) and the 'monitor_docker' component has been setup, you should see several sensors created for each container. For my dashboard, I've added the sensors in a Glance card and the end result looks like this ...

columns: 4
entities:
  - entity: sensor.hass_docker_containers_running
    name: Running
  - entity: sensor.hass_docker_containers_stopped
    name: Stopped
  - entity: sensor.hass_docker_hassio_supervisor_status
    name: Supervisor
  - entity: sensor.hass_docker_homeassistant_status
    name: Hassio
show_icon: true
show_name: true
show_state: true
title: false
type: glance

Restart Services

Last in the column is a card to allow easy access to restart several key services within HA without having to navigate through the Configuration panel. No extra config is needed to set this one up as it uses the existing 'reload' services within HA. Simply create a Glance card with the following details to get this up and running ...

entities:
  - entity: zone.home
    icon: 'mdi:home-assistant'
    name: Hassio
    tap_action:
      action: call-service
      service: homeassistant.restart
  - entity: zone.home
    icon: 'mdi:cogs'
    name: Automation
    tap_action:
      action: call-service
      service: automation.reload
  - entity: zone.home
    icon: 'mdi:script-text'
    name: Script
    tap_action:
      action: call-service
      service: script.reload
  - entity: zone.home
    icon: 'mdi:group'
    name: Groups
    tap_action:
      action: call-service
      service: group.reload
show_header_toggle: false
show_state: false  
title: false
type: glance

Sensor Network

As the title suggests, this column is dedicated to everything sensor related. To give you some context, I utilise three types of sensors to monitor shit such as temperature, door positions (open/closed), motion and all the other good stuff you need to keep tabs on your home. These comprise of Zigbee and 433Mhz sensors as well as WiFi devices.

Sensor Gateway/Hubs

The first element in this column shows the current status of the main sensor gateway/hub for each type of network. The Zigbee and 433Mhz gateways/hubs run on separate devices to where HA lives, Zigbee on its own Raspberry Pi (using Conbee II dongle) and 433Mhz running off a Sonoff RF bridge. I've included ESPHome in this panel as I have several devices (ESP8266's) running through this service as well which run 'semi-critical' sensors. And last to mention is WiFi which I also have a fair few devices connected also (who doesn't?).

I've already created a blog post around how to setup this element which you can find here but to give you a gist, it uses a command line sensor to ping the port each application sits on and determine whether it's up (online) or down (offline).

Sensors (In General)

This second card on the list displays the current status of the sensors themselves. These comprise of the 6 main sensor types I have around the house, Door/Window, PIR, Lights, Temperature sensors, a few 433Mhz sensors and IP cameras. The way of monitoring these is quite tricky so I've had to come up with my own solution on how to do this.

Let me try and explain ... Some of these sensors (if not most) are either connected via Zigbee or 433Mhz RF. Unlike there WiFi counterparts, these do not have a 'constant connection' and simple ping the gateway/hub once activated or triggered. With WiFi, a device is always (hopefully) connected to a wireless network so it's easy to determine whether its online or offline. The solution I've had to put in place for Zigbee and 433Mhz RF sensors is unfortunately not real-time monitoring but a 'regular check-up' sort of procedure.

Using binary sensor templates, a group and sensor templates, I've setup individual rules for each sensor to determine if it has been activated or triggered within a certain period of time. If it hasn't then I can roughly determine that there is an issue with the sensor (battery dead or out of signal range) and set the status to 'possibly offline'.

To give an example ... I expect that my First Floor PIR sensor to be triggered at least a few times during the day (unless I'm on holiday) so I can create a rule to say 'if First Floor PIR hasn't been triggered (state changed) within 13 hours' then set the status to 'possibly offline'. Make sense? Of course this requires individual rules being setup for each sensor however it is the only solution I can think of to get around the issue.

So ... It took a lot of time and head banging but here is how I managed to conjure this shit up. Firstly a binary sensor template is created for each sensor in order to figure out the time value of when it last triggered or activated. A bit of a ball ache depending on how many sensors you have but it goes a little something like this ...

platform: template
sensors:
## Door/Windows - Back Door
  sensor_check_dws_back_door_no_activity:
    entity_id: sensor.time
    value_template: >
      {{ (now().timestamp() - as_timestamp(states.binary_sensor.openclose_19.last_changed)) | int //60 > 780 }}

In this example I've given the new sensor a name of sensor_check_dws_back_door_no_activity and then stated the binary sensor in question (binary_sensor.openclose_19) and finally how long to check before it's deemed as offline (60 > 780 which equates to 13 hours - 780 minutes). You can change this to what you see fit, for example I have used 60 > 5760 (4 days) for my letterbox sensor as I don't receive mail every day. Once you've gone through and setup each sensor its now time to group them depending on type. I've gone and created a few groups such as Door/Window contact sensor, PIRs, Lights, Temperature sensors, 433Mhz sensors (letterbox contact and doorbell) and ones for my UniFi UVC cameras.

The next part is now to parse that value into a certain format as the sensor/group created above will either give a 'on' or 'off' value depending on if the timing rule has been triggered.

Ideally we want to determine how many sensors within the group are 'possibly offline'. In order to do this we need to create a new sensor template and perform some clever formatting to display the group values into either a count, percentage or 'xx out of xx' (7/11 for example) format. I'm not going to pretend I know exactly what is going on in the config below, but this shit works ...

  platform: template
  sensors:
    dws_sensor_check_status_array:
      entity_id:
        - group.dws_sensor_check
      value_template: >-
        [{%- for e in state_attr('group.dws_sensor_check', 'entity_id') %}
          {% if loop.first %}{% else %},{% endif %}
          {%- if states(e)|lower == 'on' %}0{% else %}1{% endif -%}
        {%- endfor -%}]
    dws_sensor_check_status_on:
      entity_id:
        - sensor.dws_sensor_check_status_array
      icon_template: 'mdi:door-open'
      unit_of_measurement: count
      friendly_name: DWS Sensors Online
      value_template: >-
        {{ states('sensor.dws_sensor_check_status_array')|from_json|sum }}
    dws_sensor_check_status_count:
      entity_id:
        - sensor.dws_sensor_check_status_array
      icon_template: 'mdi:door-open'
      friendly_name: DWS Sensors Count
      unit_of_measurement: count
      value_template: >-
        {{ states('sensor.dws_sensor_check_status_array')|from_json|length }}
    dws_sensor_check_status_percent:
      entity_id:
        - sensor.dws_sensor_check_status_on
        - sensor.dws_sensor_check_status_count
      friendly_name: DWS Sensors Online
      icon_template: 'mdi:door-open'
      unit_of_measurement: '%'
      value_template: >-
        {{ '%0.1f' | format(states('sensor.dws_sensor_check_status_on')|float / states('sensor.dws_sensor_check_status_count')|float * 100.0) }}
    dws_sensor_check_status:
      entity_id:
        - sensor.dws_sensor_check_status_percent
      friendly_name: DWS Sensors Online
      icon_template: 'mdi:door-open'
      value_template: >-
        {{ states('sensor.dws_sensor_check_status_on') -}}/{{-  states('sensor.dws_sensor_check_status_count') -}}

There are a few bits you'll need to amend in this sensor for your setup. Firstly you'll need to name the new sensor, in this case I've chosen dws_sensor_check_status_array (DoorWindowSensor_sensor_check...). It's probably best to keep the same sort of naming format through this config as you can easily get lost. Underneath that you'll need to include the previously created group for the type of sensor (group.dws_sensor_check in this example) and also within the value_template statement. From there on it's a matter of renaming each new sensor type and referring to each when needed in the config below it. Once you've done all of that and restarted HA, you should end up with a sensor for each type (..._sensor_check_status, _sensor_check_status_countand _sensor_check_status_percent)

When you've managed to do this for all of your different types of sensors, add them into a Glance card and it should look something like below ...

Sensors

When I first created this dashboard I wanted a way of showing all the sensors currently in HA. However, due to the sheer amount of them, it became an absolute mess trying to display them so I ended up with two bits for this one. The first part is a search box where I'm able to quickly search for any and all sensors in HA and the second shows the most recent sensors to be triggered or activated.

The search box is a relatively easy setup by using the 'custom:search-card' to display an input field where anything can be looked up quickly. At the moment this means anything in HA (including non-sensors) however as mentioned on their GitHub page, the creators are looking to include an 'Exclude Domain' feature so I'll be able to limit this down to simply 'sensors'

entity_id:
  '1': null
max_results: 15
name: 'Toggle {1}'
service: homeassistant.toggle
search_text: Seach for Sensors
service_data: null
type: 'custom:search-card'

The second part is the 'recently triggered' sensors card which I've setup using 'custom:auto-entities'. As you may have noticed, there are two sensors which are being displayed as I've chosen to display PIR and Door/Window sensors. These are basically two 'custom:auto-entities' cards in a 'custom:vertical-stack-in-card' card to show them on top of each other. In order to only display either PIR or Door/Window sensor, I've included an 'include and 'exclude' filter for each. As most of the binary sensors have the same naming convention, I've been able to use a wildcard option in the filter, for example binary_sensor.*motion*. Including the secondary_info: last-changed under options: will also show the timing of when that sensor last triggered.

cards:
  - card:
      type: entities
    filter:
      include:
        - entity_id: binary_sensor.*motion*
          options:
            secondary_info: last-changed
      exclude:
        - entity_id: binary_sensor.motion_swk_cr_uniuvc*
    sort:
      count: 1
      method: last_changed
    type: 'custom:auto-entities'
  - card:
      show_icon: false
      type: entities
    filter:
      include:
        - entity_id: binary_sensor.openclose_*
          options:
            secondary_info: last-changed
        - entity_id: binary_sensor.window_*
          options:
            secondary_info: last-changed
    sort:
      count: 1
      method: last_changed
    type: 'custom:auto-entities'
title: false
type: 'custom:vertical-stack-in-card'

The end result should look something like this ...

Battery Levels

The last element in this column is to display the current battery levels for Zigbee sensors. This card uses the 'custom:battery-state-card' and is setup like so ...

collapse: 3
entities:
  - sensor.back_door_battery_level
...
...
...
  - sensor.window_door_sensor_5_battery_level
sort_by_level: asc
title: false
type: 'custom:battery-state-card'

There are a fair few options to fiddle around with so check out their GitHub page here for more details. For now I've simply limited the number of entities to 3 (collapse: 3) and sorted them by lowest value first (sort_by_level: asc).

UniFi Network

Another give away in the title, this column is all about my UniFi network devices (and Pi-Hole at the bottom). At a later date I may end up moving this to its own dashboard but for now it lives here as it would look a bit sparse on its own page.

Device Status

The first element is an easy one, it basically shows the current status of UniFi devices I have and whether they are connected or not. To be honest, if any of them were offline (apart from AP and Protect) I'd probably not be able to access HA anyway! A simple setup, each device has been setup as a binary ping sensor and then added to a Glance card. Its worthing mentioning that in order to get the 'Online/Offline' status, I've also created sensor templates to correct the values (previously 'on' which displayed the state 'Connected').

UniFi USG Stats

The next element in the UniFi Network column shows the current stats for my UniFi USG such as CPU, RAM and Network Traffic. At this time I can only find a custom component for the USG as I'd also like to monitor similar details for my CloudKey Gen2+ and 16 Port Switch but this will have to do for now! To achieve this a custom component is required which I grabbed from here called 'sensor.unifigateway'. Once installed and configured, it creates a bunch of sensors for different values such as WAN IP, CPU, Firmware updates as well as others. In my setup I've simply chosen CPU, RAM and Network Traffic. Using the good old 'custom:mini-graph-card' I've added these details in a horizontal stack and displayed like so ...

Network Stats

Third on the list is a simple card to display my current network details such as Local and External IP as well as SpeedTest results. To create a Local IP sensor, pop over to the Integrations page and search for 'Local IP'. Add that and you'll have a new sensor called 'sensor.local_ip'. To display your WAN (external) IP address, create a new sensor with platform: dnsip. Again once added it'll spit out a new sensor called 'sensor.myip'. And finally, to get SpeedTest results, head over the Integrations page and search for 'SpeedTest.net'. This will create three new sensors, one for 'Download', 'Upload' and 'Ping'. Now place them in an entities card and you'll have something like this ...

Pi-Hole

And we're nearly done! The very last element on this dashboard is for Pi-Hole. This is another one which is setup via the Integrations page. Head over there and search for 'Pi-Hole'. Once added, as usual, it'll provide you with a bunch of new sensors. In my case I've a chosen to display a button to enable/disable Pi-Hole and also the amount of Request and Domains blocked. For the button I've  used a 'custom:button-card' as I found the normal HA button card looked a bit shite and wouldn't align properly next to the Glance card (all setup using a horizontal stack). I've copied over an existing 'custom:button-card' setup from my Lights dashboard and tweaked a few options ...

entity: switch.pi_hole
icon: 'mdi:pi-hole'
name: Pi-Hole
state:
  - icon: 'mdi:pi-hole'
    name: Disabled
    styles:
      card:
        - height: 130px
        - width: 100px
      icon:
        - width: 55%
        - opacity: 0.2
      name:
        - padding: 0px 10px 15px
        - font-size: 15px
        - text-overflow: unset
        - white-space: unset
        - word-break: break-word
    value: 'off'
  - color: white
    icon: 'mdi:pi-hole'
    operator: default
    name: Enabled
    styles:
      card:
        - height: 130px
        - width: 100px
      icon:
        - width: 55%
        - opacity: 0.9
      name:
        - padding: 0px 10px 15px
        - font-size: 15px
        - font-weight: bold
        - text-overflow: unset
        - white-space: unset
        - word-break: break-word
type: 'custom:button-card'

This config essentially allows me to change the appearance of the card depending on if Pi-Hole is either on or off. When Pi-Hole is disabled, the label will change to 'Disabled' as well 'greying' out the icon using the opacity: 0.2 option. The opposite goes for the Pi-Hole is enabled. Finally I created another card (Glance) in the horizontal stack to show the amount of blocked Domain and DNS requests. The end result is like so ...

Huzzah! Another Home Assistant dashboard breakdown completed! If you've not seen my previous post for my Media dashboard, either head back to my blog home page or if you're lazy, click here.

Thanks again for all the responses and comments I've received on Reddit and Facebook! Please don't hesistate to drop me a message with any questions or queries as I'm always happy to help where I can!

As usual, if you like what you've read and want to support me in creating more content, you can 'Buy me a Beer' here: 🍺Buy me a Beer!

Many thanks!