Vorhaben

Ziel dieses Beitrags ist Home Assistants mächtige Funktion der Automation Templates näherzubringen und diese zu nutzen, um die bestehende Custom App zu optimieren. Dazu wird die Automation erweitert und die Trigger Data verwendet, um den dargestellten Text des Bitcoin Kurse einzufärben. Steigt der Kurs, gegenüber dem zuletzt gelieferten Ausgangswert, wird der Text grün dargestellt. Fällt der Kurs, wird er in roter Textfarbe ausgegeben. Ist der Wert gleichbleibend erfolgt eine Ausgabe in Gelb:

Zur Einfärbung des Texts muss die State Trigger Data herangezogen werden, die zwei Variablen namens trigger.from_state und trigger.to_state bereitstellt:

Automation anpassen

Die Farbausgabe auf dem Display wird über den Payload Key color definiert. Zuvor muss jedoch ermittelt werden, ob der letzte gelieferte Wert des Sensors sensor.exchange_rate_1_btc größer oder kleiner ist als der aktuelle Wert:

alias: notify_pixelclock_bitcoin
trigger:
  - trigger: state
    entity_id: sensor.exchange_rate_1_btc
action:
  - action: mqtt.publish
    data:
      qos: 2
      retain: true
      topic: pixelclock/custom/bitcoin
      payload: >-
        {
          "text": "{{ states('sensor.exchange_rate_1_btc') | round(0) }}",
          "icon": "bitcoin",
          "color":  {% if is_number(trigger.from_state.state) and (float(trigger.to_state.state,default=0) > float(trigger.from_state.state,default=0)) %}
                      "#006400"
                    {% elif is_number(trigger.from_state.state) and (float(trigger.to_state.state,default=0) < float(trigger.from_state.state,default=0)) %}
                      "#FF0000"
                    {% else %}
                      "#FFCC00"
                    {% endif %}
        }

Handelt es sich beim aktuellen Sensorwert um einen numerischen Wert (is_number()) und ist dieser größer als der vorherige Wert wird der Text nun in Grün ausgegeben:

Fällt der aktuelle Kurs, wird der Text Rot ausgegeben:

Im Falle eines gleichbleibenden Werts, wird der Text in gelber Farbe ausgegeben.

Einbindung über Phoscon App

Der Rauchmelder kann über die deCONZ Integration eingebunden und muss zuvor über die Phoscon App verbunden werden. Wie bereits in allen anderen Beiträgen zum Thema Zigbee Geräte nutze ich dafür das offizielle deCONZ Add-On.

Der Pairing Mode des Rauchmelders wird über drei schnelle kurze Klicks auf den einzigen Button des Geräts aktiviert. Anschließend steht der Rauchmelder in der Phoscon App in der Sektion Sensoren zur Verfügung:

Der Rauchmelder erscheint in Homeassistant als Binary Sensor, der detektierten Rauch mit einem State on anzeigt. Zusätzlich sind drei weitere Sensoren vorhanden:

1. Ein Binary Sensor, der einen niedrigen Batteriestand mit dem State on anzeigt.
2. Ein Binary Sensor, der die Ausführung des Test-Modus mit dem State on anzeigt.
3. Ein numerischer Sensor, der den Batteriestand in Prozent anzeigt.

Rauchmelder Gruppe erstellen

Da ein Rauchmelder selten alleine daherkommt, werden alle Geräte in einer Gruppe mittels Group Integration zusammengefasst. Dazu folgenden Eintrag in der group.yaml erstellen und die Namen der Entities entsprechend anpassen:

rauchmelder:
  name: Rauchmelder
  entities:
    - binary_sensor.rauchmelder_flur
    - binary_sensor.rauchmelder_ballsaal
    - binary_sensor.rauchmelder_schlafzimmer

Der Eintrag erzeugt in Homeassistant nun eine Gruppe:

Der Vorteil der Group Integration liegt darin, dass nur einer der Sensoren einen Feueralarm melden muss, um den State der Gruppe auf on zu setzen. Dieser State der Gruppe wird in der nun zu erstellenden Automation genutzt.

Automation für Push-Message

Die folgende Automation erzeugt eine Push-Nachricht, die den Namen des Rauchmelders enthält, der einen Brand/Rauch detektiert hat. Trigger ist der State der anglegten Gruppe. Im Falle eines Brandes werden alle Lichter des Hauses blinkend geschaltet, mittels des Parameters flash: long der Action light.turn_on.

- alias: Feueralarm
  trigger:
    - trigger: state
      entity_id: group.rauchmelder
      to:  'on'
  action:
    - action: notify.mobile_app_iphone
      data:
        title: "🔥 Feueralarm 🔥"
        message: "{{ states | selectattr('entity_id','in', state_attr('group.rauchmelder','entity_id')) | selectattr('state','eq','on') | map(attribute='name') | join(', ') }}"
        data:
          tag: "push_feueralarm"
          channel: Alarm
    - action: light.turn_on
      data:
        entity_id:
          - light.deconz_licht_wohnzimmer
          - light.deconz_licht_flur
          - light.deconz_licht_schlafzimmer
          - light.deconz_licht_ballsaal
        flash: long

Automation Testen

Hält man den Button des Rauchmelders lange gedrückt, wird der Test-Modus aktiviert. Die erzeugte Gruppe wechselt in den State on und die Automation wird getriggert:

Nachricht auf Ulanzi Pixelclock

Wer eine Ulanzi Pixelclock im Eigenheim betreibt, kann zusätzlich auf dieser eine Warnung ausgeben:

    - action: mqtt.publish
      data:
        qos: 2
        retain: false
        payload: >-
          {
            "text": "Feuer!",
            "icon": "fire",
            "hold": true
          }
        topic: pixelclock/notify

Als Icon nutze ich dafür die animierte Flamme mit der Icon ID 7756, die unter dem Dateinamen fire.gif auf der Pixelclock abgespeichert ist:

Home Assistant hat die Konfiguration für Template Sensoren überarbeitet und mich mit haufenweise Warnmeldungen überschüttet. Siehe: Deprecation of legacy template entities in 2025.12

Die Deprecation Warnings betrafen unter Anderem den Post Room Based Presence mit Motion Sensoren, was ich als Anlass genommen habe das Setup neu zu überdenken. Da ich vor kurzem arbeitsfrei geworden bin, ist die Zeit dafür vorhanden.

Vorhaben

Befindet sich im trauten Eigenheim ein Bewegungssensor in jedem Raum, kann man über diese ermitteln, in welchem Raum zuletzt eine Bewegung erkannt wurde. In einem Single-Haushalt entspricht diese Information dem Raum, in dem man sich gerade aufhält. Diese Information kann zielführend genutzt werden, wie bereits im Post Room Based Presence mit Motion Sensoren erläutert wurde.

An meinem aktuellen Setup hat mir nie gefallen, dass ich auf eine zusätzliche Custom Component namens home-assistant-variables angewiesen war. Im Kern war dies immer eine Lösung, die zuverlässig funktioniert hat und mich vor der Auseinandersetzung mit Template Sensoren freigesprochen hat.

Template Sensoren nutzen eine sperrige Syntax aus der Hölle, die durch die Python Template Engine Jinja2 bereitgestellt wird. Im Home Assistant Forum gibt es herausstechende Planetenbürger wie Petro, die diese Syntax mit einer Leichtigkeit beherrschen, als würde man Pfannkuchen backen. Zu diesen Menschen zähle ich jedoch nicht. Nichtsdestotrotz habe ich noch einmal das Forum durchforstet und eine funktionierende Lösung in diesem Thread Quick sensor/template question - Last active motion sensor gefunden.

Aus einer vordefinierten Liste an Bewegungssensoren soll jener ermittelt werden, der als letztes den State on gemeldet hat. Die Bewegungssensoren sind naturgemäß als Binary Sensors in Home Assistant eingebunden, das sie lediglich die States on und off besitzen können. Bewegung wird detektiert oder eben nicht.

Als Beispiel eingesetzter Bewegungsmelder werden folgende Entities und Namen verwendet:

Last Motion Sensor

Der Code des Template Sensors macht folgendes:

• Er definiert die Entity Names der Bewegungssensoren in einer Liste sensors.
• Er ermittelt alle Entities in der Liste sensors, die den State on besitzen und speichert diese als eine Liste.
• Wenn mehr als ein Bewegungssensor in dieser Liste den State on besitzt, wird der Name des zuletzt getriggerten Sensors zurückgegeben.
• Für meinen persönlichen Fall habe ich noch einen regex_replace() gesetzt, der mir den Präfix Hue Motion aus dem Rückgabewert entfernt. Somit bleibt lediglich der Raumname über, bspw. Hue Motion Flur wird reduziert auf Flur.
• Für jeden Raum wird ein Custom Icon definiert, das sich dynamisch anpasst, je nachdem wo zuletzt eine Bewegung registriert wurde.

template:
  - sensor:
      - name: last_motion
        state: >
          {%- set sensors = 'binary_sensor.hue_motion_flur', 'binary_sensor.hue_motion_kueche', 'binary_sensor.hue_motion_schlafzimmer', 'binary_sensor.hue_motion_wohnzimmer' %}
          {% set sensors_on = expand(sensors) | selectattr('state', 'eq', 'on') | map(attribute='name') | list %}
          {% if sensors_on | count > 0 %}
            {{ expand(sensors) | selectattr('state', 'eq', 'on') | sort(reverse=true, attribute="last_changed") | map(attribute='name') | list | first | default(none) | regex_replace(find='Hue Motion ', replace='') }}
          {% else %}
            {{ expand(sensors) | sort(reverse=true, attribute="last_changed") | map(attribute='name') | list | first | default(none) | regex_replace(find='Hue Motion ', replace='') }}
          {% endif %}
        icon: >
          {% if is_state('sensor.last_motion', 'Küche') %}
            mdi:food-variant
          {% elif is_state('sensor.last_motion', 'Wohnzimmer') %}
            mdi:sofa
          {% elif is_state('sensor.last_motion', 'Flur') %}
            mdi:cube-unfolded
          {% elif is_state('sensor.last_motion', 'Schlafzimmer') %}
            mdi:bed
          {% else %}
            mdi:account-question
          {% endif %}

Der Sensor ersetzt nahtlos das alte Setup, reduziert unnötige Komplexität und liefert identische Rückgabewerte, wie die alte Lösung mittels home-assistant-variables:

