Dank zahlreicher Integrationsmöglichkeiten ist Home-Assistant eine einfache Plattform für das Steuern verschiedenster Smart-Home Geräte. Im Vergleich zu ioBroker ist mir der Start mit Home Assistant wesentlich einfacher gefallen. Während ich für ioBroker noch am Suchen war, welches Frontend ich für meine Dashboards verwenden könnte, hatte ich mit Home-Assistant out of the box ein fertig eingerichtetes System. Die Lovelance Dashboards von Home Assistant können einfach in der GUI zusammengeklickt und für spezielle Anpassungen im Code Editor und mit zusätzlichen Frontend-Paketen nahezu beliebig adaptiert werden.

Ich verwende Home-Assistant primär für das Steuern bestimmter Lampen oder der Markise über das Smartphone. Zudem überwache ich damit die Temperatur und Luftfeuchtigkeit von bestimmten Räumen, meine Heizung, die Haustüre, eine NAS und einen Webserver. Außerdem habe ich auf Basis eines alten Smartphones sowas wie eine Wetterstation an die Wand gehängt. Darauf kann ich jetzt als Beispiel den Temperaturverlauf, das Wetter oder andere Werte im Vorbeigehen begutachten oder bestimmte Aktionen darauf starten.

Home-Assistant – Docker Inbetriebnahme

Um Home-Assistant in Docker zu starten, wird natürlich ein Docker-Setup vorausgesetzt, siehe: Docker. Wer Docker bereits eingerichtet hat, kann Home-Assistant mit folgendem Befehl starten:

docker run -d --name="home-assistant" \
-v ha:/config \
-v /etc/localtime:/etc/localtime:ro \
--net=host \
--restart=always \
homeassistant/home-assistant:stable

Das Netzwerk für Home-Assistant muss laut dem Hersteller auf „--net=host" gestellt werden, die verwendeten Ports können aber auch definiert werden: als Beispiel bei Verwendung eines Reverse-Proxys für den Zugriff aus dem Internet, siehe:  Zugriff aus dem Internet - SSL Let's Encrypt.

Erster Start: Initiale Konfiguration

Nach dem Start des Containers ist Home-Assistant standardmäßig mit der IP-Adresse des Host und dem Port 8123 im Browser erreichbar:

Wer Docker auf demselben Rechner ausführt, kann auch http://localhost:8123 für den Aufruf verwenden, siehe localhost aufrufen: IP Adresse „127.0.0.1“, „::1“ | was ist localhost?

Geräte und Sensoren können in HomeAssistant über sogenannte Integrationen hinzugefügt werden:

Integrationen

ZigBee Integration mit dem ConBee 2 USB-Stick: 3 mögliche Installationsvarianten:

Damit ich meine ZigBee-Geräte über Home-Assistant steuern kann, verwende ich einen ConBee II USB-Stick. Informationen zum Setup, siehe: Conbee 2: Phoscon deCONZ - Docker Inbetriebnahme | Review. Ursprünglich habe ich die Herstellersoftware des ConBee 2 Sticks verwendet: deCONZ mit der grafischen Oberfläche Phoscon.

Alternativ kann ConBee 2 aber auch direkt in Home Assistant eingebunden werden und als dritte Möglichkeit über Zigbee2MQTT. Mit den letzten beiden Varianten kann auch ein günstigerer ZigBee-Adapter, als Beispiel: CC2652 oder CC1352 verwendet werden. Beim Wechsel von einer Variante zur anderen müssen die Endgeräte neu verbunden werden. Ich habe ca. ein Jahr deCONZ eingesetzt und das Setup dann auf Zigbee2MQTT geändert, was aus jetziger Sicht auch meine Empfehlung ist.

1) ConBee 2 Hersteller-Software: deCONZ / Phoscon

Wer ConBee und Phoscon bereits im Einsatz hat, muss als Vorbereitung für die Verbindung von Home Assistant das Phoscon-GW auf „App verbinden“ stellen:

Über die Benachrichtigung meldet Home-Assistant bereits das erkannte deCONZ-Setup: 

Alternativ kann die Integration auch im Menüpunkt Konfiguration hinzugefügt werden: 

Details siehe, https://www.home-assistant.io/integrations/deconz/

2) Zugriff auf ConBee 2, direkt aus Home Assistant (Zigbee Home Automation: ZHA)

Alternativ zur Anbindung des ConBee-Sticks über das deCONZ Zigbee Gateway, kann der Stick auch direkt in Home Assistant eingebunden werden, dazu muss Home-Assistant, wie auch der deCONZ-Container, mit dem Parameter „--device“ gestartet werden:

