How to create a sensor with hostname of host running Home Asisstant (HAOS)

Configuration
, ,
1

Hello everyone,

tl;dr: If you are just looking for a way to create a sensor with the hostname in a HAOS installation, jump directly to the solution

Background

I am in the process of building a test system and a strategy to update it regularly. I probably won’t be able to automate this process completely and there are a few things to consider so that the productive system and the test system don’t interfere with each other later, but that’s not the topic of my post. Rather, I had the idea of creating a sensor with the host name of the system on which Home Assistant is running, e.g. to insert it as a condition for critical automations and in node red flows or to visually emphasise on the dashboard that it is a test system. Apart from a feature request and a similar post, both are quite old, I couldn’t find anything about it and the proposed solution didn’t satisfy me. So I tried to find a solution myself. My first approach was to implement this via a command_line sensor, but I had to realise that commands that work in the SSH addon do not necessarily also work with the command_line sensor, because they are executed in the Home Assistant container and the feature set is significantly limited compared to the SSH addon. This is where the following command, which I found in this article, came into play and made testing much easier:

docker exec -it homeassistant bash

Executed on the console or in Advanced SSH Addon terminal with protection mode disabled, commands can then be tested in the same context as Home Assistant. But even that didn’t get me any further at first:

  • hostname returns only the Home Assistant Docker hostname, which is always homeassistant.
  • hostnamectl command is not available.
  • ha host info | grep ^hostname | awk "{print $2}" does not work because the HA CLI is not available in the Home Assistant container.

Then I thought of the Supervisor API, which can be used to get the hostname via the /info endpoint, for example. It is possible to call the API from within a container via the alias supervisor. The required authorisation token is available as a system variable named SUPERVISOR_TOKEN, so that a universal sensor can be created without hard coding anything. I have tested two ways of doing this successfully, whereby the rest variant looks somehow cleaner.

Solution

Here are two ways of creating a hostname sensor leveraging the Supervisor API:

command_line:
  - sensor:
      name: Hostname
      command: >
        curl -s -H "Authorization: Bearer $SUPERVISOR_TOKEN" -H "Content-Type: application/json" http://supervisor/info | jq -r .data.hostname.data.hostname
      scan_interval: 3600
      unique_id: supervisor_hostname

rest:
  - resource: http://supervisor/info
    method: GET
    headers:
      Authorization: !env_var SUPERVISOR_TOKEN
      Content-Type: application/json
    scan_interval: 3600
    sensor:
      - name: Hostname_rest
        value_template: "{{ value_json.data.hostname }}"
        unique_id: supervisor_hostname_rest

Here’s a screenshot of the sensors after restoring a backup to a different host:

grafik
grafik1047×278 16.4 KB

Even though there may exist other and better approaches out there, I think this is a pretty neat, universal and easy-to-implement approach that should work with all API endpoints. Incidentally, I have learnt a lot about ssh, authorized_keys, how Home Assistant works under Docker, what works and what does not. In any case, it works very well for me and maybe this will help someone else, too.

2

I made a mistake in the original post but cannot edit it anymore. The correct jq command for the command_line sensor is as follows:

curl -s -H "Authorization: Bearer $SUPERVISOR_TOKEN" -H "Content-Type: application/json" http://supervisor/info | jq -r .data.hostname