Er kann für viele Automationen genutzt werden, bspw. wenn ein Media-Player bei aktiver Wiedergabe pausiert werden soll, wenn man den Raum verlässt oder aber, wenn das Licht in einem Raum nicht ausgeschaltet werden soll, wenn man sich darin aufhält.

Bei Custom Apps ist es, je nach Anwendungsfall, sinnvoll das MQTT-Flag retain: true zu setzen. Nur so ist gewährleistet, dass eine Custom App den Neustart der Pixelclock übersteht und persistent angezeigt wird. Custom Apps leben ansonsten nur im RAM des ESP32 und werden bei einem Neustart gelöscht. Das Retain-Flag bewirkt, dass der MQTT-Broker bei einer Neuverbindung der Pixelclock erneut, die zuletzt gesendete Message an diese übermittelt.

Wann macht es Sinn das Retain-Flag zu nutzen:
Wenn Sensor Daten sich nicht häufig aktualisieren und somit der Trigger in Homeassistant nicht häufig auslöst. Startet man in diesem Fall die Pixelclock neu, kann es unter Umständen sehr lange dauern, bis ein neuer Wert gesendet wird. Die Custom App wäre bis zu diesem Zeitpunkt nicht aktiv.

Wann macht es keinen Sinn das Retain-Flag zu setzen:
Wenn Custom Apps automatisch bei einem Trigger X entfernt werden, siehe Beispiel der Spotify App. Es macht keinen Sinn die letzten Wiedergabeinformationen eines Songs am Broker vorzuhalten, da diese Info flüchtig ist und sich häufig ändert und der Song ggf. gar nicht mehr abgespielt wird, wenn die Pixelclock neugestartet wird.

Custom Apps

Folgend eine List an Custom App, die im Zusammenspiel mit Homeassistant an die Pixelclock gesendet werden können. Alle Daten werden direkt aus Homeassistant generiert und benötigen keinerlei externe Add-Ons, wie bspw. Node Red.

Zu jeder Custom App ist ein Icon von der LaMetric Developer Website verlinkt. Der nachfolgende Dateiname entspricht der Benennung im Filesystem der Pixelclock.

Spotify

Dargestellt wird der aktuell abgespielte Künstler und Songname, sowie ein Fortschrittsanzeige (Progressbar) für den aktuell abgespielten Song. Die Progressbar wird aus zwei Attributen des Media-Players errechnet. Der Name des Media-Players muss entsprechend an den Namen der eigenen Entity in Homeassistant angepasst werden.

Die App wird automatisch entfernt, wenn der State des Media-Player auf idle oder paused wechselt und keine Wiedergabe mehr erfolgt.

Automation:

- alias: notify_pixelclock_spotify
  trigger:
    - platform: state
      entity_id: media_player.spotify
  action:
    - choose:
        - conditions:
            - condition: state
              entity_id: media_player.spotify
              state: 'playing'
          sequence:
            - service: mqtt.publish
              data:
                qos: 2
                retain: false
                payload: >-
                  {
                    "text": "{{ state_attr('media_player.spotify', 'media_artist') }} - {{ state_attr('media_player.spotify', 'media_title') }}",
                    "icon": "spotify",
                    "rainbow": false,
                    "duration": 10,
                    "pushIcon": 0,
                    "textCase": 2,
                    "progress": {{ ( states.media_player.spotify.attributes.media_position / states.media_player.spotify.attributes.media_duration * 100 ) | round() }},
                    "progressC": "18B04C"
                  }
                topic: pixelclock/custom/spotify
        - conditions:
            - condition: template
              value_template: "{{ not states.media_player.spotify.state == 'playing' }}"
          sequence:
            - service: mqtt.publish
              data:
                qos: 2
                retain: false
                topic: pixelclock/custom/spotify

pr0gramm

Zeigt den Benis eines beliebigen Accounts auf einem großen deutschen Imageboard, über das niemand spricht. Der Username, beispielhaft horst, muss entsprechend im API-Call angepasst werden.

Sensor:

- platform: rest
  scan_interval: 3600
  name: "Pr0 Benis"
  unit_of_measurement: ''
  value_template: '{{ value_json["user"]["score"] | int }}'
  resource: 'https://pr0gramm.com/api/profile/info?name=horst'

Automation:

- alias: notify_pixelclock_pr0
  trigger:
    - platform: state
      entity_id: sensor.pr0
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: true
        payload: >-
          {
            "text": "{{ states.sensor.pr0.state }}",
            "icon": "pr0"
          }
        topic: pixelclock/custom/pr0

Wetter

Für diese Custom App sind diverse Icons erforderlich. Das exakte Vorgehen wurde bereits im vorhergehenden Post Ulanzi Smart Pixel Clock TC001 im Detail erläutert.

Die Temperatur wird ganzzahlig gerundet dargestellt.

Automation:

- alias: notify_pixelclock_weather
  trigger:
    - platform: state
      entity_id: weather.openweathermap
    - platform: template
      value_template: "{{ states.weather.openweathermap.attributes.temperature }}"
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: true
        payload: >-
          {
            "text": "{{ states.weather.openweathermap.attributes.temperature | round(0) }} {{ states.weather.openweathermap.attributes.temperature_unit }}",
            "icon": "{{ states('weather.openweathermap') }}",
            "rainbow": false
          }
        topic: pixelclock/custom/weather

Bitcoin

Der aktuelle Kursstand des Bitcoins. Der Name des Sensors muss entsprechend angepasst werden.

Automation:

- alias: notify_pixelclock_bitcoin
  trigger:
    - platform: state
      entity_id: sensor.exchange_rate_1_btc
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: true
        payload: >-
          {
            "text": "{{ states.sensor.exchange_rate_1_btc.state | round(0) }}",
            "icon": "bitcoin"
          }
        topic: pixelclock/custom/bitcoin

Hochwasserportal

Als echte Nordblume ist der Pegelstand der Ostsee natürlich essentiell. Diese Custom App nutzt eine Custom Integration namens Hochwasserportal, die über HACS installiert werden kann. Drei variable Icons kommen für die Pegelstände zum Einsatz. Bei Hochwasser wird der Text in rot ausgegeben, bei Niedrigwasser in gelb.

- alias: notify_pixelclock_hochwasser
  trigger:
    - platform: state
      entity_id: sensor.ostsee_level
  action:
    - service: mqtt.publish
      data:
      qos: 0
      retain: false
      topic: pixelclock/custom/hochwasser
      payload: >-
        {
          "text": "{{ states.sensor.ostsee_level.state }} cm",
          "textCase": 2,
          "icon": {% if (states.sensor.ostsee_level.state | int <= 379) %} "water-level-low"
                  {% elif (states.sensor.ostsee_level.state | int >= 624) %} "water-level-high"
                  {% else %}"water-level-normal"
                  {% endif %},
          "color":  {% if (states.sensor.ostsee_level.state | int <= 379) %} "#FFFF00"
                    {% elif (states.sensor.ostsee_level.state | int >= 624) %} "#FF0000"
                    {% else %} "#FFFFFF"
                    {% endif %}
        }

Instagram Follower

Angepasst werden muss der Name des Accounts in dem Parameter ressource. Verwendet wird eine Custom Component, die das Scrapen von Webseiten ermöglicht und weitaus mehr Funktionsumfang bietet als die native Scrape Integration von Homeassistant. Die Custom Component kann aus dem HACS Store installiert werden.

Sensor:

multiscrape:
  - name: intagram_followers
    resource: https://www.picnob.com/profile/davidhasselhoff/
    scan_interval: 1800
    sensor:
      - unique_id: ig_followers_davidhasselhoff
        name: "D.Hasselhoff Instagram Followers"
        select: ".item_followers > div:nth-child(2)"

Automation:

- alias: notify_pixelclock_instagram
  trigger:
    - platform: state
      entity_id: sensor.ig_followers_davidhasselhoff
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: true
        payload: >-
          {
            "text": "{{ states.sensor.ig_followers_davidhasselhoff.state | int() }}",
            "icon": "instagram"
          }
        topic: pixelclock/custom/thehoff

Octoprint

Die Custom App zeigt den aktuellen Druckfortschritt in Prozent an. Wenn Octoprint während des Druckvorgangs in einen Fehler läuft, wird eine Nachricht dauerhaft auf der Pixelclock angezeigt, die aktiv durch einen Klick auf den mittleren Button entfernt werden muss. Ist der Druckvorgang beendet, wir die Custom App automatisch entfernt.

Automation:

- alias: notify_pixelclock_octoprint
  initial_state: True
  trigger:
    - platform: template
      value_template: "{{ not state('sensor.octoprint_current_state') == 'Printing' }}"
      id: "idle"
    - platform: state
      entity_id: sensor.octoprint_job_percentage
      id: "printing"
    - platform: state
      entity_id: binary_sensor.octoprint_printing_error
      state: 'on'
      id: "error"
  action:
    - choose:
      - conditions:
          - condition: trigger
            id: "printing"
          - condition: state
            entity_id: sensor.octoprint_current_state
            state: "Printing"
        sequence:
          - service: mqtt.publish
            data:
              qos: 2
              retain: false
              payload: >-
                {
                  "text": "{{ (states('sensor.octoprint_job_percentage') | round(1) ) }}{{ state_attr('sensor.octoprint_job_percentage', 'unit_of_measurement') }}",
                  "icon": "3dprinter",
                  "duration": 10
                }
              topic: pixelclock/custom/octoprint
      - conditions:
          - condition: trigger
            id: "idle"
        sequence:
          - service: mqtt.publish
            data:
              qos: 2
              retain: false
              topic: pixelclock/custom/octoprint
      - conditions:
          - condition: trigger
            id: "error"
        sequence:
          - service: mqtt.publish
            data:
              qos: 2
              retain: false
              topic: pixelclock/custom/octoprint
          - service: mqtt.publish
            data:
              qos: 2
              retain: false
              payload: >-
                {
                  "text": "Error",
                  "icon": "3dprinter",
                  "textCase": 2,
                  "hold": true
                }
              topic: pixelclock/custom/octoprint

NINA Warnungen

Das Bundesamt für Bevölkerungsschutz und Katastrophenhilfe stellt über die NINA Integration ortsbezogene Warnmeldungen für die Bevölkerung bereit. Diese Custom App prüft, ob eine Warnung vorliegt und nutzt das Indicator Feature von AWTRIX Light. Liegt eine Warnung vor, leuchtet der Indicator so lange über allen anderen Custom Apps rot, bis die Warnung aufgehoben wird. Bei Aufhebung der Warnung wird die Custom App automatisch entfernt.

