Home assistant is very powerful – possessing a great deal of flexibility both in terms of what can be monitored and how the monitored state is displayed. Much of the display flexibility comes through a combination of the Jinja templating engine and custom components.

Here is one example of this flexibility in action: display a dynamic list of sensors, coloring the status LED differently depending on the sensor state. Or more specifically: the ping status for a set of devices – in this case the ping status of all my raspberry pi cameras.

To display a dynamic list of sensors I first helped myself by giving my devices a consistent name prefix – e.g. “pi-cam-X” where X is the instance. I then installed the wonderful auto-entities plugin and specified an inclusion filter of “/pi-cam/”

Next to perform the styling I download the template-entity-row plugin – which allows applying a template to each entity row. The card yaml is actually fairly compact and readable:

type: custom:auto-entities
card:
  type: entities
filter:
  include:
    - name: /pi-cam/
      options:
        style: |
          :host {
            --card-mod-icon-color: {{ 'rgb(221,54,58)' if is_state('this.entity_id','off')  else 'rgb(67,212,58)' }};
          }
        type: custom:template-entity-row
        icon: mdi:circle
        state: >-
          {% if is_state('this.entity_id','off') %} Down {% else  %} Up {% endif %}

To be honest it took way longer to accept that this kind of flexibility was not available out of the box – it is too bad some of these add-ons are not just core to HA as they seem like core functionality.

The “out of the box” display is on the left. The ostensibly-improved status is on the right. Note that in truth i dont see a huge need for displaying textually what the red/green LED shows, however I much prefer “Up/Down” to “Connected/Disconnected”..

As described on their official MQTT Auto Discovery page, Home Assistant allows one to create sensors on the fly. This is particularly important if you are, say, trying to add some non-trivial number of devices that speak MQTT.

I saw a lot of posts about people struggling to get this working. I too had a few issues and felt it worth stating my take on it. Spoiler alert: HA MQTT auto discovery works perfectly, so long as you get over some of the setup nuances. I thought I’d document these for posterity:

• If you added MQTT support through the GUI, auto discovery is set to false by default. There doesn’t appear to be any way to fix this through the GUI. If you then add MQTT to your configuration yaml, the GUI config overrides it! The only way to overcome this is to delete MQTT from the GUI and then add it in the configuration yaml, restart HA, etc..
• To publish a value there is a two step process
  1. Publish to the configuration topic to define the sensor. The concept of how this works is well documented on the main link given above – however it is important to note that you do NOT have to provide the configuration for all values in a entity with multiple values. This is actually a nice feature – and works so long as you always publish the config before sending the value. It was not clear to me (and i didnt investigate) if there was any good way to minimize the need to broadcast configurations; e.g. how do you know HA saw your config before you send state? To be safe i just publish the config and state one after another everytime. This doesnt seem optimal but it works.
  2. Publish the state via the state topic passed in during the config publish. The only thing to note here is that, unfortunately, it does not appear that values get rooted under the objectid you provide. Insted they are placed under a sensor with the name you provide – seemingly HA completely ignores the objectid…

Otherwise this feature works very well. Some tips I found for debugging this:

• Enabling logging on mqtt works well. To do this add to configuration.yaml:

logger:
  default: warning
  logs:
    homeassistant.components.mqtt: debug

You can then tail (if under docker) config/home-assistant.log

• Using the “Publish a packet” or “Listen to a topic” pages under MQTT->configure (in the HA configuration->integrations page) is good for eliminating any client broker issues you might see
• Additionally, if you are using eclipse-mosquitto as your mqtt server, you can directly view (HA aside) publishes. In docker it would be:

docker exec -it <mosquittodockerid> /bin/sh
mosquitto_sub -u user -P pass -h localhost -t topic

Where “topic” above is whatever you are publishing, e.g. “homeassistant/sensor/grinch/state”

Lastly, in looking for a good c++ mqtt client, I tried paho and mosquitto. I found mosquitto worked best – both for the server (which i run in a docker) and c++ client. My decision was based on this simple requirement: the library should build (paho failed), work with c++11 (other, albeit cool-looking, c++ libraries required c++14), and be easy. Mosquitto fit the bill perfectly. I am sure – perhaps – there could be other libraries that might work as well – i just never found them.