Benachrichtigung bei Ist- und nicht bei Sollzustand auslösen (Rollos)

Hallo und frohes Neues!

Ich habe jetzt über eine Woche damit verbracht, den Heimassistenten einzurichten (Umzug von Tuya), 64 Geräte über Zigbee2MQTT, davon sind 33 Router, alles auf Raspberry PI 5 mit 8GB und Sonoff Dongle-E. Nach ein paar Stolpersteinen und dem letzten Feinschliff läuft jetzt alles bestens und genau so, wie ich es mir wünsche, nur an einer Sache beiße ich mir die Zähne aus:

Ich habe 3 Rollos mit Zigbee-Perlschnurantrieben, einer von MOES und 2 von einer anderen Firma, aber alle bau- und funktionsgleich. (AM43-0.45-40-ES-EB)

Wenn ein Rollo komplett geöffnet oder geschlossen wurde, lasse ich mir per Automation eine Benachrichtigung zukommen, nur leider werden diese Benachrichtigungen bereits ausgelöst, wenn ein Rollo anläuft und nicht, wenn es den finalen Zustand erreicht. Ich habe alle möglichen Kombinationen für jeweils Schließ-, Öffnungs- und Benachrichtigensautomationen probiert, über Gerät, Abdeckung, Entität, Zustand/Nummerischer Zustand, immer das gleiche Ergebnis, auch im Dashboard wird bereits die Endposition angezeigt, während das Rollo noch läuft. Ist es nicht möglich, die Benachrichtigung erst bei erreichtem Zustand auszulösen, ist es geräteabhängig oder übersehe ich etwas? Unter Tuya hat das bestens funktioniert, Zielposition nicht erreicht, gabs auch keine Benachrichtigung oder umgekehrt.

Hier mal die YAML-Codes

Schließautomation:

alias: SU WZ-Rollos ZU
description: ""
triggers:
  - trigger: sun
    event: sunset
    offset: 0
conditions: []
actions:
  - action: automation.trigger
    metadata: {}
    target:
      entity_id:
        - automation.zu_wz_rollo_r_ohne_ausloser
    data:
      skip_condition: false
  - action: scene.turn_on
    metadata: {}
    target:
      entity_id: scene.zu_wz_rollo_l
    data: {}
mode: single

Eingesetzte Schließszenen für jeweils Links und Rechts:

id: "1767536711976"
name: ZU WZ-Rollo-L
entities:
  cover.wz_rollo_l:
    current_position: 0
    friendly_name: WZ-Rollo-L
    supported_features: 15
    state: closed
icon: mdi:roller-shade-closed
metadata:
  cover.wz_rollo_l:
    entity_only: true
id: "1767536797361"
name: ZU WZ-Rollo-R
entities:
  cover.wz_rollo_r:
    current_position: 0
    friendly_name: WZ-Rollo-R
    supported_features: 15
    state: closed
icon: mdi:roller-shade-closed
metadata:
  cover.wz_rollo_r:
    entity_only: true

Benachrichtigungsautomation:

alias: 🌘WZ-Rollo-R ZU
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - cover.wz_rollo_r
    below: 1
conditions: []
actions:
  - action: notify.alle_geraete
    metadata: {}
    data:
      message: >-
        {{ now().strftime('%H:%M') }} Uhr, {% set weekdays = ['Sonntag',
        'Montag', 'Dienstag', 'Mittwoch', 'Donnerstag', 'Freitag', 'Samstag'] %}
        {{ weekdays[(now().weekday() + 1) % 7] }}, {{ now().strftime('%d.%m.%Y')
        }}
      title: "{{ this.attributes.friendly_name }}"
mode: single

Müsstest du nicht das Attribut “current_position” triggern?

trigger: numeric_state
entity_id:
  - cover.wz_rollo_r
attribute: current_position
below: 1
1 „Gefällt mir“

Auch das schon probiert, dann kommt garkeine Benachrichtigung, current_position kennt, glaube ich, nur Wortwerte wie closed, opened etc., für den nummerischen Stand dürfte einfach nur “position” verantwortlich sein. Wie gesagt, alle Kombinationen durchprobiert und mir raucht der Schädel, aber ich probiers nochmal. Langsam muß ich mein Testrollo auch mal wieder aufladen, nach dem ganzen Auf und Zu durch die Probierei. :laughing:

Wenn ich numeric_state durch current_position ersetze, gibt mir der visuelle Editor “Unbekannter Auslöser" aus.

Du sollst es nicht ersetzen, sondern ein Attribut hinzufügen. @maxe hat dir doch ein Beispiel geschrieben.

1 „Gefällt mir“

Achso, ja, gemacht, getan, ich blicke bei YAML leider noch nicht ganz durch. Gleiches Ergebnis, Benachrichtigung sofort, wenn das Rollo anfährt. Meiner Meinung nach sollte das eigentlich von Hause aus funktionieren, der Auslöser “Wenn Position erreicht ist" ist ja gesetzt und nicht "Löse aus, wenn Rollo Richtung Position X fährt”.

Guck doch mal über die Entwickler Werkzeuge, welchen Wert die gewünschte Position hat, z.b.

1 „Gefällt mir“

Zustand: closed

Position: 0

Hatte ich auch schon bei Zigbee2MQTT geschaut, alles korrekt und ich brauche ja auch nur die Positionen 0 und 100. Mir ist, als ob irgendwas in der Kette sofort bereits den Endzustand und keine Zwischenschritte übermittelt, sobald das Rollo nur losfährt und das löst das Problem aus.

Aber ich habe noch eine andere Idee, bei den Werten upper_limit und bottom_limit steht “Unbekannt", ich werde die Rollos mal über HA/Zigbee2MQTT neu kalibrieren, vielleicht löst das ja das Problem.