Automation:

- alias: notify_pixelclock_warning
  trigger:
    - platform: state
      entity_id: binary_sensor.warning_kiel
  action:
    - choose:
        - conditions:
            - condition: state
              entity_id: binary_sensor.warning_kiel
              state: "on"
          sequence:
            - service: mqtt.publish
              data:
                qos: 2
                retain: false
                payload: >-
                  {
                    "text": "{{ state_attr("binary_sensor.warning_kiel", "headline") }}",
                    "icon": "warning",
                    "pushIcon": 2
                  }
                topic: pixelclock/custom/nina
            - service: mqtt.publish
              data:
                qos: 2
                retain: false
                payload: >-
                  {
                    "color": [255,0,0]
                  }
                topic: pixelclock/indicator1
        - conditions:
            - condition: state
              entity_id: binary_sensor.warning_kiel
              state: "off"
          sequence:
            - service: mqtt.publish
              data:
                qos: 2
                retain: false
                topic: pixelclock/custom/nina
            - service: mqtt.publish
              data:
                qos: 2
                retain: false
                topic: pixelclock/indicator1

Homeassistant Timer

Homeassistant hat eine Timer Integration, die auf dem Eventbus feuert, wenn ein Timer abgelaufen ist. Wie bereits im Beitrag ControllerX und Home Assistant beschrieben, nutze ich diese für meine Waschmaschine.

Verwendet wird ein Tradfri Shortcut Button. Wenn der Button einfach gedrückt wird startet ein Timer für eine 40° Wäsche, wird er gedrückt gehalten startet ein Timer für die 60° Wäsche.

Ist einer der beiden Timer abgelaufen lauscht eine Automation auf dem Eventbus

Timer Configuration:

Die Werte müssen entsprechend der Waschdauer des eigenen Geräts angepasst werden.

laundry_40:
  duration: '01:58:00'
laundry_60:
  duration: '02:09:00'

Automation:

- alias: notify_pixelclock_laundy_finished
  trigger:
    - platform: event
      event_type: timer.finished
      event_data:
        entity_id: timer.laundry_40
    - platform: event
      event_type: timer.finished
      event_data:
        entity_id: timer.laundry_60
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: false
        payload: >-
          {
            "text": "Fertig",
            "icon": "laundry",
            "hold": true
          }
        topic: pixelclock/notify

Rauchmelder Warnung

Im Post Zigbee Rauchmelder ist eine weitere Custom App beschrieben, die auf der Pixelclock eine Warnung ausgibt, wenn ein Zigbee Rauchmelder einen Brand/Rauch detektiert.

Spritpreise

Mit der Tankerkönig Integration, können die Spritpreise nahegelegener Tankstellen angezeigt werden. Dafür muss zuvor ein API-Key erstellt werden.

Der nachfolgende Automationscode nutzt beispielhaft den Sensor mit dem Namen sensor.shell_pansenstrasse_15_super und entfernt den Tankstellenpfennig/Zehntelpfennig 9. Aus 2.059 € wird 2.05 €.

Automation:

- alias: notify_pixelclock_gasprice
  description: "Spritpreis ohne Tankstellencent 9"
  trigger:
    - trigger: state
      entity_id: sensor.shell_adelheidstr_15_super
  action:
    - action: mqtt.publish
      data:
        qos: 2
        retain: true
        payload: >-
          {
            "text": "{{ "%.2f" | format((states('sensor.shell_pansenstrasse_15_super') | float * 100) | int / 100) }} €",
            "icon": "fuel"
          }
        topic: pixelclock/custom/gasprice

Links

Custom Firmware: AWTRIX3

Obwohl für die Pixel Clock eine ausführliche Anleitung zur Verwendung mit ESPHome existiert, habe ich mich für die Verwendung mit der Custom Firmware AWTRIX3 entschieden.

Die Firmware ist quelloffen und unterstützt Homeassistant Discovery, das eine unkomplizierte Integration mittels MQTT ermöglicht. Vorrausetzung ist, dass ein MQTT-Broker betrieben wird - bspw. mittels des Homeassistant Add-On Mosquitto Broker.

Firmware flashen

AWTRIX3 kann sehr einfach mittels ESP Web Tools direkt aus dem Chrome/Edge Browser auf das Gerät geflasht werden. Dazu muss die Pixel Clock lediglich mittels USB-C Kabel mit einem Rechner verbunden werden und der zugehörige Online Flasher im Browser aufgerufen werden. Nach einem erfolgreichen Flashen wechselt die Pixel Clock in den AP-Modus und spannt ein WiFi mit dem Namen awtrix_XXXXX auf, das mit dem Passwort 12345678 verbunden werden kann. Nachdem die Verbindungsdaten zum heimischen WiFi hinterlegt wurden, startet die Pixel Clock neu und ist fortan im eigenen Netzwerk erreichbar. Die vergebene IP wird praktischerweise auf dem Display dargestellt.

Ersteinrichtung

Ruft man nun das Webinterface der Pixel Clock im Browser auf erscheint eine Oberfläche zur Konfiguration:

Die Menupunkte und ihre Einstellungsmöglichkeiten im Detail:

Sind alle Einstellungen getätigt und die MQTT-Konfigurationswerte korrekt eingegeben worden, erkennt Homeassistant automatisch alle Sensoren und Funktionen der Pixel Clock:

Bedienung

Im Gegensatz zur Standardfirmware von Ulanzi ermöglicht AWTRIX3 die Standardfunktionen, bspw. welche Infos dargestellt werden sollen, wie lange eine Info sichtbar sein soll oder wie schnell die Transition beim Bildschirmwechsel erfolgen soll, direkt über die 3 Buttons auf der Oberseite der Pixel Clock einzustellen. Dazu muss der mittlere Knopf 2 Sekunden gedrückt werden. Anschließend kann mit dem linken und rechten Button navigiert werden. Möchte man ein Untermenüpunkt aktivieren erfolgt dies über einen einfachen Klick auf den mittleren Button. Möchte man zurück ins Menü kehren erfolgt dies wieder durch ein zweisekündiges Gedrückthalten des mittleren Buttons.

Icons herunterladen

Icons können von der Konkurrenz von LaMetric genutzt und heruntergeladen werden. Neben vielen existierenden Icons und Gifs können auf der Herstellerseite auch eigene Icons generiert werden.

Hat man ein passendes Icon gefunden, muss lediglich die ID des Icons im Webinterface von AWTRIX3 im Menüpunkt Icons eingegeben werden. Es kann ein Preview generiert und die Datei direkt ins Dateisystem heruntergeladen werden. Die Icons liegen im Ordner /ICONS/und haben standardmäßig das Namensschema $ID.jpg oder $ID.gif. Die Dateinamen können direkt im Webinterface mit einem Rechtsklick und der Funktion Rename/Move in sprechende Namen umbenannt werden:

RTTTL Soundfiles speichern

Ring Tone Text Transfer Language, kurz RTTTL, Soundfiles können im Ordner /MELODIES/ im txt-Format abgelegt werden. Ein kleiner Fundus an RTTTL-Soundfiles kann hier entdeckt und verwendet werden. Möchte man beispielsweise die Titelmelodie der TV Serie Die Simpsons erklingen lassen, legt man die Datei /MELODIES/simpsons.txt an und fügt dort den folgenden Inhalt ein:

The Simpsons:d=4,o=5,b=160:c.6,e6,f#6,8a6,g.6,e6,c6,8a,8f#,8f#,8f#,2g,8p,8p,8f#,8f#,8f#,8g,a#.,8c6,8c6,8c6,c6

Nutzen als Notifier in Homeassistant

Über MQTT können nun Notifications direkt aus Homeassistant an die Pixel Clock gesendet werden. Entscheidend ist hierfür das vom Benutzer vergebene MQTT Präfix, welches in der Ersteinrichtung gewählt wurde. Ich habe an dieser Stelle den Präfix pixelclock gewählt. Möchte man grundsätzlich erst einmal testen wie Notifications auf der Clock aussehen, kann dies sehr einfach in den Developer Tools von Homeassistant erfolgen. Dazu den Menüpunkt Services auswählen und dann den Service mqtt.publish:

Es stehen grundsätzlich zwei Arten der Notification mit diversen Payload Parametern zur Verfügung, die in der Sektion Custom Apps and Notifications beschrieben werden:

1. Notification: Eine Textnachricht, ggf. mit Icon, die für eine definierbare Dauer dargestellt wird. Es besteht auch die Möglichkeit eine Notification solange darzustellen, bis sie durch einen Klick auf den mittleren Button entfernt wird.
2. Custom Page: Standardmäßig wechselt die Pixel Clock durch ein definierte Liste an Infobildschirmen. Ist das Ende der Liste erreicht, beginnt sie von vorne. Diese Liste kann mit einer (oder mehreren) Custom Page erweitert werden.

Fall 1: Notification

Fiktiver Fall: Ein Rauchmelder in der Wohnung meldet einen Brand. Hierzu habe ich das Feuer-Icon mit der LaMetric-ID 24873 über das Webinterface von AWTRIX3 heruntergeladen und anschließend in feuer.gif umbenannt. Um nun dieses Icon und den Text Feuer! auf dem Display anzuzeigen wird der folgende Service Call gesendet:

service: mqtt.publish
data:
  qos: 2
  retain: false
  payload: >-
    {
      "icon": "fire",
      "text": "Feuer!",
      "hold": true
    }
  topic: pixelclock/notify

Der Parameter hold bewirkt dabei, dass die Darstellung erst beendet wird wenn sie durch einen Klick auf den mittleren Button bestätigt wird.

Fall 2: Custom Page

Fiktiver Fall: Der Wert eines Sensors in Homeassistant soll kontinuierlich auf der Pixel Clock angezeigt werden. Ändert sich der Wert, soll auch die Info auf der Pixelclock aktuell sein. Als Beispiel dient ein REST-Sensor für ein deutsches Bilderbrett, das im Homeassistant Forum zu finden ist. Verwendet wird das Icon mit der LaMetric ID 26807, das anschließend unter dem Dateinamen pr0.jpg gespeichert wurde. Der Sensor hat den Namen sensor.pr0. Zu beachten ist, dass jede Custom Page einen eindeutigen Namen erhält. In diesem Fall ist es pr0. Die Automation in Homeassistant sieht wie folgt aus:

alias: notify_pixelclock_pr0
trigger:
  - platform: state
    entity_id: sensor.pr0
action:
  - service: mqtt.publish
    data:
      qos: 2
      retain: true
      payload: >-
        {
          "text": "{{ states.sensor.pr0.state }}",
          "icon": "pr0",
        }
      topic: pixelclock/custom/pr0

Custom Pages sollten ggf. mit dem parameter retain: true gesendet werden. Der MQTT-Broker speichert somit das letzte gesendete mqtt.publish Kommando und stellt dieses bei einem Neustart der Pixel Clock wieder zur Verfügung. Nähere Erläuterungen zum Thema Retained Messages sind im Folgepost Pixelclock: Custom App Collection zu finden.

Pixelclock: Custom App Collection

29.04.2023·Aktualisiert: 05.03.2026·1556 Wörter·8 min

MQTT Microcontroller media-player Notification

Da die Entwicklung der Custom Firmware AWTRIX3 schleunig voranschreitet und fortlaufend neue Features eingebaut werden, soll dieser Post als Sammler für derzeitige und zukünftige Custom Apps dienen.

Möchte man die Custom Page wieder entfernen, erfolgt dies über das erneute adressieren des App-Topics, jedoch mit einer leeren Payload:

- service: mqtt.publish
  data:
    qos: 2
    topic: pixelclock/custom/pr0

Sounds Wiedergeben

Generell kann jeder Art von Notification auch eine Soundwiedergabe zugewiesen werden, wovon man nur abraten kann. Verwendet wird exemplarisch die bereits erwähnte simpsons.txt RTTTL-File:

service: mqtt.publish
data:
  qos: 2
  retain: false
  payload: >-
    {
      "sound": "simpsons"
    }
  topic: pixelclock/sound

Alternativ kann auch direkt ein RTTTL-String über die API-Endpoint /RTTTL abgespielt werden:

service: mqtt.publish
data:
  qos: 2
  retain: false
  payload: >-
    {
      "sound": "d=4,o=5,b=160:c.6,e6,f#6,8a6,g.6,e6,c6,8a,8f#,8f#,8f#,2g,8p,8p,8f#,8f#,8f#,8g,a#.,8c6,8c6,8c6,c6"
    }
  topic: pixelclock/rtttl

Der Timer ist nach 3 Sekunden abgelaufen und spielt anschließend die Melodie so lange, bis der mittlere Button auf der Clock gedrückt wird.

Automation: Spotify Media Player

Die Pixel Clock eignet sich hervorragend Informationen zum aktuell wiedergegebenen Interpreten und Song darzustellen. Genutzt wird in diesem Beispiel die Spotify Integration. Analog wird erneut ein passendes Icon gesucht und als spotify.gif oder spotify.jpg auf der Clock gespeichert.

Als Trigger wird der State des Spotify Media Player verwendet. Erfolgt eine aktive Wiedergabe wechselt dessen State auf playing und stellt zusätzlich die Attribute media_artist (Interpret) und media-title (Songname) bereit. Wird die Wiedergabe pausiert wechselt der State zu idle und die Attribute stehen nicht länger zur Verfügung, daher muss dieser Fall als Ausnahme über eine Condition ausgeschlossen werden.

Da die dargestellte Textinformation unter Umständen sehr lang ausfallen, macht es Sinn einen höheren Wert für die duration (Anzeigedauer) zu wählen. Auch ist in diesem Fall die Option pushIcon mit dem Wert 2 gesetzt. Dies bewirkt, dass das Icon mit dem Scrollen des Textes mitfährt und anschließend beim nächsten Durchlauf erneut erscheint.

- alias: notify_pixelclock_spotify
  trigger:
    - platform: state
      entity_id: media_player.spotify
  condition:
    not:
      - condition: state
        entity_id: media_player.spotify
        state: "idle"
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: false
        payload: >-
          {
            "text": " {{ state_attr('media_player.spotify', 'media_artist') }} - {{ state_attr('media_player.spotify', 'media_title') }}", 
            "icon": "spotify",
            "duration": 10,
            "pushIcon": 2
          }
        topic: pixelclock/notify

Wetteranzeige

Die Pixelclock lässt sich hervorragend als Wetteranzeiger nutzen. Voraussetzung ist eine eingerichtete Weather Integration bspw. OpenWeatherMap. Die Weather Integration hat, ungeachtet des gewählten Wetterdatenproviders, ein festes Condition Mapping:

Damit eine eindeutige Zuordnung der dargestellten Icons zu der aktuellen Wetterlage möglich ist, sollte für jeden State ein passendes Icon auf die Pixel Clock geladen werden, dass genau den Namen des States trägt, bspw. fog.jpg oder lightning-rainy.gif.

Anschließend kann unter Hilfenahme von Templates eine Automation für eine Custom Page zur Anzeige des Wetters erstellt werden:

- alias: notify_pixelclock_weather
  trigger:
    - platform: state
      entity_id: weather.openweathermap
  action:
    - service: mqtt.publish
      data:
        qos: 2
        retain: true
        payload: >-
          {
            "text": "{{ states.weather.openweathermap.attributes.temperature | round(0) }} {{ states.weather.openweathermap.attributes.temperature_unit }}",
            "icon": "{{ states('weather.openweathermap') }}"
          }
        topic: pixelclock/custom/weather

Die Temperaturwerte werden ganzzahlig gerundet und die Temperatureinheit, bspw. °C, an den Wert angehangen.

Resources

Um den täglichen Verbrauch aller Tasmota-Steckdosen in den real anfallenden Geldbetrag zu wandeln, wird die Custom Component hass-variables benötigt. Diese kann aus dem HACS-Store installiert werden und kam unter anderem bereits in diesen Posts zum einsatz:

• Room Based Presence mit Motion Sensoren
• Homeassistant, FritzBox und Anrufbenachrichtigung per Push-Nachricht

Zur Theorie des Vorhabens

Die Tasmota-Steckdosen liefern einen Wert zum täglichen Stromverbrauch (Energy Today), der um Mitternacht auf 0 gesetzt wird. Tagsüber kann also dieser kumulierende Wert mit dem aktuellen Strompreis multipliziert werden und man erhält den anfallenden Geldbetrag.

Den Strompreis möchte ich zentral in einer Variable festhalten. So kann bei Verwendung mehrerer Tasmota-Steckdosen zentral auf diesen Wert zugegriffen und bei der nächsten anstehenden Erhöhung muss nur an einer Stelle der Strompreis geändert werden.

Strompreisvariable anlegen

Nachdem hass-variable installiert wurde, muss folgender Eintrag in der configuration.yaml erfolgen:

var:
  strompreis:
    restore: true
    initial_value: 0.3615
    icon: mdi:currency-eur
    friendly_name: Strompreis
    unit_of_measurement: '€/kwh'

Anschließend steht die Variable mit der Entity ID var.strompreis in Homeassistant zur Verfügung.

Template Sensor

Nun muss nur noch ein Sensor erstellt werden, der den Tagesverbrauch von einer beliebigen Tasmota Steckdose ausließt und mit dem Strompreis multipliziert. In diesem Beispiel dient mein Kühlschrank mit der Entity ID sensor.kuehlschrank_energy_today als Beispiel parat. Der Sensor muss ebenfalls in der configuration.yaml angelegt werden:

sensor:
  - name: kuehlschrank_kosten_heute
    state: '{{ "%.2f" | format(states.sensor.kuehlschrank_energy_today.state | float | multiply(states.var.strompreis.state | float)) }}'
    unit_of_measurement: €

Der Sensor liefert einen zweistelligen Nachkommawert à la 0,07€.

Kumulierte Kosten mehrerer Steckdosen

Wer mehrere Tasmota-Steckdosen im Eigenheim betreibt, kann den obigen Sensor für alle weiteren Steckdosen einrichten und am Ende die Gesamtsummer errechnen:

sensor:
  - name: kosten_gesamt_elektrische_verbraucher
    state: "{{ '%.2f' | format( (states('sensor.kuehlschrank_kosten_heute') | float) + (states('sensor.heimserver_kosten_heute') | float) }}"
    unit_of_measurement: €

Monats- & Jahreskosten

Da Tasmota nur einen Wert für den Tagesverbrauch liefert, muss zur Ermittlung von monatlichen oder jährlichen Kosten auf bordeigene Mittel in Homeassistant zugegriffen werden. Dafür steht die Utitlity Meter Integration zur Verfügung, die auch schon im Post zum Homeassistant Fitness Tracker zum Einsatz kam:

utility_meter:
  kuehlschrank_kosten_monatlich:
    source: sensor.kuehlschrank_kosten_heute
    cycle: monthly

Homeassistant Fitness Tracker

23.01.2021·531 Wörter·3 min

Utility Meter Companion App

Die Homeassistant Companion App liefert Fitnessdaten, die direkt vom Smartphone OS generiert werden. Diese können in Langzeitstatistiken mittels dem Utility Meter in Homeassistant getrackt und ausgewertet werden.

Das Vorgehen ist einfach erklärt. Mit dem ESPHome Add-On wird eine Firmware für den ESP32 generiert und diese mittels eines USB-TTL-Adapters oder alternativ einem USB-Adapter-Board auf den Microcontroller geflasht. Das Flashen funktioniert seit kurzem reibungslos direkt über einen Webkit-basierten Browser, also Chrome oder Safari und kann daher auch von unbedarften Users einfach vorgenommen werden. Genaueres dazu kann hier nachgelesen werden.

ESPHome: Firmware generieren

Über das ESPHome Add-On muss eine neue Firmware generiert werden. Das Add-On bietet dazu einen Wizard, der den Microcontrollertypen, Ausführungen, Gerätenamen und WLan-Credentials abfragt.

Der Platzhalter YOUR_GENERATED_ID muss durch eine selbstgenerierte ID ersetzt werden. Diese kann direkt auf der ESPHome Webseite generiert und kopiert werden.

Die Config sollte anschließend wie folgt aussehen. Neben der Camera wird noch die eingebaute LED als eigene Entity in Homeassistant bereitgestellt:

esphome:
  name: gockelcam
  platform: ESP32
  board: esp32cam

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_passwd

  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: "Gockelcam Fallback Hotspot"
    password: !secret ap_passwd

