Homelab, Linux, JS & ABAP (~˘▾˘)~
 

Tag: zigbee2mqtt

Home Assistant

[Home Assistant] Zigbee Garagentoröffner

 , , , , , , , , ,

Wir haben zu unserem alten Haus auch eine alte Doppelgarage bekommen. Die Garage ist in einem Zustand, dass man sie eigentlich nur noch abreißen kann. Aufgrund des Alters ist sie so schmal, dass heute gängige Autos quasi gar nicht hineinpassen. Von den zwei Garagentoren ist immerhin eines elektrisch. Verbaut ist ein Genie Screw Drive Antrieb. Die Firma Genie gibt es heute noch, unser Modell ist aber sicher >30 Jahre alt und gibt es natürlich nicht mehr im Sortiment.

Das Tor öffnen kann man über einen Taster oder einer Fernbedienung. Dafür wurde zusätzlich noch ein Genie Radio Control Modul verbaut (der graue Kasten rechts neben der Steckdose). In der Steckdose ist praktischerweise der Garagentormotor angeschlossen. Und der weiße dünne Draht, der an dem Stromkabel nach rechts langläuft, führt zum Taster.

Die Fernbedienungen hatten mittlerweile beide das zeitliche gesegnet. Na gut, über eine sind wir auch mit einem Auto drübergefahren… 🙂

Interessanterweise gibt es den Dickert Handsender MAHS40-01 (10 Codierschalter) heute noch. Der Preis ist natürlich absolut lächerlich mit >30€.

Nach kurzer Recherche auf AliExpress habe mir daher lieber einen Zigbee Garagentoröffner gekauft für 13,08€.

Erheblich günstiger und nun kann die Garage auch in Home Assistant integriert werden. Erkannt wird der MANHOT Garage Door Opener in Zigbee2MQTT als Tuya TS603. Zwei Entitäten werden bereitgestellt, eine zum Öffnen und Schließen des Tores und eine weitere zeigt den aktuellen Status des Tores an.

Die Installation habe ich mir so einfach wie möglich gemacht. Einen Schönheitswettbewerb bei der Verkabelung gewinnt man in unserer abrissreifen Garage sowieso nicht mehr. Ich habe daher einfach den Draht vom Taster durchtrennt

und dann wieder mit zwei 3er WAGO Klemmen verbunden, sodass die Taster Funktion erhalten bleibt. Die WAGOs sind eigentlich etwas zu groß für den dünnen Draht, aber hatte gerade nichts Besseres zur Hand. Und auf eine Lüsterklemme hatte ich noch wenig Lust.

Das schwarze Kabel war bereits beim Zigbee Garagentoröffner beigelegt und habe ich in die verbliebenen freien WAGO Plätze gesteckt und mit dem anderen Ende in den Zigbee Schalter. Jetzt fehlte nur noch Strom und der Sensor für den Zustand des Tores (offen/geschlossen). Da ich die alte Verkabelung in der Aufputzdose nicht anrühren wollte, habe ich mir einfach einen 2-fach Steckdosenadapter genommen und für die 230v Stromversorgung des Schalters einen alten Stecker (mit viel zu langem Kabel), den ich irgendwo mal abgeschnitten hatte.

Jetzt noch den Sensor mit dem Zigbee Schalter verbunden und das andere Ende zum Tor geführt und drangeklebt (ja, das Tor müsste mal lackiert werden…).

Und das war es auch schon! Neben dem Taster und den Fernbedienungen kann das Tor nun auch via Home Assistant gesteuert werden.

An beiden Toren hatte ich bereits Tür/Fenster Kontaktsensoren, um einfach prüfen zu können, ob wir das Tor offen stehen lassen haben. Die Sensoren werden mit 2 x AAA-Batterien betrieben und müssen vermutlich alle 2-3 Jahre getauscht werden. Zumindest an einem Tor kann ich mir das jetzt aber sparen.

Eine geeignete Darstellung auf dem Dashboard fehlt mir allerdings noch.

    Home Assistant

    [Home Assistant] Offline detection for Zigbee2MQTT devices using the last_seen attribute

     , , , , , ,

    Activate the last_seen attribute via the Zigbee2MQTT interface. Go to Settings → Advanced → Last seen → Choose ISO_8601

    Per default, the last seen sensor is disabled for all Home Assistant entities. To enable the last_seen attribute for all devices, add the following lines via VS Code in homeassistant → zigbee2mqtt → configuration.yaml

    device_options:
  legacy: false
  homeassistant:
    last_seen:
        enabled_by_default: true

    Now you must either restart Home Assistant or activate the entity manually: Go to Settings → Devices & services → Entities and adjust your Filter like this:

    • Integrations: Select “MQTT”
    • Status: Select “Disabled”

    Then search for last seen, click on select all (right next to the filter button) and choose Enable selected in the context menu when clicking on the three dots in the top right corner.

    Now the last_seen entity values should be visible, and you can use this new entity to detect an offline device. For example, by using this blueprint or by creating a template sensor like it is described here (related YT video). 

    {% set result = namespace(sensors=[]) %}
{% for state in states.sensor | rejectattr('attributes.device_class', 'undefined') | selectattr('attributes.device_class', '==', 'timestamp') %}
    {% if 'last_seen' in state.entity_id and (states(state.entity_id) == 'unavailable' or ((as_timestamp(now()) - as_timestamp(states(state.entity_id))) > ((24 | int) * 60 * 60))) %}
        {% set result.sensors = result.sensors + [state.name | regex_replace(find=' last seen', replace='') ~ ' (' ~ relative_time(strptime(states(state.entity_id), '%Y-%m-%dT%H:%M:%S%z', 'unavailable')) ~ ')'] %}
    {% endif %}
{% endfor %}
{{ result.sensors | join('\n') | truncate(254, True) }}

    The template sensor can be put somewhere on your dashboard or used in an automation. Following the automation I’m using:

    alias: Notify when zigbee device goes offline using last_seen