Edit: Das Setzen der Limits hat leider auch keine Veränderung gebracht.

Es scheint wohl wirklich an den Geräten und deren Übermittlung zu legen, wenn ich das Verhalten beim Öffnen und Schließen direkt bei einem Gerät in der Exposé-Ansicht beobachte, dort springt der Wert sofort auf die finale Position und wird wohl auch gleich als Status/Position an HA übermittelt, obwohl das Gerät noch läuft. Kann man wohl nix machen und ich werde damit leben müssen, obwohl mich wundert, das es unter Tuya funktioniert hat, ok, vielleicht fehlt etwas bei der Zigbee2MQTT Einbindung.

:crayon:by HarryP: Zusammenführung Doppelpost (bei Änderungen oder hinzufügen von Inhalten bitte die „Bearbeitungsfunktion“ anstatt „Antworten“ zu nutzen)

Ein Cover nimmt doch für gewöhnlich folgende Zustände an, damit meine ich nicht die Position, sonder den Zustand von cover.xyz

Diese kannst Du doch als Auslöser verwenden.
Wenn Dir keine Zustände zur Auswahl stehen, dann wahrscheinlich weil sie von der Integration nicht zur Verfügung gestellt werden. In dem Fall einfach die englische Entsprechung manuell eingeben. also Bsp. closed bzw. open

Gruß Osorkon

1 „Gefällt mir“

Ist mit den Zuständen leider genau das Gleiche, auch diese werden vorzeitig durch Zigbee2MQTT übermittelt. Wie im Eingangspost geschrieben, ich habe bereits alle Kombinationen durchprobiert, auch die direkt bezeichneten Zustände.

Edit: Wenn man in den Entwickleroptionen beim Zustand eines Rollos noch während der Bewegung auf “Aktualisieren" klickt, springt die Angabe für Position und Zustand auch direkt auf die jeweilige Endposition, also identisch zum angezeigten Verhalten bei Zigbee2MQTT. Kann also HA nix für, sondern Zigbee2MQTT.

Ab das ein ZigBee2MQTT Problem ist, kann ich nicht beurteilen, da ich keine ZigBee Cover habe und je haben werde. Außerdem hat ZHA bei mir ZigBee2MQTT abgelöst. :grinning_face:

Zumindest arbeiten meinen Cover alle so, dass der Zustand in Home Assistant dem realen Zustand des Covers entspricht und nicht dem geplanten Soll Zustand.

Gruß Osorkon

Man bist du toll.
Wie hilft das jetzt den Fragesteller?

1 „Gefällt mir“

Nun ja, ich hatte anfangs natürlich auch ZHA ausprobiert, aber schon bei einem meiner zum Test gekoppelten Temperatursensoren war das kleinste Aktualisierungsintervall für je Temperatur und Luftfeuchtigkeit 5min, obwohl die 1min unterstützen und genau die brauche ich auch, ob man das noch hätte anpassen können, keine Ahnung, mein Metier ist es unter anderem, nicht ewig für alles rumfummeln zu müssen, es soll einfach funktionieren und unter Zigbee2MQTT werden alle Funktionen der Sensoren unterstützt. Meine BEOK TRV-705ZB Heizkörperregler hätten unter ZHA sicher nicht funktioniert, unter Zigbee2MQTT jedoch voll und ganz, wenn auch mit nicht nativer Integration. Aber wer weiß, vielleicht hätten ja dafür meine Rolloantriebe unter ZHA vollumfänglich funktioniert … Zum Glück ist es so, daß ich auf die (präzisen) Rollobenachrichtigungen auch verzichten kann, ist eher ein “Schön, es zu haben", dafür funktioniert ansonsten alles bestens mit HA und Zigbee2MQTT mit wesentlich mehr Funktionen, als unter Tuya. Selbst mein über Tuya-Local angebundenes Bluetooth-Türschloss funktioniert nach anfänglichen K(r)ämpen, die aber eher auf meiner Unwissenheit basierten, bestens.

Ich bin von Tuya weg, weil Tuya immer mehr Geräte rausschmeißt, die sich dann nicht mehr koppeln lassen, wenn man sie aus irgendwelchen Gründen mal entkoppeln mußte oder welche zur Reserve liegen hatte (z.B. Zwischenstecker braucht man immer wieder mal neue) und weil ich von der Cloud weg wollte, unter Zigbee2MQTT funktionieren jetzt wieder ein Türsensor und ein Bewegungsmelder, die unter Tuya nicht mehr wollten/durften.

Das ist für mich kein Zigbee Problem, sondern eher ein Problem des Antriebs. Du sendest das Signal zum Schließen und der Antrieb sendet sofort “geschlossen”. Das leitet Zigbee natürlich sofort weiter.

Wenn man das nicht in der Software des Antriebs einstellen kann, dann musst du leider damit leben.

1 „Gefällt mir“

Klar müsste ich damit leben, ist ja jetzt auch nicht so wichtig, wie gesagt, aber ich habs jetzt so gelöst: Ich lasse die Rollos erst auf 1 bzw. 99 Prozent fahren, der Wert wird dann auch erstmal vom Antrieb gemeldet, verzögere um Zeitraum X, welcher der Wert ist, den ein Rollo zum kompletten hoch- oder runterfahren braucht + ne Karenzsekunde und lasse dann auf 0 bzw. 100 Prozent fahren, dieser Wert wird dann wiederum gemeldet und kann von der Benachrichtigungsautomatik aufgegriffen werden. Funktioniert soweit nahtlos und einwandfrei. Sollte ein Rollo jedoch aus irgendwelchen Gründen unterwegs stehen bleiben, weil Akku leer oder so, wird letztendlich wohl trotzdem über die Endposition benachrichtigt, aber da denke ich mir nochwas aus über Bedingungen oder so.