captive_portal:

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "YOUR_GENERATED_ID"

ota:
  password: !secret ota_passwd

esp32_camera:
  external_clock:
    pin: GPIO0
    frequency: 20MHz
  i2c_pins:
    sda: GPIO26
    scl: GPIO27
  data_pins: [GPIO5, GPIO18, GPIO19, GPIO21, GPIO36, GPIO39, GPIO34, GPIO35]
  vsync_pin: GPIO25
  href_pin: GPIO23
  pixel_clock_pin: GPIO22
  power_down_pin: GPIO32
  horizontal_mirror: false
  vertical_flip: false
  name: gockelcam

output:
  - platform: gpio
    pin: GPIO4
    id: gpio_4
light:
  - platform: binary
    output: gpio_4
    name: gockelcam light

Zur Verwendung einer secrets.yaml-Datei mit ESPHome kann dieser Post erläuternd zu Rate gezogen werden:

ESPHome Bluetooth Low Energy Hub

13.01.2022·Aktualisiert: 07.08.2025·1121 Wörter·6 min

ESPHome Bluetooth Xiaomi

Dieser Post beschreibt, wie man mittels ESPHome und einem ESP32 Microcontroller ein Bluetooth Low Energy Hub aufsetzt, das alle Bluetooth IoT-Geräte ausliest und als Broker an Homeassistant sendet.

Das initiale Flashen der Firmware muss einmalig über eine Kabelverbindung erfolgen. Anschließend kann die Konfiguration einfach und unkompliziert Over the air angepasst werden.

Wurden alle Schritte erfolgreich durchlaufen erkennt Homeassistant automatisch die neue ESPHome-Node und bietet an diese einzubinden. Anschließend stehen zwei neue Entities zur Verfügung:

USB-Stromversorgung

Da das ESP32-CAM-Modul keinen eigenen Micro-USB-Anschluss auf der Platine enthält, empfiehlt es sich einen altes USB-Ladegerät am Steckerende abzutrennen, die einzelnen Kabel freizulegen und direkt mit der Platinenanschlüssen zu verlöten oder auf ein USB-Breakout-Board zurückzugreifen, wie bspw. in diesem Post beschrieben.

Gehäuse drucken

Da eine nackte Platine nicht sonderlich ansehnlich erscheint, kann der heimische 3D-Drucker angeworfen werden und bei Thingiverse ein passendes Gehäuse gewählt werden. Die vorhandene Auswahl ist groß.

ESP32-CAM in Lovelace UI

Ich habe meine ESP32-CAM mit einer Picture Glance Card in die UI eingebunden. Diese erlaubt neben dem direkten betrachten des Videostream auch das einfach Ein- und Ausschalten der LED auf der Platine des ESP32. Der Code dafür:

type: picture-glance
title: Gockelcam
camera_view: auto
camera_image: camera.gockelcam
entities:
  - entity: light.gockelcam_light

In der Lovelace UI sieht dies dann folgendermaßen aus. Die LED kann mit einem Klick auf das Lampen-Icon einfach geschaltet werden:

In diesem Post erkläre ich, wie man einen Bewegungssensor nutzen kann, um automatisiert die Tagesschau in 100 Sekunden beim morgendlichen Betreten der Küche abzuspielen.

Hardware

Ich verwende bei mir die Motion-Sensoren von Philips Hue in meiner Küche und dort steht auch ein Bose Soundtouch 10 zur räumlichen Beschallung. Für das folgende Beispiel werden diese Entity IDs verwendet:

Setup Bose Mediaplayer

Die Bose Soundtouch App erlaubt das Belegen von sechs Shortcuts, die schnell und unkompliziert über die physischen Buttons auf dem Lautsprecher und der zugehörigen Fernbedienung aktiviert werden können. Gleichzeitig erlaubt die Bose Soundtouch Integration für Homeassistant die Shortcuts automatisiert abzuspielen. In Kombination mit der Spotify Integration lassen sich so leicht vordefinierte Songs, Playlisten und Podcasts automatisiert wiedergeben.

Ich habe den täglichen “Podcast” der Tagesschau in 100 Sekunden auf den Shortcut 4 gelegt.

Die Automation

Wenn morgens die Küche betreten wird, soll automatisch die Wiedergabe der Tagesschau in 100 Sekunden erfolgen, jedoch nur unter bestimmten Bedingungen (Conditions):

• Die Wiedergabe soll ausschließlich nach einer vordefinierten Uhrzeit erfolgen. In diesem Beispiel wird der Zeitpunkt nach 05:30h gewählt.

  - condition: time
    after: '05:30:00'

• Die Wiedergabe soll nur einmal am Tag erfolgen und nicht jedes mal, wenn die Küche betreten wird. Dafür wird auf das Attribute last_triggered der Automation zurückgegriffen, wie im Homeassistant Forum beschrieben:

  - "{{ state_attr('automation.wecker_tagesschau_auto_play', 'last_triggered') | default(today_at(), true) < today_at('05:30') }}"

Code für Automation

Der Code für die beschriebenen Bedingungen sieht folgender Maßen aus. Er stellt zusätzlich noch eine annehmbare Lautstärke für den Bose Soundtouch ein, damit man in aller Früh nicht zu laut beschallt wird:

- alias: Wecker Tagesschau auto play
  initial_state: True
  trigger:
    - platform: state
      entity_id: binary_sensor.hue_motion_kueche
      to: 'on'
  condition:
    - condition: time
      after: '05:30:00'
    - "{{ state_attr('automation.wecker_tagesschau_auto_play', 'last_triggered') | default(today_at(), true) < today_at('05:30') }}"
  action:
    - service: media_player.play_media
      data:
        entity_id: media_player.soundtouch_kueche
        media_content_id: 4
        media_content_type: PLAYLIST
    - service: media_player.volume_set
      data:
        entity_id: media_player.soundtouch_kueche
        volume_level: 0.4

Optimierungen

Dieser Code funktioniert eigenständig, kann natürlich aber noch optimiert und den eigenen Bedürfnissen angepasst werden. Wer beispielsweise nur unter der Woche am Morgen mit einem Newsflash begrüßt werden will und am Wochenende seine Ruhe haben möchte, kann auf die Workday Integration zurückgreifen und diese als eine weitere Bedingung hinzufügen:

- condition: state
  entity_id: binary_sensor.workday_sensor
  state: 'on'

Viele IoT-Geräte funken ihre Daten über Bluetooth LE. Um diese ins Smarthome integrieren zu können benötigt man ein Gerät mit Bluetooth-Schnittstelle, das als Broker fungiert. Ich nutze dafür seit Jahren zuverlässig einen Raspberry Pi Zero, der in Anbetracht des schlichten Abfangens und Weiterleitens von Paketdaten, unterfordert und überdimensioniert ist. Ein solches Bluetooth Hub lässt sich mittels eines ESP32 und ESPHome mit deutlich geringerem Stromverbrauch und Konfigurationsaufwand realisieren.

Umgezogen werden bei mir die folgenden Bluetooth Sensoren, die nun vom ESP32 ausgelesen und an Homeassistant weitergereicht werden:

• Xiaomi Mithermometer
• Xiaomi Miscale v1
• Xiaomi Miflora Pflanzensensoren

Vorraussetzungen

Benötigt werden:

• ESP32 bspw. die Variante ESP32 D1 Mini, die ich für dieses Projekt verwendet habe
• ESPHome Add-On für Hass.io
• Chrome bzw. Edge Browser oder ESPHome Flasher zum einmaligen flashen der Firmware

Konfiguration

ESPHome Add-On

Im ersten Schritt muss das ESPHome Add-On installiert, aktiviert und gestartet werden. Anschließend kann über SMB oder das VS-Code-Add-On eine Datei namens secrets.yaml angelegt werden, in der alle sensitiven Daten, wie WiFi-Passwörter oder Atomraketenstartcodes hinterlegt werden können. Diese Einträge können mittels Variablen bei der Konfiguration verwendet werden.

Die Datei muss im Pfad ./config/esphome/secrets.yaml erstellt und kann anschließend diesem Schema und Beispieleinträgen gefüllt werden:

wifi_ssid: LanSolo
wifi_passwd: Wurstjunge12
ota_passwd: S4mtpf0te
ap_passwd: GoBBerw4rz3

Nach der Anlage der Datei, kann diese auch direkt aus dem ESPHome Dashboard in Homeassistant editiert werden. Dafür steht das Schlosssymbol neben dem Button SECRETS zur verfügung:

Damit ist die Basis geschaffen, um die Konfiguration des Microcontrollers anzulegen. Im ESPHome Dashboard wird mit einem Klick auf das (+)-Icon eine neue Node erzeugt. So heißen die einzelnen eingebundenen Microcontroller, auf denen ESPHome läuft.

MiFlora Pflanzensensoren

Benötigt wird lediglich die MAC-Adresse des Sensors, um die Daten zu empfangen. In Firmwareversionen vor 2.3.1 sendeten die Pflanzensensoren noch ihren Batteriestand. Dies ist mit neueren Firmwares leider nicht mehr möglich.

Eine Beispielkonfiguration:

- platform: xiaomi_hhccjcy01
  mac_address: "C4:7C:23:69:63:08"
  temperature:
    name: "Vietnamchili Temperature"
  moisture:
    name: "Vietnamchili Moisture"
  illuminance:
    name: "Vietnamchili Illuminance"
  conductivity:
    name: "Vietnamchili Soil Conductivity"

Ein kleiner Tipp noch zum Troubleshooting:
Meine Sensoren liefen auf der Firmware 2.7.0. Damit konnten nicht zuverlässig Werte empfangen werden. Man kann die Firmware der Sensoren leicht mit der App Flower Care (Android / iOS) updaten. Die App setzt jedoch einen Account bei Xiaomi voraus.

MiScale v1

Für die Waage von Xiaomi sollte der ESP32 das aktuelle Gewicht auslesen und zeitgleich noch einen weiteren Sensor für den BMI berechnen und an Homeassistant Senden. Die Berechnung des BMI hatte ich zuvor on Homeassitant mit einem Template Sensor gelöst. Diese Aufgabe kann nun der Mikrocontroller übernehmen. Auch für die Waage muss die MAC-Adresse bekannt sein:

- platform: xiaomi_miscale
  mac_address: 'C4:3F:13:E0:AC:82'
  weight:
    id: "miscale_weight"
    name: "Miscale Weight"
    icon: mdi:scale-bathroom
    accuracy_decimals: 1
    on_value:
      then:
        - lambda: |-
            const float bmi_factor = 0.29860551;
            return id(miscale_bmi).publish_state(x * bmi_factor);
    
- platform: template
  id: "miscale_bmi"
  name: "Miscale BMI"
  icon: mdi:human-pregnant
  unit_of_measurement: ""
  accuracy_decimals: 1

Diese Konfiguration enthält zwei Sensoren für Gewicht und BMI. Wird das Gewicht ausgelesen erfolgt automatisch die Berechnung des BMI. Der Faktor 0.29860551 muss gemäß der eigenen Körperwerte angepasst werden und setzt sich aus dem Kehrwert des Quadrats der Körperhöhe [m] zusammen:

$$BMI = \frac{m}{h^{2}} = m \times \frac{1}{h^{2}}$$

Tipp zum Abschluss:
Für die Xiaomi Waage gibt es eine Custom Component, die es erlaubt mehrere Benutzer zu tracken und einen erweiterten Fundus an generierten Fitnessdaten liefert.

Mithermometer

Auch die Mithermometer lassen sich einfach über die MAC-Adresse einbinden. Am einfachsten lassen sie sich auslesen, wenn man den Advertising Type auf den Wert Custom setzt. Wie das geht, habe ich in dem ursprünglichen Post zu dem Thermometer bereits beschrieben. Dort wurde jedoch der Funkstandard (Advertising Type) ATC1441 genutzt. Im gleichen Menü kann der Standard gewechselt werden.

Ein Konfiguration für ESPHome sieht dann wie folgt aus:

- platform: pvvx_mithermometer
  mac_address: "A6:C3:23:E0:A8:42"
  temperature:
    name: "Mithermometer Kueche Temperature"
  humidity:
    name: "Mithermometer Kueche Humidity"
  battery_level:
    name: "Mithermometer Kueche Battery Level"
  battery_voltage:
    name: "Mithermometer Kueche Battery Voltage"

Vollständige ESP32 Konfiguration

Nun müssen nur noch alle drei Teilkonfigurationen zusammengeführt, kompiliert und auf den Mikrocontroller geflasht werden. In dieser Konfiguration können die Variablen aus der secrets.yaml verwendet werden. Eine vollständige Konfiguration könnte wie folgend aussehen. Wichtig ist, dass ggf. der Eintrag im Feld board: angepasst wird, wenn eine abweichende Variante vom ESP32 verwendet wird.

Der Platzhalter YOUR_GENERATED_ID muss durch eine selbstgenerierte ID ersetzt werden. Diese kann direkt auf der ESP Home Webseite erzeugt und kopiert werden.

esphome:
  name: esp32-btle-hub
  comment: ESP32 Bluetooth LE Hub

esp32:
  board: esp32dev
  framework:
    type: esp-idf

# Enable logging
logger:

# Enable Home Assistant API
api:
  encryption:
    key: "YOUR_GENERATED_ID"

ota:
  password: !secret ota_passwd

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_passwd
  fast_connect: true

  # Enable fallback hotspot (captive portal)
  # in case wifi connection fails
  ap:
    ssid: "Btle-Hub Fallback Hotspot"
    password: !secret ap_passwd

captive_portal:

esp32_ble_tracker:

sensor:
  # XIAOMI MISCALE
  - platform: xiaomi_miscale
    mac_address: 'C4:3F:13:E0:AC:82'
    weight:
      id: "miscale_weight"
      name: "Miscale Weight"
      icon: mdi:scale-bathroom
      accuracy_decimals: 1
      on_value:
        then:
          - lambda: |-
              const float bmi_factor = 0.29860551;
              return id(miscale_bmi).publish_state(x * bmi_factor);

  - platform: template
    id: "miscale_bmi"
    name: "Miscale BMI"
    icon: mdi:human-pregnant
    unit_of_measurement: ""
    accuracy_decimals: 1

  # XIAOMI THERMOMETER
  - platform: pvvx_mithermometer
    mac_address: "A6:C3:23:E0:A8:42"
    temperature:
      name: "Mithermometer Kueche Temperature"
    humidity:
      name: "Mithermometer Kueche Humidity"
    battery_level:
      name: "Mithermometer Kueche Battery Level"
    battery_voltage:
      name: "Mithermometer Kueche Battery Voltage"

  # XIAOMI MIFLORA PLANT SENSOR
  - platform: xiaomi_hhccjcy01
    mac_address: "C4:7C:23:69:63:08"
    temperature:
      name: "Vietnamchili Temperature"
    moisture:
      name: "Vietnamchili Moisture"
    illuminance:
      name: "Vietnamchili Illuminance"
    conductivity:
      name: "Vietnamchili Soil Conductivity"

Dieser Code muss im ESPHome Add-On im Editor zur Node eingegeben, gespeichert und kompiliert werden.

Firmware flashen

Im ESPHome Add-On gibt es mehrere Möglichkeiten eine Firmware auf den ESP32 zu installieren:

Der einfachste Weg ist die erste Option den Mikrocontroller direkt aus dem Browser heraus zu flashen. Voraussetzung dafür ist der Browser Chrome oder Edge. Mit Firefox klappt es nicht.

Ich nutze immer die letzte Option des manuellen Downloads und lade die Firmware herunter und flashe sie anschließend mit dem ESPHome Flasher. Dieser Vorgang muss nur einmal erfolgen, da Nodes später Over-The-Air geupdated werden können.

Ist der Flashvorgang erfolgreich durchlaufen wird der ESP32 automatisch neu starten.

ESP32 Node in Hass einbinden

Homeassistant erkennt nach dem erfolgreichen Flashvorgang den ESP32 automatisch und bietet an diesen zu integrieren. Beim initialen Verbinden mit dem Controller muss dann das definierte Passwort, welches in der Variable !secret api_passwd hinterlegt ist, eingegeben werden. Anschließend stehen alle Sensoren in Homeassistant zur Verfügung.

Sollte die automatischer Erkennung der Node nicht klappen, kann diese auch manuell eingebunden werden indem man im Menü Configuration > Devices & Services den Button Add Integration klickt und dort den Eintrag ESPHome auswählt.

iOS Actions sind eine Funktion von Homeassistant, die speziell für das iOS-Ökosystem genutzt werden kann. Im Kern ähneln sie den Actionable Notification, wobei letztere - unabhängig davon, ob man die Homeassistant Companion App auf dem Smartphone installiert hat - genutzt werden können, wie in dem Post Homeassistant, Actionable Notifications und Appdaemon über Appaemon Notifications bereits beschrieben wurde.

iOS Actions können nach initialem Setup in der iOS Shortcuts App und auch auf der Apple Watch genutzt werden. Wie dies einfach möglich ist, möchte ich in diesem Post zeigen.

Das Vorgehen

Für mein Setup definiere ich alle iOS Actions direkt in Homeassistant. Wird eine dieser Actions ausgeführt, bspw. über einen Shortcut oder einen Tap auf der Apple Watch, wird auf dem Eventbus von Homeassistant ein Event mit dem Namen ios.action_fired gefeuert. Diesen fange ich mit einer Appdaemon App ab und weise in der App an, welche Action erfolgen soll.

Konfiguration Homeassistant

In der configuration.yaml muss zuerst die iOS-Integration aktiviert werden. Da ich ungern meine configuration.yaml zumülle habe ich im ersten Schritt im Ordner ./config/ eine Datei mit dem Namen ios.yaml angelegt und diese anschließend so in der configuration.yaml eingebunden:

ios: !include ios.yaml

In der Datei ios.yaml habe ich vier Einträge eingefügt, die für diesen Post als Beispiel herhalten sollen:

actions:
  - name: blind_toggle
    background_color: "#000000"
    label:
      text: "Rollo"
      color: "4BA7EE"
    icon:
      icon: blinds
      color: "#ffffff"
  - name: sleepmode
    background_color: "#000000"
    label:
      text: "Schlafmodus"
      color: "4BA7EE"
    icon:
      icon: bed
      color: "#ffffff"
  - name: christmastree
    background_color: "#000000"
    label:
      text: "Weihnachtsbaum"
      color: "4BA7EE"
    icon:
      icon: pine-tree
      color: "#ffffff"
  - name: cast_toggle
    background_color: "#000000"
    label:
      text: "Chromecast"
      color: "4BA7EE"
    icon:
      icon: cast
      color: "#ffffff"

Entscheidend sind an dieser Stelle die Namen der Actions in den Einträgen name:, da diese auf dem Eventbus abgefangen werden müssen.

Erläuterung Beispiele

Ist diese Einrichtung erfolgt, muss Homeassistant neugestartet werden. Anschließend stehen diese Actions bereits in der Companion App, der Watch App und der iOS Shortcuts App zur Verfügung, können aber zu dem jetzigen Zeitpunkt noch keine Actions ausführen.

Screenshots

Apple Watch Companion App

iOS Shortcut App

Konfiguration Appdaemon

Damit die vier Beispiele auch Aktionen ausführen können, bspw. das Rollo oder den Weihnachtsbaum schalten, nutze ich Appdaemon. Dazu muss im ersten Schritt die Datei ./config/appdaemon/apps/iosactions.py angelegt werden und folgendes in diese geschrieben werden:

import appdaemon.plugins.hass.hassapi as hass

class iOSActions(hass.Hass):
    def initialize(self):
        self.listen_event(self.handle_event, "ios.action_fired")

    def handle_event(self, event_name, data, kwargs):
        if data['actionName'] == 'blind_toggle':
            self.call_service("cover/toggle", entity_id = "cover.rollo_schlafzimmer")
        elif data['actionName'] == 'sleepmode':
            self.call_service("script/turn_on", entity_id = "script.schlafzimmer_readytosleep")
        elif data['actionName'] == 'christmastree':
            self.call_service("light/toggle", entity_id = "light.wled")
        elif data['actionName'] == 'cast_toggle':
            self.call_service("switch/toggle", entity_id = "switch.schlafzimmer_steckdose_cast")

Diese Appdaemon App lauscht kontinuierlich nach dem Event ios.action_fired. Ist ein solcher Event erkannt, wird anschließend nach dem actionName gesucht und die zugewiesene Action ausgeführt. Die App muss im letzten Schritt noch für Appdaemon zugänglich gemacht werden. Dazu muss in der Datei ./config/appdaemon/apps/apps.yaml der folgende Eintrag hinzugefügt werden:

# Handling iOS Actions
iOSActions:
  module: iosactions
  class: iOSActions

Nach dem Speichern registriert Appdaemon automatisch die neue Konfiguration. Anschließend können die iOS Actions genutzt werden.

Tipp zum Abschluss

iOS erlaubt auf dem iPhone unter Einstellungen > Bedienungshilfen > Tippen > Auf Rückseite tippen die Möglichkeit einen Shortcut direkt mit einem Doppel- oder Dreifachtipp auf die Rückseite des iPhones auszuführen. Da die iOS Shortcut App auch auf die iOS Actions zugreifen kann, kann man also auch mit einem Doppeltipp auf die Rückseite seinen Weihnachtsbaum ein- oder ausschalten.

Viel Spaß damit!

Da sich das jährliche Weihnachtsfest nähert möchte ich in diesem Post zeigen, wie ich WLED für meinen Weihnachtsbaum nutze und in Homeassistant einbinde.

Verwendete Hardware

Herzstück meines Setups ist ein QuinLED Dig Uno, der mit einem ESP8266 bestückt ist und die angeschlossenen LED-Strips steuert. Auf den ESP8266 wurde widerum WLED geflasht. Ich habe dabei auch 5V-LED-Strips des Typs WS2811 gesetzt. Es gibt diese auch in 12V-Varianten, was dann aber in der Wahl des Netzteils berücksichtigt werden muss. Der QuinLED Dig Uno kann sowohl 5V, als auch 12V LEDs steuern.

Setup

QuinLED Dig Uno

Nachdem der QuinLED Dig Uno korrekt mit den LED-Strips, dem Adapter und dem Netzteil verdrahtet ist, liefert er automatisch die nötige Betriebsspannung für den aufgesetzten ESP8266. Dieser muss zunächst mit dem WLan verbunden werden. Die vorgefertigten Bausätze haben bereits WLED installiert und müssen nur mit dem Netzteil verbunden werden. Anschließend erzeugt WLED einen Access Point mit dem man sich verbinden und die Zugangsdaten für das Heimnetz eintragen kann. Es sollte eine statische IP-Adresse zugewiesen werden.

WLED in Homeassistant Integrieren

In Homeassistant kann unter Configuration > Devices & Services über den Button Add Integration WLED hinzugefügt werden. Homeassistant erkennt im Idealfall direkt automatisch das neue Gerät im Netzwerk. Alternativ kann manuell die zuvor vergebene statische IP angegeben werden.

In meiner Kofiguration wurde folgender Entity-Name für WLED eingerichtet: light.wled. Dieses wird für die anschließenden Beispiele verwendet.

Lovelace Custom Card

Über HACS sollte die custom-vertical-stack-in-card installiert werden. Sie sorgt dafür, dass man mehrere Cards ohne visuellen Abstand zueinander Stapeln kann. Unterschiedliche Lovelace-Cards erscheinen in der UI dann als eine zusammengehörige Card.

Ich verwende für meinen Weihnachtsbaum eine Picture Glance Card. Diese hat den Vorteil, dass ich direkt auf das Bild klicken kann, um den Baum mittels light.toggle ein und auszuschalten. Zusätzlich kann im Footer der Karte mit einem Klick der more-info-Dialog für WLED aufgerufen werden, der eine detailliertere Auswahl der Farben und Effekte erlaubt

Die Card hat des Weiteren noch eine Listenauswahl für Effekte, die in WLED als Preset festgelegt wurden und zwei weitere Slider für die Intensität und die Geschwindigkeit des gewählten Effekts.

Hintergrundbild

Als Hintergrundbild für die Picture Glance Card muss das folgende Bild über Speichern unter im Homeassistant Config-Pfad gespeichert werden.

Im folgenden Beispiel nutze ich dafür den Pfad ./config/www/entitypictures/weihnachtsbaum.jpeg

Code für die Card

Der folgende Code erzeugt die oben dargestellte Card:

type: custom:vertical-stack-in-card
cards:
  - type: picture-glance
    image: /local/entitypictures/weihnachtsbaum.jpeg
    tap_action:
      action: toggle
    entities:
      - entity: light.wled
        tap_action:
          action: more-info
    entity: light.wled
    title: Weihnachtsbaum
  - type: entities
    entities:
      - entity: select.wled_preset
        name: Preset
      - entity: number.wled_intensity
      - entity: number.wled_speed

Advanced Lovelace Card

Alternativ kann der Footer direkt mit weiteren Presets versehen werden, die sich mit einem Klick direkt aktivieren lassen ohne vorher in das Dropdown Menü wechseln zu müssen. Die Sache hat einen Haken und erfordert ein wenig kreatives Umdenken. Als Entities können nur bereits existierende Entities eingebunden werden. Die Picture Glance Card biete leider keine Möglichkeit ein Platzhalter zu platzieren.

Ein Umweg:
Man kann auf schnellem Wege ein paar Scenes unter Configuration > Automations & Scenes anlegen und ein Icon zuweisen, dass dem Effekt entspricht. Als Gerät wird dann einfach light.wled angegeben. Diese Scenes dienen nur als Icons im Footer. Bei einem Klick werden sie nicht aktiviert, sondern stattdessen ein dedizierter Service Call ausgeführt. Die Karte sieht dann so aus:

Code

Wichtig:
Im Service Call muss als option der exakte Name des Presets aus der WLED-UI gewählt werden. Die Namen können unter den Developer Tools eingesehen werden, wenn man nach der Entity select.wled_preset sucht und diese anklickt.

type: custom:vertical-stack-in-card
cards:
  - type: picture-glance
    image: /local/entitypictures/weihnachtsbaum.jpeg
    entity: light.wled
    title: X-Mas
    tap_action:
      action: toggle
    entities:
      - entity: scene.wled_running
        tap_action:
          action: call-service
          service: select.select_option
          service_data:
            entity_id: select.wled_preset
            option: 1 Running XMas
      - entity: scene.wled_fireflicker
        tap_action:
          action: call-service
          service: select.select_option
          service_data:
            entity_id: select.wled_preset
            option: 2 Fireflicker
      - entity: scene.wled_flow
        tap_action:
          action: call-service
          service: select.select_option
          service_data:
            entity_id: select.wled_preset
            option: 3 Flow
      - entity: scene.wled_lake
        tap_action:
          action: call-service
          service: select.select_option
          service_data:
            entity_id: select.wled_preset
            option: 4 Lake
      - entity: scene.wled_colorwinkles
        tap_action:
          action: call-service
          service: select.select_option
          service_data:
            entity_id: select.wled_preset
            option: 5 Colorwinkles
      - entity: scene.wled_saw
        tap_action:
          action: call-service
          service: select.select_option
          service_data:
            entity_id: select.wled_preset
            option: 6 Saw
      - entity: light.wled
        tap_action:
          action: more-info
  - type: entities
    entities:
      - entity: select.wled_preset
        name: Preset
      - entity: number.wled_intensity
      - entity: number.wled_speed

Viel Spaß beim automatisieren des Weihnachtsbaums.

Lebt man in seiner Wohnung überwiegend allein, kann über Bewegungssensoren verlässlich ermittelt werden, in welchem Raum man sich aufhält. Wie das geht wurde bereits im Post über Room Based Presence erläutert. Schaut man einen Film oder hört ein Hörbuch, geschieht das über einen Media Player, der klar einem Raum zugeordnet ist. Verlässt man den Raum, in dem gerade eine Wiedergabe erfolgt, bspw. um eine Tüte Chips zu holen, kann der Media Player automatisch pausiert und beim Wiedereintreten in den Raum automatisch fortgesetzt werden.

Voraussetzungen

Für diese Automation wird der sensor.last_motion benötigt, der in dem Post über Room Based Presence ausgiebig erläutert wurde. Durch diesen Sensor weiß Homeassistant in welchem Raum man sich derzeit aufhält.

Room Based Presence mit Motion Sensoren

30.03.2020·Aktualisiert: 04.12.2025·637 Wörter·3 min

Zigbee Motion Sensor hass-variables

Wer im Eigenheim Bewegungssensoren installiert hat, kann schnell und einfach einen Sensor erstellen, der aufzeigt in welchem Raum die letzte Bewegung registriert wurde. Wie man diese Info sinnvoll nutzen kann, wird in diesem Post erläutert.

Es gelten die erläuterten Grundsätze, die im verlinkten Post erläutert wurden:

• Jeder Raum des Hauses benötigt einen Bewegungssensor
• Diese Automation funktioniert nur, wenn sich nur eine Person im Haus aufhält
• Es sollte ein input_boolean als Condition in der Automation verwendet werden für den Fall, dass mehrere Personen im Haus anwesend sind

Die Automation

Benötigt wird ein Media Player. In diesem Beispiel verwendete ich meinen Beelink GT-King Pro, der mit CoreElec geflasht wurde und das kostenlose Media Center Kodi ausführt. Wie man diesen Media Player mit CoreElec flasht, habe ich in diesem Post ausgeführt.

Beelink GT-King Pro und CoreELEC

01.02.2020·193 Wörter·1 min

media-player

Der Hersteller Beelink bietet mit dem GT-King Pro eine Streaming Box an, die sowohl mit Android als auch mit dem freie Media Center Kodi betrieben werden kann. Dieser Post beschreibt, wie man Kodi mittels dem CoreELEC Projekt installiert.

Der Media Player für dieses Beispiel hat den Namen media_player.beelink und befindet sich in meinem Wohnzimmer.

- alias: Kodi Auto Pause
  description: "Automatically pauses and resumes playback when living room is left or entered"
  trigger:
    - platform: state
      entity_id: sensor.last_motion
  condition:
    condition: and
    conditions:
      - condition: state
        entity_id: input_boolean.besuchermodus
        state: 'off'
      - condition: state
        entity_id: sensor.current_av_receiver_source
        state: 'Kodi'
  action:
    - service: >
        {% if not is_state("sensor.last_motion", "Wohnzimmer") and is_state("media_player.beelink", "playing") %}
          media_player.media_pause
        {% elif is_state("sensor.last_motion", "Wohnzimmer") and is_state("media_player.beelink", "paused") %}
          media_player.media_play
        {% endif %}
      data:
        entity_id: media_player.beelink

Erläuterung der Automation

Trigger