description: ""
trigger:
  - platform: state
    entity_id:
      - sensor.offline_zigbee_devices
    from: null
    to: null
    for:
      hours: 0
      minutes: 10
      seconds: 0
condition: []
action:
  - service: notify.mobile_app_mi_8
    metadata: {}
    data:
      title: |-
        {% if not states('sensor.offline_zigbee_devices') %}
          All Zigbee Devices Online!
        {% else %}
          The following Zigbee Devices are offline:
        {% endif %}
      message: >-
        {% for entity in expand('sensor.offline_zigbee_devices') | map(attribute='entity_id') | list %} 
          {{ states(entity) }} 
        {% endfor %}
mode: single

    I also recommend excluding the last_seen sensors from the Logbook, because else the Logbook is flooded with changes. To do this, simply add the following lines in your configuration.yaml file:

    logbook:
  exclude:
    entity_globs:
      - sensor.*_last_seen
    Home Assistant

    [Home Assistant] Zigbee2MQTT device_class motion is now occupancy

     , , , , , , , ,

    After the last Zigbee2MQTT update to version 1.39.0, suddenly the motion sensors were missing in my auto-entities cards, which I use to display all motions sensors for specific areas.

    type: vertical-stack
title: Bewegungsmelder
cards:
  - type: custom:auto-entities
    card:
      show_header_toggle: false
      title: null
      type: entities
      state_color: true
    filter:
      include:
        - attributes:
            device_class: motion
          options:
            secondary_info: last-changed
          area: cellar
    sort:
      method: last_changed
      reverse: true

    When checking the changes included in the new Zigbee2MQTT version, I found the reason: https://github.com/Koenkk/zigbee2mqtt/pull/22896
    With this pull request, the device_class is motion is replaced with occupancy. After changing the device_class in the auto_entities config, the motions sensors are displayed again.

    Alternatively, you can switch the device_class back to motion, like it is described here. This would also bring back the old icon mdi:motion-sensor instead of mdi:home-outline.

    Home Assistant

    [Home Assistant] Zigbee2MQTT – ‘MAC channel access failure’ (225)

     , , , , , , ,

    Suddenly, some weeks ago, devices in my Zigbee network started to become sometimes unavailable and did not respond. This occurred at random times and on random devices. When checking the Zigbee2MQTT logs, it was flooded with MAC channel access failure error messages.

    When searching for this error message, this GitHub issue pointed me to the potential issue: Network Interferences (probably Wi-Fi). See also the official docs here.

    I have two ZigBee networks in parallel. One using ZHA and the Conbee II stick running on channel 20. And one using Zigbee2MQTT using a Sonoff ZBDongle-P (CC2652P) running on channel 11, which had the network issues. Without further investigation, I thought, let’s check what channel my own Wi-Fi is using and if it is on channel 11, simply change it to something else (which turned out to be a completely wrong approach). In my FritzBox router, the channel selection was configured as “auto”. So no specific channel set. That made sense to me, as the ZigBee issues randomly appeared, so perhaps only when the Wi-Fi switched to a channel, ZigBee was already using.

    Without further investigation, I simply set the Wi-Fi channel to 1, so that it does not interact with Zigbee channel 11 (just to mention it here again: this is completely incorrect!). But things got worse, instead of better.

    After reading this great blog post about building a stable Zigbee network and seeing the graph from Metageek about Wi-Fi and Zigbee channels, I noticed my issue…

    Wi-Fi Channel 11 <> Zigbee Channel 11

    By simply looking at the Metageethek graph, I understood why I made things even worse. My newly selected Wi-Fi channel 1 interfered directly with Zigbee2MQTT channel 11.
    SmartHomeScene is recommending the following channel settings in their blog post:

    • Zigbee channel 11, Wi-Fi channel 6 or 11
    • Zigbee channel 15, Wi-Fi channel 11
    • Zigbee channel 20, Wi-Fi channel 1
    • Zigbee channel 25, Wi-Fi channel 1 or 6

    So I tried switching my WI-FI to channel to 11, which should not interference with ZigBee channel 11. And yes, Zigbee2MQTT was now running fine, but suddenly the MAC channel access failure error messages appeared on ZHA. Seems like the ZHA ZigBee channel 20 was sill too close to WI-FI channel 11. So I thought, why not using a WI-FI channel, which is completely out of the ZigBee range. I switched my Wi-Fi from channel 11 to channel 13, and everything runs smooth since then. Finally, my ZigBee network is “rock solid”! 🙂

    Update 19.04.2024: The Zigbee network was now working without issues for a few days, but suddenly my ESP Devices started to drop off the WI-FI network… When searching, I found this blog post, where it’s recommended to avoid channel 12-14 when using ESP devices. As I didn’t want to get into conflict with the Zigbee network again, I changed the channel from 13 to 12 as a test. And after a few days, I can now say that Zigbee and ESP devices are running smoothly. Finally!