Starting over with HomeAssistant pt.2

This is part 2 of my homeassistant migration.
Here I’m showing how to put all the containers into one “stack” and how you can tackle specific things like the Shelly integration and notifications.
At a later stage I’ll also share some of my automation blueprints.

influxDB config

Homessistant normally only persists a few days of log data. To be able to really trace back events or use the internal graph engine (or grafana) for your dashboards, you probably want influxDB.
This is how you configure your instance connection:

#configuration.yaml
 
influxdb:
  api_version: 2
  ssl: false
  host: localhost # we're on another network
  port: 8086
  token: TOKEN
  organization: ORG
  bucket: homeassistant
  tags:
    source: HA
  tags_attributes:
    - friendly_name
  default_measurement: units

Combining: docker-compose

With these snippets, you can now create a complete “stack” for homeassistant, so it’s easier manageable. As you can see, a few of the services have to be in the host network or e.g. deCONZ won’t be able to send its values correctly to HA. Complete docker-compose file:

#configuration.yaml
version: '3.4'
 
services:
 
  homeassistant:
    container_name: homeassistant
    image: "ghcr.io/home-assistant/raspberrypi4-homeassistant:stable"
    volumes:
      - "${LOCAL_BASE_PATH}/homeassistant:/config"
      - "/etc/localtime:/etc/localtime:ro"
    restart: unless-stopped
    privileged: true
    network_mode: host
 
  mosquitto:
    container_name: mosquitto
    image: "eclipse-mosquitto"
    ports:
      - "1883:1883"
      - "9001:9001"
    volumes:
      - "${LOCAL_BASE_PATH}/mosquitto:/mosquitto"
      - "${LOCAL_BASE_PATH}/mosquitto/data:/mosquitto/data"
      - "${LOCAL_BASE_PATH}/mosquitto/log:/mosquitto/log"
    restart: unless-stopped
    network_mode: host
 
  influxdb:
    image: influxdb:2.1.1
    container_name: influxdb
    environment:
      - "DOCKER_INFLUXDB_INIT_MODE=setup"
      - "DOCKER_INFLUXDB_INIT_USERNAME=${DOCKER_INFLUXDB_INIT_USERNAME:-homeassistant}"
      - "DOCKER_INFLUXDB_INIT_PASSWORD=${DOCKER_INFLUXDB_INIT_PASSWORD:-homeassistant}"
      - "DOCKER_INFLUXDB_INIT_ORG=${DOCKER_INFLUXDB_INIT_ORG:-home}"
      - "DOCKER_INFLUXDB_INIT_BUCKET=${DOCKER_INFLUXDB_INIT_BUCKET:-homeassistant}"
    ports:
      - "8086:8086"
    volumes:
      - "${LOCAL_BASE_PATH}/influxdb/data:/var/lib/influxdb2"
      - "${LOCAL_BASE_PATH}/influxdb/config.yml:/etc/influxdb2/config.yml"
    restart: unless-stopped
 
  deconz:
    image: deconzcommunity/deconz
    container_name: deconz
    restart: unless-stopped
    privileged: true
    ports: 
      - "8085:8085"
      - "4435:4435"
    volumes:
      - "${LOCAL_BASE_PATH}/deconz:/opt/deCONZ"
    devices:
      - "${DECONZ_USB_DEVICE:-/dev/ttyACM0}"
    environment:
      - "TZ=Europe/Berlin"
      - "DECONZ_WEB_PORT=8085"
      - "DECONZ_WS_PORT=4435"
      - "DEBUG_INFO=1"
      - "DEBUG_APS=0"
      - "DEBUG_ZCL=0"
      - "DEBUG_ZDP=0"
      - "DEBUG_OTAU=0"
      - "DECONZ_DEVICE=${DECONZ_USB_DEVICE:-/dev/ttyACM0}"
      - "DECONZ_VNC_MODE=1"
      - "DECONZ_VNC_PORT=5900"
    network_mode: host

And the according .env:

# .env
LOCAL_BASE_PATH=/home/ubuntu
DECONZ_USB_DEVICE=/dev/ttyACM0
DOCKER_INFLUXDB_INIT_USERNAME=homeassistant
DOCKER_INFLUXDB_INIT_PASSWORD=PASSWORD
DOCKER_INFLUXDB_INIT_ORG=home
DOCKER_INFLUXDB_INIT_BUCKET=homeassistant
DOCKER_INFLUXDB_INIT_RETENTION=forever
DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=TOKEN
DOCKER_INFLUXDB_INIT_MODE=setup

deCONZ integration

As you have seen in the docker-compose file, deCONZ is on the host network. It makes it substantially easier with the webservice communication. Since deCONZ or more precisely, the Phoscon app, stores its configuration internally, this should be relatively seamless. For security reasons, best create a config backup before you switch. For me, it proved best, to first plug in the ConBee II stick while the Pi was powered down.
After booting, it was correctly found - and the container could pick it up correctly.

Note: The device that’s handed through to the container is /dev/ttyACM0 by default.
If all went well, you should see all your previous devices within the Phoscon app. And as soon as you enabled the integration in homeassistant, all devices will be also available there.
Also here: Name your devices in a sensible manner!

Shelly integration

If you have a lot of Shelly devices like me, make sure, all have the latest firmware or they won’t all show up.
Also it is important for older devices that you check that

Internet & Security -> Advanced Developer-Settings -> CoIoT protocol

is enabled. Otherwise the devices might also not show up for integration.
Afterwards, if activated, the Shelly integration offers you all devices that are available on the network. You still need to configure each one separately and I strongly suggest to name them while adding or you’ll lose track pretty fast.

Overview of my current integrations

As you can see in the picture below, I have quite a collection of devices. So it is very important to keep naming things consistently.

Integrations

Pushing alerts or messages

For me it’s normally pushover, since the API is quite nice (token based auth, direct https requests) and I am already using it all over the place with a bash wrapper.
So, imagine you want to know if someone opened/closed your front door, or movement in your kitchen while you are gone and nobody is supposed to be home.
How to integrate Pushover is extensively documented here and it works absolutely fine.
I’ll later add some implementation scenarios together with my lighting triggers in Part 3. A general usage for the “notify” service can be found here.

This is a short example for your local config, including also slack:

# configuration.yaml
notify:
 
  - name: pushover
    platform: pushover
    api_key: API_KEY
    user_key: USER_KEY
 
  - name: slack_debug 
    platform: slack
    api_key: SLACK_API_KEY
    default_channel: "#debug"

Will continue in part 3 :-)

part 1 | part 2 | part 3 #programminghomeassistant automation

aschmann.dev

Explorer