docker run -d --name="home-assistant" \
-v ha:/config \
-v /etc/localtime:/etc/localtime:ro \
--net=host \
--restart=always \
--device=/dev/ttyACM0 \
homeassistant/home-assistant:stable

Geräte die zuvor in deCONZ eingebunden wurden, könne an dieser Stelle nicht weiter verwendet werden, sie müssen erneut verbunden werden:

Eine weitere Alternative zu deCONZ und ZHA stellt Zigbee2MQTT dar:

3) Unabhängige Lösung: Zigbee2MQTT

Zigbee2MQTT ist eine Zigbee-Bridge für die Kommunikation zwischen Zigbee und einem MQTT-Broker. Das Setup mit HomeAssistant besteht dabei aus drei Komponenten:

• HomeAssistant 
• MQTT - Broker
• Zigbee2MQTT

In Home-Assistant kann MQTT in den Integrationen hinzugefügt werden:

Siehe: MQTT - Broker : Docker Setup, bzw. mein komplettes Docker Compose-Setup: Zigbee2MQTT- docker-compose.yml.

Im Vergleich zu Phoscon, siehe: Zigbee2MQTT vs deCONZ und Phoscon

System Monitor

Um das Betriebssystem - auf dem Home Assistant läuft - rudimentär zu überwachen, können in der configuration.yaml zusätzliche Sensoren hinzugefügt werden, als Beispiel Disk und Memory:

configuraton.yaml:

sensor:
  - platform: systemmonitor
    resources:
      - type: disk_use_percent
        arg: /
      - type: disk_use_percent
        arg: /daten
      - type: memory_free    

Server oder Linux-Systeme überwachen

Wer den Status anderer Linux-Systeme überwachen will, kann dazu die Integration „Glances“ verwenden. Glances sammelt Daten zu CPU, Memory oder dem freien Speicherplatz einer Festplatte u.v.m.. Als Voraussetzung muss Glances zuvor auf den zu überwachenden Systemen installiert werden, siehe auch:  Glances - Linux-Server überwachen

Template-Sensor

Mit einem Template-Sensor können Sensoren auf Basis bestimmter Werte erstellt werden, z. B. für Sonnenaufgang und Sonnenuntergang:

configuraton.yaml

sensor:
  - platform: template
    sensors:
      nextsunrise:
        friendly_name: 'Sonnenaufgang'
        value_template: >
          {{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom(' %H:%M') | replace(" 0", "") }}
        icon_template: mdi:weather-sunset-up
      nextsunset:
        friendly_name: 'Sonnenuntergang'
        value_template: >
          {{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom(' %H:%M') | replace(" 0", "") }}
        icon_template: mdi:weather-sunset-down
      nextsunsetsunrise:
        friendly_name: 'Sonne'
        value_template: >
          {{ as_timestamp(states.sun.sun.attributes.next_rising) | timestamp_custom(' %H:%M') | replace(" 0", "") }} - {{ as_timestamp(states.sun.sun.attributes.next_setting) | timestamp_custom(' %H:%M') | replace(" 0", "") }}
        icon_template: mdi:weather-sunset-up   

Plattform Integration

Um aus einem Momentanwert den Verbrauch zu bestimmen, kann eine sogenannte Plattform-Integration verwendet werden. Als Beispiel kann aus bestimmten Verbrauchswerten: Watt der komplette Verbrauch summiert werden:

sensor:
  - platform: integration
    source: sensor.waschmaschine_power
    name: waschmaschine_energy_sum
    unit_prefix: k
    unit_time: h
    round: 2  

Der Verbrauch wird summiert:

Um den summierten Verbrauch wieder auf eine bestimmte Zeitspanne zu beziehen, kann die Platform Integration als „utility_meter“ verwendet werden:

Utility_Meter

Der Utility-Meter verwendet den Gesamtverbrauch und unterteilt diesen in bestimmte Zeitspannen: z.B. stündlich (hourly) oder (täglich) daily:

utility_meter:
  waschmaschine_hour:
    source: sensor.trockner_energy_sum
    name: Waschmaschine hour
    cycle: hourly  
  waschmaschine_daily:
    source: sensor.trockner_energy_sum
    name: Waschmaschine hour
    cycle: daily

Shelly

