Home Assistant: Shelly Overheat Automation

Die kleinen, aber feinen, WLAN-Devices der Firma Allterco Robotics LTD, wir nennen sie im weiteren einfach Shelly’s, sind sehr kostengünstige und kleine Automaten um das ein oder andere in einem Haus oder einer Wohnung nachträglich ein wenig „Smarter“ zu machen.

Ich habe aktuell in Summe 6 Shelly-1PM Devices verbaut. Diese nutze ich zur Schaltung von Steckdosen als auch zum Monitoring des Stromverbrauches. Ich habe hinter den folgenden Steckdosen Shelly’s versteckt:

  • Waschmaschine
  • Trockner
  • Gefrierschrank
  • TV im Elternschlafzimmer
  • PC & Monitor im Büro
  • NAS, Drucker, PI’s und weiteren „Kleinkram“ im Büro

Für jedes dieser Geräte habe ich durch die Shelly’s die Möglichkeit, diese Stromlos zu schalten und den Verbrauch zu sehen. Ein weiteres schickes Goodie ist, dass sich die Shelly Geräte nahtlos in das Home-Assistant Energy Dashboard integrieren lassen.

Jedes Shelly-1PM-Gerät bringt eine Temperaturüberwachung mit sich. Sprich: Wenn das Gerät eine Überhitzung meldet, kann man sich in Home-Assistant einen entsprechenden Trigger dafür zu nutze machen. Und über genau das handelt dieser Beitrag. Das Ziel ist es, eine Automation zu entwickeln, die per Push-Nachricht über eine Überhitzung informiert und das entsprechende Gerät auch direkt abschaltet.

Die Automationsregel sieht im gesamten so aus:

- id: '1641376749153'
  alias: Shelly Overheat Alarm
  description: 'Wenn der Überhitzungssensor eines Shelly anschlägt (Meldeschwelle:
    30 sek) muss eine Nachricht verschickt und das entsprechende Gerät abgeschaltet
    werden'
  trigger:
  - type: problem
    platform: device
    device_id: 9fb6134cbd51000b05ab19672d330ec8
    entity_id: binary_sensor.shelly1pm_f2fe43_overheating
    domain: binary_sensor
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - type: problem
    platform: device
    device_id: cb1a31d8e19a6425abf4fc08b97b27ca
    entity_id: binary_sensor.shelly1pm_f272fa_overheating
    domain: binary_sensor
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - type: problem
    platform: device
    device_id: beac86fe6012511f081d8cd42283af78
    entity_id: binary_sensor.shelly1pm_f26bcb_overheating
    domain: binary_sensor
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - type: problem
    platform: device
    device_id: 3d2a8d2005ff8e88551177d1ba04ed62
    entity_id: binary_sensor.shelly1pm_f2fe84_overheating
    domain: binary_sensor
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - type: problem
    platform: device
    device_id: 6d44a4f9186de512cd5b9c6260c2a034
    entity_id: binary_sensor.shelly1pm_3c6105e545de_overheating
    domain: binary_sensor
    for:
      hours: 0
      minutes: 0
      seconds: 30
  - type: problem
    platform: device
    device_id: d8bcbec4f58943700d49e6eb54f22c86
    entity_id: binary_sensor.shelly1pm_e629bf_overheating
    domain: binary_sensor
    for:
      hours: 0
      minutes: 0
      seconds: 30
  condition: []
  action:
  - service: notify.all_house_members
    data_template:
      message: '{{ trigger.to_state.attributes.friendly_name }} reports high temperature:  {{
        states(trigger.entity_id | replace(''binary_sensor'', ''sensor'', 1) | replace(''_overheating'',
        ''_device_temperature'')) }}°C. Turning device off!'
      title: Shelly overheat alarm
      data:
        ttl: 0
        priority: high
  - service: switch.turn_off
    data_template:
      entity_id: '{{ trigger.entity_id | replace(''binary_sensor'', ''switch'', 1)
        | replace(''_overheating'','''') }}'
  mode: single

Was hier passiert ist folgendes:

Jedes mal wenn bei einer Shelly der Überhitzungsschutz triggert, wird mir auf mein Handy eine Nachricht ge-pushed. Diese Nachricht enthält sowohl das auslösende Gerät als auch die gemessene Temperatur des Gerätes. Als letzte Aktion wird das, an der Shelly „hängende“, Gerät zur Sicherheit abgeschaltet.

Der einzige Trick besteht hier darin, sich die Namensgebung der Shelly-Geräte zu nutze zu machen. In Home-Assistant hat jedes Gerät und jeder Sensor, also jede Entität, immer eine ID, eine Entity-ID. So hat der Binärsensor des Shelly-Gerätes das vor dem TV im Schlafzimmer hängt die Entity-ID:

binary_sensor.shelly1pm_f2fe43_overheating

Da die Trigger der Automationsregel diese Binärsensoren sind, ist es nicht so ohne weiteres Möglich an die Temperatur zu kommen. Das trigger-Objekt in einer Home-Assistant Automation ist immer das Objekt das getriggert hat. Hier eben eins aus der Klasse der Binärsensoren und diese geben keine Temperatur aus. Zum Glück hat der Entwickler der Shelly-Integration nach einem Namesschema gearbeitet:

[entity_klasse].[entity_id]_[fähigkeit]

Fähigkeit soll hier den Bezeichner darstellen der klarmacht um was für eine Entität es sich handelt. So bringt eine Shelly-1PM zwei Binärsensoren mit

  • Overheat-Sensor
  • Overpower-Sensor

Die [entity_klasse] ist jeweils binary_sensor. Die [fähigkeit] für den Overheat-Sensor ist overheating und die für den Overpower-Sensor ist overpowering.

So sehen zum Beispiel bei mir alle Entitäten des Schlafzimmer-TV-Shelly’s aus:

Die für mich interessanten Entitäten habe ich mir etwas freundlicheren Namen ausgestattet. Dieses Namensschema gilt für alle Entitäten, außer für den eigentlichen Switch. Dieser wird immer mit switch.[entitd_id] belegt.

Um beim Beispiel mit der Shelly vor dem Schlafzimmer-TV zu bleiben haben wir im trigger nun die folgende Entität zu Verfügung:

binary_sensor.shelly1pm_f2fe43_overheating

Da ich aber auch die aktuelle Temperatur haben möchte, muss ich dies über eine anderen Entität lösen. Die Temperatur steht in der Entität mit der Entity-ID:

sensor.shelly1pm_f2fe43_device_temperature

Um nun aus der Entity-ID des Binärsensors, die des Temperatursensors zu machen nutzen wir die Jinja2-Replace-Funktion:

{{ states(trigger.entity_id | replace(''binary_sensor'', ''sensor'', 1) | replace(''_overheating'', ''_device_temperature'')) }}°C

Wir ersetzen den String binary_sensor durch sensor und den String _overheating durch _device_temperature.

Das gleiche Prinzip wenden wir bei der Aktion zur Abschaltung des Gerätes an. Hier benötigen wir die Entität, die den Switch repräsentiert:

switch.shelly1pm_f2fe43

Auch hier wenden wir die Replace()-Funktion an:

{{ trigger.entity_id | replace(''binary_sensor'', ''switch'', 1) | replace(''_overheating'','''') }}

Home-Assistant: Ladestand von Batterie-Devices prüfen

Ich habe in meinem Haus recht viele batteriebetriebene Sensoren von Xiaomi verbaut:

  • Fenster- und Türsensoren
  • Luftfeuchtigkeitssensoren
  • Bewegungsmelder

Eine Problematik, die alle batteriebetriebenen Geräte gemein haben ist, irgendwann sind sie eben leer. Damit mir nun nicht die Batterie des Bewegungssensor an der Eingangstüre genau dann leer geht, wenn keiner zuhause ist und jemand einbricht, habe ich eine Automation erstellt die jede Nacht um 0 Uhr den Zustand aller batteriebetriebenen Geräte in meiner Home-Assistant Installation prüft.

Dazu pflege ich eine Gruppe eben all dieser Devices:

battery_entities:
  entities:
    - sensor.battery_xiaomi_attic
    - sensor.battery_xiaomi_bathroom
    - sensor.battery_xiaomi_bedroom
    - sensor.battery_xiaomi_hwr
    - sensor.battery_xiaomi_kitchen
    - sensor.battery_xiaomi_living
    - sensor.battery_xiaomi_maindoor
    - sensor.battery_xiaomi_office
    - sensor.battery_xiaomi_toilet
    - sensor.battery_xiaomi_fitness
    - sensor.battery_xiaomi_storage
    - sensor.battery_xiaomi_window_living_big
    - sensor.battery_xiaomi_window_living_small
    - sensor.battery_xiaomi_window_dining
    - sensor.battery_xiaomi_window_kitchen_side
    - sensor.battery_xiaomi_window_kitchen_front
    - sensor.battery_xiaomi_window_guest
    - sensor.battery_xiaomi_window_hwr
    - sensor.battery_xiaomi_window_bathroom_side
    - sensor.battery_xiaomi_window_bedroom_side
    - sensor.battery_xiaomi_window_bedroom_garden
    - sensor.battery_xiaomi_window_office_garden
    - sensor.battery_xiaomi_glasbs_living_big_right
    - sensor.battery_xiaomi_changing
    - sensor.battery_xiaomi_motion_bathroom

Zum Zugriff auf die Batterie-Informationen, benötigt es jedoch die Konfiguration eines Template-Sensors im Home-Assistant:

sensor:
  - platform: template
    sensors:
      battery_xiaomi_attic:
        friendly_name: 'Xiaomi Feuchtigkeitssensor - Spitzboden'
        value_template: "{{ states.sensor.humidity_158d0002fb487a.attributes.battery_level|default(-1)|int if states.sensor.humidity_158d0002fb487a is not none }}"
        unit_of_measurement: '%'

Ich bastel mir also für jedes Batterie-Device einen Sensor, packe den in die Gruppe und die Gruppe nutze ich wiederum zur Iteration in der Automatisierung.

Die Grundidee meiner Regel ist dabei die folgende:

Prüfe jede Nacht um 0 Uhr ob irgendein Gerät aus der Gruppe „battery_entities“, einen Ladestand von unter 10% hat. Sollte dieser der Fall sein, wird die Regel ausgeführt und ich suche mir in der „Action“ alle Geräte zusammen auf die diese „Condition“ zutrifft und packe diese in eine Mail an mich.

Die „Condition“ die ich dafür nutze sieht so aus:

condition: template
value_template: >-
  {{ states | selectattr('entity_id', 'in', state_attr('group.battery_entities', 'entity_id')) | map(attribute='state') | map('int') | select("lessthan", 10) | list }}

Die „Action“, so:

data_template:
  message: >
    The following devices reporting a low battery status: {% for item in
    expand('group.battery_entities') %}
      {%- if item.state | int < 10 %}
        {{ item.name }} ({{item.state}}%)
      {% endif %}
    {%- endfor %} Regards - Your Homie
  title: Homie - Report of battery devices with low energy
service: notify.homiemail

Alles zusammen gebracht, sieht dann so aus:

- id: CheckBatteryFromDevices
  alias: Check battery level of battery devices
  trigger:
  - platform: time
    at: 00:00:00
  condition:
  - condition: template
    value_template: '{{ states | selectattr('entity_id', 'in', state_attr('group.battery_entities', 'entity_id')) | map(attribute='state') | map('int') | select("lessthan", 10) | list }}'
  action:
  - data_template:
      title: Homie - Report of battery devices with low energy
      message: "The following devices reporting a low battery status: {% for item\
        \ in expand('group.battery_entities') %}\n  {%- if item.state | int < 10 %}\n\
        \    {{ item.name }} ({{item.state}}%)\n  {% endif %}\n{%- endfor %} Regards\
        \ - Your Homie\n"
    service: notify.homiemail

DIY: ZigBee Glasbruchsensor

Als stolzer Eigenheimbesitzer mit KNX, ich nenne es mal, Grundverkabelung (Licht, Heizung und Rollos) kamen relativ schnell, nach Fertigstellung des Bau’s, weitere „Dinge“ auf, die man gut Smart machen kann.

Ich selber, bin ein großer Fan von Home-Assistant. Hier kann man allerlei Technologien an einem Ort integrieren.

So habe ich diverse Steckdosen mit WLAN-Aktoren von Shelly versehen, oder Bewegungsmelder und Luftfeuchtigkeitssensoren von Xiaomi „verbaut“.

Für meine Partnerin ist einer der großen Vorteile eines Smart-Home, die Sicherheit die man erhöhen kann. So ist im Eingangsflur eine ONVIF-Kamera aufgestellt. Die Eingangstüre ist mit einem Bewegungssensor versehen und alle Fenster haben Öffnungssensoren. Alles ist zusammen verbunden und diverse Automations-Regeln feuern bei diversen Zuständen und alarmieren im Falle eines Einbruchs oder spielen Musik ab, schalten das Licht an oder fahren die Rollos runter.

Was mir hier jedoch noch fehlte, waren Glasbruchsensoren. Die Automatisierung erkennt, wenn wir nicht zuhause sind und jemand z.B. die Terassentüre aufmacht. Was aber nicht erkannt wird ist, wenn jemand die Scheibe einschlägt und durch die Scheibe in den Innenraum tritt.

Abhilfe schafft hier nur ein Glasbruchsensor. Da ich nichts gefunden habe was mir passt, dachte ich mir, kann man doch bestimmt auch selber bauen.

Meine Lösung, ist eine selbstgebaute Verbindung zwischen einem ABUS Glasbruchsensor passiv (GMB7300) und einem Xiaomi Aqara Fenstersensor.

Der Xiaomi Fenstersensor kommuniziert mittels ZigBee mit seiner Zentrale und diese Zentrale kann im Home-Assistant sehr einfach eingerichtet werden.

Der Sensor, im original, schaltet mittels Magnetschalter. Diesen Magnetschalter habe ich einfach mit einer Zange „abgeknipst“ und den Glasbruchsensor angelötet.

Ab jetzt schaltet der Glasbruchsensor die Kontakte und der Xiaomi Sensor meldet entsprechend weiter. Testen kann man das ganze indem man den Glasbruchsensor anbringt und mit einer Münze gegen die Scheibe „flitscht“ (einfach mal googeln).

Der ABUS Sensor hat knappe 15 EUR gekostet und der Aqara Sensor knappe 10. Somit hat man für 25 EUR einen funktionalen Glasbruchsensor der ohne große Probleme in die Home-Assistant Automatisierung eingebunden werden kann.

Disclaimer: Ich bin kein Elektriker oder Fensterbauer. Jeder ist für sein Handeln selber verantwortlich und natürlich kann diese Lösung keine Garantie auf Funktion geben, für mich selber passt es. Es muss eben nur jeder für sich selber entscheiden.