- platform: state
  entity_id: sensor.last_motion

Trigger ist der Sensor sensor.last_motion, der den Aufenthalt in Haus angibt. Ändert sich der Aufenthalt, werden zwei conditions geprüft.

Conditions

- condition: state
  entity_id: input_boolean.besuchermodus
  state: 'off'

Diese Condition prüft den State eines input_boolean, der von mir gesetzt wird, wenn Besuch anwesend ist. Für diesen Fall soll die Automation nicht ausgeführt werden.

- condition: state
  entity_id: sensor.current_av_receiver_source
  state: 'Kodi'

Diese Condition prüft, ob mein AV-Receiver auf den Eingang des Media Players geschaltet ist, damit die Automation nicht triggert, wenn ich bspw. über das Gerät Musik höre.

Action

- service: >
    {% if not is_state("sensor.last_motion", "Wohnzimmer") and is_state("media_player.beelink", "playing") %}
      media_player.media_pause
    {% elif is_state("sensor.last_motion", "Wohnzimmer") and is_state("media_player.beelink", "paused") %}
      media_player.media_play
    {% endif %}
  data:
    entity_id: media_player.beelink

Für die Action kommt eine service_template zum Einsatz, die basierend auf dem Zustand des sensor.last_motion und des Media Players media_player.beelink zwei Unterschiedliche Aktionen ausführt:

• Pause: Wenn eine Bewegung außerhalb des Wohnzimmers detektiert wird UND der Media Player gerade etwas abspielt
• Resume: Wenn eine Bewegung im Wohnzimmer detektiert wird UND der Media Player pausiert ist.

ControllerX ist ein mächtiges und sehr gut dokumentiertes Tool, um Zigbee-Eingabegeräte in Homeassistant zu verwenden. ControllerX greift dabei auf die Funktionalitäten von AppDaemon zurück und erlaubt es nahezu jedes auf dem Markt verfügbare Eingabegerät nahtlos mit Homeassistant zu verwenden.

Vorraussetzungen zur Nutzung

AppDaemon

AppDaemon ist essentiell für die Nutzung von ControllerX und steht als eigenes Add-On im Supervisor von Homeassistant zur Installation bereit. Ist die Installation erfolgt, muss das Add-On manuell gestartet werden.

Damit ControllerX und AppDaemon im Zusammenspiel funktionieren, muss zusätzlich die Datei appdaemon.yaml angepasst werden. Siehe dazu die ControllerX Dokumentation. Wichtig ist der Eintrag für app_dir, der Anweist in welchem Pfadd AppDaemon nach Anwendungen sucht.

HACS

HACS, kurz für Home Assistant Community Store, ist ein Appstore zur Erweiterung von Homeassistants Basisfunktionen.

ControllerX

ControllerX kann über HACS installiert und aktualisiert werden. Es wird unter dem Menüpunkt Automation gelistet und mit einem Klick auf Install installiert werden.

Zigbee-Hub

Ein Zigbee-Hub dient als Router für alle Zigbee-Geräte. Über diese Hardware wird jedes Gerät eingebunden und in Homeassistant als Entity zur Verfügung gestellt. Als Universalhub für alle Hersteller spreche ich eine klare Empfehlung für den Conbee 2 von Dresden Elektronik aus. Der Conbee 2 kann zusammen mit dem offiziellen deCONZ Add-On genutzt werden und stellt zum Pairing der Geräte eine Web UI namens Phoscon zur Verfügung. Über diese kann im Browser ein neues Gerät eingebunden, benannt und gruppiert werden.

Zigbee Events und der Event Bus

Im Herzen von Homeassistant schlägt der Event Bus. Jede Änderung eines States wird dort in einem fortlaufenden Stream dargestellt und im Recorder festgehalten. Nutzt man die deCONZ-Integration, kann explizit nach Events von Zigbee-Geräten gefiltert werden. Dazu muss unter DEVELOPER TOOLS > EVENTS in der Sektion Listen to Events im Eingabefeld deconz_event eingegeben und auf den Button Start listening geklickt werden. Für andere Integrationen als deCONZ sei auf die Docs von ControllerX verwiesen.

Drückt man nun einen Knopf an einem Zigbee-Eingabegerät, wie bspw. einem Aqara Button, erscheint - exemplarisch - eine Ausgabe im JSON-Format:

{
    "event_type": "deconz_event",
    "data": {
        "id": "button_wohnzimmer",
        "unique_id": "00:15:8d:00:01:e8:7f:26",
        "event": 1002,
        "device_id": "6f7383674eed4fb3b0aabca03e9a32e1"
    },
    "origin": "LOCAL",
    "time_fired": "2021-07-08T19:23:01.451187+00:00",
    "context": {
        "id": "89f14979b86490040adef6588e0789d8",
        "parent_id": null,
        "user_id": null
    }
}

Interessant für die Automationen sind die Daten im Objekt data: {}. Zur Erläuterung:

Die id und unique_id sind essentiell für die Nutzung des Geräts mit ControllerX. Mit einem der beiden Parameter kann jedes Gerät eindeutig ermittelt und der gesendete event_code zugeordnet werden. Dieser kann dann als Trigger für Aktionen benutzt werden. Per default verwendet ControllerX die id.

Controller einbinden

Nach der Installation von AppDaemon ist unter ./config/appdaemon/apps/ eine Datei namens apps.yaml verfügbar, in der alle Eingabegeräte konfiguriert werden.

Als einfaches Beispiel sei hier die Konfiguration für die Fernbedienung E1766 meines IKEA Fyrtur Rollos dargestellt, dem zuvor schon ein Post gewidmet wurde:

rollo_schlafzimmer:
  module: controllerx
  class: E1766CoverController
  controller: tradfri_open_close_remote
  integration: deconz
  cover: cover.rollo_schlafzimmer

Die einzelnen Konfigurationsparameter im Detail:

Eine große Stärke von ControllerX ist, dass jede vordefinierte Aktion überschrieben werden kann. Dabei wird unterschieden zwischen:

• mapping: Überschreibt die Grundfunktionen des Controllers komplett. Nicht definierte Events werden ignoriert.
• merge_mapping: Behält die Grundfunktionen und überschreibt nur bestimmte Events.

Beispielkonfigurationen

Da es dem Menschen zu gerne an Phantasie mangelt, möchte ich ein paar Beispiele präsentieren, wie ich Zigbee-Eingabegeräte in meinem Alltag nutze. Alle Beispiele zur Nutzung von ControllerX erfolgen unter der Verwendung der deCONZ-Integration und müssen ggf. angepasst werden, wenn ZHA oder Z2M verwendet werden.

Hue Dimmer Switch

In jedem meiner Räume hängt eine Hue Dimmer Switch. Sämtliche Lichter eines Raumes sind über die Phoscon App gruppiert und erscheinen als eine einzige steuerbare Entity in Homeassistant. Ich nutze die Dimmschalter zum Einschalten und Dimmen der Lampen und habe jeweils den Einschalt- und den Ausschaltknopf mit einem merge_mapping angepasst. Geändert wurden die folgenden Event Codes:

Der entsprechende Eintrag in der .config/appdaemon/apps/apps.yaml sieht dann folgendermaßen aus:

hue_dimmer_flur:
  module: controllerx
  class: HueDimmerController
  controller: flur_dimmschalter
  integration: deconz
  light: light.deconz_licht_flur
  merge_mapping:
    1000: # Click I
      - scene: scene.flur_hell
    1001: # Hold I
      - scene: scene.flur_gedimmt
    4001: # Hold O
      - service: script.turn_on
        entity_id: script.leaving_home

Aqara Buttons

Für kleines Geld können simple Buttons von Aqara erstanden werden. Diese gibt es jedoch in zwei unterschiedlichen Varianten:

In diesem Beispiel kommt die erste Variante mit 4 möglichen Aktionen zum Tragen und es werden alle Standardfunktion des Buttons mittels mapping überschrieben. Das zugewiesene Licht light.schlafzimmer_decke ist also nur ein Alibi-Eintrag, denn ein Licht wird in diesem Fall nicht direkt gesteuert.

button_schlafzimmer:
  module: controllerx
  class: WXKG11LMSensorSwitchLightController
  controller: button_schlafzimmer
  integration: deconz
  light: light.schlafzimmer_decke
  mapping:
    1002: # 1 Click
      - service: switch.toggle
        entity_id: switch.scene_schlafzimmer_nachtlicht
    1004: # 2 Clicks
      - service: switch.toggle
        entity_id: switch.schlafzimmer_steckdose_cast
    1005: # 3 Clicks
      - service: script.turn_on
        entity_id: script.schlafzimmer_readytosleep
    1006: # 4 Clicks
      - service: script.turn_on
        entity_id: script.sz_soundtouch_aus_1h

Das neu festgelegte Mapping der Events führt folgende Aktionen aus:

Aqara Magic Cube

Der Magic Cube ist ein merkwürdiges Gerät. Es hat so viel Funktionen, dass ich jedes mal nach fünf Minuten vergesse, womit ich sie belegt habe. Trotzdem lässt er sich wunderbar mit ControllerX verwenden. In diesem Fall wird aber nicht ein Event ausgelesen, sondern eine bereits interpretierte Geste (gesture), wie bspw. das Schütteln, Drehen oder das Schieben des Würfels verwendet. Den Magic Cube nutze ich für meine Lichter im Wohnzimmer und zur Steuerung meines Fernsehers und AV-Receivers.

Die Gestures und gewählten Aktionen im Detail:

Der zugehörige Eintrag in der .config/appdaemon/apps/apps.yaml lautet:

magiccube_wohnzimmer:
  module: controllerx
  class: MFKZQ01LMLightController
  controller: zauberwurfel_wohnzimmer
  integration:
    name: deconz
    type: gesture
  light: light.wohzimmer_esstisch
  mapping:
    1: # Shake
      - service: media_player.toggle
        entity_id: media_player.sony_bravia
    3: # Flip 90°
      - scene: scene.wohnzimmer_fernsehen
    4: # Flip 180°
      - scene: scene.wohnzimmer_chill
    6: # Double Tap on Surface
      - service: media_player.select_source
        data:
          entity_id: media_player.av_receiver
          source: "HDMI2"
    7: # Rotate Right
      - service: media_player.volume_up
        entity_id: media_player.av_receiver
    8: # Rotate Left
      - service: media_player.volume_down
        entity_id: media_player.av_receiver