Nachdem es mit Home Assistant ein leichtes ist, verschiedene Systeme zu verbinden, habe ich neben ZigBee auch einen WLAN-Schalter im Einsatz. Shelly ist ein kleiner Unterputz-WLAN-Schalter für das Steuern z.B. einer Steckdose.

Nach dem Setup wird das Gerät automatisch dem Standard-Home-Dashboard zugewiesen:

Device Tracker OpenWrt

Wer über OpenWrt die Anwesenheit von Geräten tracken will, kann dies mit dem Eintrag device_tracker in der configuration.yaml-Datei:

device_tracker:
  - platform: luci
    host: 192.168.1.2
    username: root
    password: ???
    interval_seconds: 30
    consider_home: 360
    new_device_defaults:
       track_new_devices: true

Für OpenWRT wird dazu das Paket luci-mod-rpc vorausgesetzt. Informationen zu OpenWrt, siehe: Alternative Router Firmware: OpenWrt und nicht mehr DD-WRT

Alternativ kann der Status auch über einen Ping abgefragt werden:

Ping auf ein Netzwerkgerät

Wer über OpenWrt die Anwesenheit von Geräten über einen Ping tracken will, kann dies mit dem Eintrag binary_sensor in der configuration.yaml-Datei:

..
binary_sensor:
  - platform: ping
    name: FireTV
    scan_interval: 120
    host: 192.168.1.104
..

Der Status des Sensors ist je nach Erreichbarkeit des Geräts: "off" oder "on"

MQTT-Geräte als Sensor verbinden 

Nachdem die MQTT-Integration hinzugefügt wurde, kann in der configuration.yaml-Datei ein neuer Sensor angelegt werden:

Voraussetzung für MQTT ist ein MQTT-Broker-Server, siehe MQTT - Broker : Docker Setup.

Hinzufügen von einzelnen Sensoren in der configuration.yaml-Datei:

sensor:
  - platform: mqtt
    state_topic: "flowmeter/flow"   
    name: "flowmeter"
    unit_of_measurement: "m³/h"

Home-Dashboard

Alle eingebundenen Geräte werden automatisch im Home-Dashboard angezeigt.

Die Dashboards können natürlich auch selbst erstellt und angepasst werden.

Verlauf

Im Verlauf werden die historischen Daten der einzelnen Geräte automatisch aufbereitet:

Die Standardeinstellungen für die History sind 10 Tage, danach werden historische Werte aus der Datenbank gelöscht:

Einstellung: purge_keep_days integer (optional, default: 10) in der Datei configuration.yaml:

recorder:
  purge_keep_days: 10

Siehe, www.home-assistant.io/integrations/recorder/, bzw. um eine andere Datenbank als SQLite zu verwenden: Home Assistant Datenbank MySQL vs. SQLite und für die Anbindung einer InfluxDB, siehe: InfluxDB: Time series database - Docker und für das Visualisieren: Grafana: Docker - Daten visualisieren und Alarme definieren.

Home Assistant Community Store (HACS)

Eigentlich wollte ich nur ein RGB-Licht in das Dashboard hinzufügen, geht zwar, aber ohne der Möglichkeit die Farbe zu ändern: An dieser Stelle hätte ich mir mehr erwartet. Die Recherche und Installation einer Integration für das Steuern von Farben hat mich wesentlich mehr Zeit gekostet als die eigentliche Home Assistant Installation. Dafür habe ich mit HACS aber die Grundlage für weitere Anpassungen geschaffen. HACS ist eine Integration um GitHub Repositories über eine Art Softwarekatalog herunterzuladen. 

Installiert habe ich HACS über einen Befehl im Docker-Container:

user@rechner:~$ docker exec -it home-assistant bash
bash-5.0# wget -q -O - https://install.hacs.xyz | bash -

dann auf Einstellungen, Integration 

und im Anschluss muss die Installation auf GitHub registriert werden, siehe: hacs.xyz/docs/configuration/basic

Ist HACS erst mal installiert, geht das Hinzufügen von zusätzlichen Repositorys relativ einfach:

HACS: Must-have Frontend-Pakete

Resourcen hinzufügen - RGB Light Card

Wer RGB-Lichter im Einsatz hat, kann für das Ändern der Farben die RGB Light Card verwenden:

apexcharts-card

Neben der RGB Light Card, habe ich auch apexcharts-card installiert. Mit diesem Paket können wesentlich ansprechendere Graph-Cards erstellt werden:

Plotly Graph Card

Wer für Charts eine Zoom- und Scroll-Funktion sucht, sollte sich Plotly Graph Card ansehen:

lovelance-card-mod

Mit "lovelance-card-mod" können Elemente in Home Assistant belieben über CCS-Styles angepasst werden:

Siehe: github.com/thomasloven/lovelace-card-mod

Benachrichtigung aufs Handy - Alarm

Die Android-App „Home Assistant“ bietet neben zahlreichen Handy-Sensor-Werten in Home Assistant auch eine sehr einfache Möglichkeit Benachrichtigungen aus Home Assistant zu empfangen: https://play.google.com/store/apps/details?id=io.homeassistant.companion.android&hl=de_AT&gl=US.

Wer die App installiert, wird feststellen, dass Home Assistant regelmäßig das Aktualisieren der Handy-Sensoren nach Home Assistant kundtut:

Aktualisiere Sensoren

Standardmäßig wird alle 15 Minuten eine Benachrichtigung mit „Aktualisiere Sensoren“ angezeigt:

Der Hinweis kann ganz einfach durch ein langes Drücken auf die Benachrichtigung und dem Deaktivieren des „SensorWorker“ entfernt werden:

Das Deaktivieren des SensorWorker beeinflusst die in den Automatisierungen hinterlegten Benachrichtigungen nicht, diese bleiben dennoch aktiv. Um eine Benachrichtigung beim Eintritt eines Ereignisses zu erhalten, kann dafür eine Automatisierung angelegt werden, dazu auf „Konfiguration“ und „Automatisierung“:

Benachrichtigung beim Erreichen eines bestimmten Wertes

Als Beispiel habe ich eine Benachrichtigung für das Überwachen der Luftfeuchtigkeit erstellt:

Für diese Meldung habe ich in Konfiguration / Automatisierung eine neue Automatisierung erstellt:

Die Benachrichtigung kann später mit „RUN ACTIONS“ getestet werden, zunächst aber zu den Einstellungen dieser Automatisierung:
 

service: notify.mobile_app_sm_a405fn
data:
  title: Luftfeuchtigkeit Bad
  message: >-
    Luftfeuchtigkeit: {{states('sensor.bad_2')}}%
    Temperatur:{{states('sensor.bad')}}°C

Zugriff über das Internet HTTPS-SSL (Let's Encrypt) und Docker Compose

Dank Let’s Encrypt kann Home Assistant sehr einfach mit einem SSL-Zertifikat versorgt und somit sicher im Internet betrieben werden. Als Voraussetzung dafür habe ich folgendes Setup im Einsatz: Traefik in Docker | mehrere Webserver inkl. Zertifikat SSL.

Für den Betrieb mit dem Reverse-Proxy habe ich folgende Einstellungen in der Konfiguration getroffen:

configuration.yaml:

http:
  server_port: 8123
  use_x_forwarded_for: true
  trusted_proxies:
    - 127.0.0.1
    - ::1    
    - 172.18.0.0/16

Ich verwende für die Web-Container, die über den Let’s Encrypt-Reverse-Proxy aus dem Internet erreichbar sind, das Netzwerk „webproxy“. Entsprechend habe ich für Home Assistant folgendes docker-compose-File erstellt:

docker-compose.yml

version: "3"
services:
  hass:
    image: homeassistant/home-assistant:stable
    container_name: home-assistant 
    #Labels für ReverseProxy, siehe: https://www.libe.net/traefik
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ha.rule=Host(`ha.domain.tld`)"      
      - "traefik.http.routers.ha.entrypoints=web"
      - "traefik.http.routers.ha.entrypoints=websecure"
      - "traefik.http.routers.ha.tls.certresolver=myresolver"      
      - "traefik.http.services.ha.loadbalancer.server.port=8123"
    restart: always
    volumes:
      - ha:/config
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    expose:
       - "8123"
    #Für einen direkten Test-Zugriff, in den folgenden 2 Zeilen "#" entfernen. Aufruf: http://localhost:8123 oder http://ServerIP:8123
    #ports:   
      #- "8123:8123" 
volumes:
  ha:
#Ohne dem Einsatz eines Reverse Proxy (https://www.libe.net/traefik) fehlt voraussichtlich das Netzwerk webproxy 
#und die folgenden Zeilen können entfernt oder auskommentiert werden. Alternativ kann das Netzwerk mit "docker network create webproxy" erstellt werden
networks:
  default:
    external:
      name: webproxy

Für einen direkten Zugriff über die IP-Adresse oder localhost - auch ohne Reverse Proxy, DNS oder öffentlicher IP - kann die auskommentierte Port-Einstellung für Testzwecke aktiviert werden, indem „#“ vor „ports:“ und „-"83:80"“ entfernt wird. Sollte der Reverse Proxy nicht eingesetzt werden, wird das Netzwerk webproxy nicht benötigt und der Bereich networks: .. kann entfernt werden. Für den Internetzugriff über den Traefik Reverse Proxy, muss in den Labels die Domäne mit den zuvor erstellten DNS-Einträgen ersetzt werden (im Beispiel: ha.domain.tld). Das Beispiel verwendet Docker Volumes und keine Bind-Mounts für das permanente Speichern der Daten. Siehe: Docker Daten speichern: Docker Volumes vs. Host-Ordner

deCONZ und Home-Assistant in einem docker-compose.yml-File

Damit auch der Conbee 2-Stick angesprochen werden kann, habe ich deCONZ hinzugefügt

version: "3"
services:
  hass:
    image: homeassistant/home-assistant:stable
    container_name: home-assistant 
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ha.rule=Host(`ha.domain.tld`)"      
      - "traefik.http.routers.ha.entrypoints=web"
      - "traefik.http.routers.ha.entrypoints=websecure"
      - "traefik.http.routers.ha.tls.certresolver=myresolver"      
      - "traefik.http.services.ha.loadbalancer.server.port=8123"
    restart: always
    volumes:
      - ha:/config
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    expose:
       - "8123"
  deconz:
    image: marthoc/deconz
    container_name: deconz
    environment:
      DECONZ_DEVICE: '/dev/ttyACM0'
      DECONZ_VNC_MODE: '1'
      DECONZ_VNC_PORT: '5900'
      DECONZ_VNC_PASSWORD: 'password'
    restart: always
    volumes:
      - deconz:/root/.local/share/dresden-elektronik/deCONZ
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    devices: 
      - /dev/ttyACM0
    ports:
       - 83:80
       - 5983:5900
volumes:
  ha:
  deconz:
networks:
  default:
    external:
      name: webproxy

Nach ca. einem Jahr mit deCONZ bin ich auf Zigbee2MQTT umgestiegen, entsprechend habe ich im folgenden Beispiel deCONZ entfernt und Zigbee2MQTT und MQTT zusammen mit Home-Assistant in ein docker-compose-File gegeben: 

Alternativ: Zigbee2MQTT, MQTT und Home-Assistant in einem docker-compose.yml - File

Mein komplettes Setup, bestehend aus Home Assistant, MQTT und Zigbee2MQTT, einen laufenden Let's Encrypt Reverse Proxy vorausgesetzt, schaut aktuell wie folgt aus:

version: "3"
services:
  hass:
    image: homeassistant/home-assistant:stable
    container_name: home-assistant 
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ha.rule=Host(`ha.domain.tld`)"      
      - "traefik.http.routers.ha.entrypoints=web"
      - "traefik.http.routers.ha.entrypoints=websecure"
      - "traefik.http.routers.ha.tls.certresolver=myresolver"      
      - "traefik.http.services.ha.loadbalancer.server.port=8123"
    restart: always
    volumes:
      - ha:/config
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    expose:
       - "8123"
  mosquitto:
    image: eclipse-mosquitto
    container_name: mqtt
    restart: always
    volumes:
      - mosquitto-config:/mosquitto/config
      - mosquitto-data:/mosquitto/data
      - mosquitto-log:/mosquitto/log
    ports:
      - "1883:1883"
      - "9001:9001"      
  zigbee2mqtt:
      container_name: zigbee2mqtt
      restart: always
      image: koenkk/zigbee2mqtt
      volumes:
        - mqtt:/app/data
        - /run/udev:/run/udev:ro
      ports:
        - 83:8080
      environment:
        - TZ=Europe/Vienna
      devices:
        - /dev/ttyACM0
volumes:
  ha:
  mqtt:
  mosquitto-config:
  mosquitto-data:
  mosquitto-log:
networks:
  default:
    external:
      name: webproxy

InfluxDB und Grafana

Um für meine Heizung Langzeitwerte zu speichern und diese besser visualisieren zu können, habe ich zudem für das Speichern der Daten eine InfluxDB und für das Auswerten Grafana im Einsatz. Die Anbindung der InfluxDB hier erfolgt über die Home-Assistant-Konfig-Datei configuration.yml

...
influxdb:
  include:
    entities:
       - sensor.1...
       - sensor.2...
  host: influxdb
  port: 8086
  database: ha
  username: ha
  password: ???
  max_retries: 3

Die Version 1 verwendet für die Verbindung einen Benutzernamen und ein Passwort,  Version 2: Token, Organisation und Bucket.

Nachdem ich nicht alle Daten in Grafana auswerten möchte, habe ich mit „include“ nur bestimmte Sensoren hinterlegt. Das komplette Docker-Setup für Home-Assistant, MQTT, Zigbee2MQTT, InfluxDB und Grafana schaut bei mir dann so aus:

version: "3"
services:
  hass:
    image: homeassistant/home-assistant:stable
    container_name: home-assistant 
    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.ha.rule=Host(`ha.domain.tld`)"      
      - "traefik.http.routers.ha.entrypoints=web"
      - "traefik.http.routers.ha.entrypoints=websecure"
      - "traefik.http.routers.ha.tls.certresolver=myresolver"      
      - "traefik.http.services.ha.loadbalancer.server.port=8123"
    restart: always
    volumes:
      - ha:/config
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro
    expose:
       - "8123"
  mosquitto:
    image: eclipse-mosquitto
    container_name: mqtt
    restart: always
    volumes:
      - mosquitto-config:/mosquitto/config
      - mosquitto-data:/mosquitto/data
      - mosquitto-log:/mosquitto/log
    ports:
      - "1883:1883"
      - "9001:9001"      
  zigbee2mqtt:
      container_name: zigbee2mqtt
      restart: always
      image: koenkk/zigbee2mqtt
      volumes:
        - mqtt:/app/data
        - /run/udev:/run/udev:ro
      ports:
        - 83:8080
      environment:
        - TZ=Europe/Vienna
      devices:
        - /dev/ttyACM0
  influxdb:
      container_name: influxdb
      restart: always
      image: influxdb
      volumes:
        - influxdb:/var/lib/influxdb
      ports:
        - 8086:8086
  grafana:
      container_name: grafana
      restart: always
      image: grafana/grafana
      volumes:
        - grafana:/var/lib/grafana
      ports:
        - 3000:3000
volumes:
  ha:
  mosquitto-config:
  mosquitto-data:
  mosquitto-log:
  mqtt:
  influxdb:
  grafana:
networks:
  default:
    external:
      name: webproxy

siehe dazu auch: InfluxDB: Time series database - Docker und Grafana: Docker - Daten visualisieren und Alarme definieren

Troubleshooting – deCONZ

EVENTS

In den Developer Tools, kann im Reiter „EVENTS“ beobachtet werden, welche Geräte eine Aktion auslösen, beispielsweise beim Drücken auf einen Taster:

deconz_event

Der Konfigurationsfluss konnte nicht geladen werden

Durch den Betrieb von deCONZ in Docker kann sich beim Neustart die IP-Adresse des deCONZ Containers ändern. Home Assistant verwendet nicht den Namen des Containers für die Verbindung, sondern dessen IP-Adresse, daher funktioniert die Verbindung dann nicht mehr:

Die Einstellung in der Datei .storage/core.config_entries zeigt dann auf eine falsche IP-Adresse:

Markisensteuerung – ausgegraut

Ich hatte anfangs das Problem, dass sich meine Markise nur in eine Richtung bewegen ließ.

Bei dem ZigBee-Schalter handelt es sich laut Phoscon um das Modell FB56+CUR17SB2.2 (Heiman)

Für das Anpassen bestimmter Einstellungen wird der erweiterte Modus benötigt.

Einstellungen: Anpassung

Dadurch können in den Einstellungen bestimmte Attribute geändert werden, in meinem Fall „assumed_state“

Die Datei customize.yaml wird dadurch wie folgt befüllt:

cover.window_covering_device_10:
  assumed_state: true

Damit die Einstellungen geladen werden, muss die Datei noch in der configuration.yaml angegeben werden:

homeassistant:
  customize: !include customize.yaml

Dann noch den Docker-Container neugestartet und siehe da, jetzt funktioniert auch die andere Richtung:

Fazit

Dank der schnellen Inbetriebnahme und dem einfachen Umsetzen neuer Ideen, bin ich mit Home Assistant aktuell mehr als zufrieden und habe mein zuvor erstelltes Setup, bestehend aus ioBroker, InfluxDB und Grafana, mit Home Assistant abgelöst. Für die meisten Dashboards verwende ich Home Assistant und nur für bestimmte Visualisierungen habe ich InfluxDB und Grafana zusätzlich im Einsatz. Für einen Vergleich mit anderen Smart-Home-Plattformen, siehe: Smart-Home-Plattform: Systeme