Danke für all diese Tests, du hast mehrere Dinge aufgedeckt, und es gibt mindestens einen Fehler auf unserer Seite. Ich gehe der Reihe nach vor.
1. Der Unterschied zwischen den beiden Aktionen
Im Code tun MQTT-Nachricht senden und Zigbee2mqtt-Nachricht senden genau dasselbe: Dein Text wird in den Variablenmotor gegeben und dann unverändert veröffentlicht. Der einzige Unterschied ist der verwendete MQTT-Client: Die MQTT-Aktion veröffentlicht auf den Broker, der im MQTT-Dienst konfiguriert ist, die Zigbee2mqtt-Aktion veröffentlicht auf die eigene Verbindung des Zigbee2mqtt-Dienstes (standardmäßig Mosquitto, das für Z2M reserviert ist, mqtt://localhost:1884).
Wenn dein Z2M außerhalb von Gladys mit deinem eigenen Broker läuft, geht die Zigbee2mqtt-Aktion also potenziell ins Leere: Niemand hört zu, und da das Protokoll auf debug steht, siehst du tatsächlich nichts. Du hast nichts übersehen. Auch zu beachten: Diese Aktion fügt keinen Präfix zigbee2mqtt/ hinzu, du musst das vollständige Topic zigbee2mqtt/relais_03/set schreiben — der Platzhalter gladys/my-topic ist irreführend, wir werden ihn korrigieren.
Kurz gesagt: In deiner Konfiguration bleibst du bei MQTT-Nachricht senden, das ist die richtige Wahl.
2. Das ×10 und der RangeError
Hier liegt es weder an Gladys noch an einem Z2M-Fehler: Es ist das Zigbee-Protokoll. Der ZCL-Befehl genOnOff.onWithTimedOff gibt ontime und offwaittime in Zehnteilen einer Sekunde auf einem 16-Bit-Ganzzahlwert an. Zigbee2MQTT macht also on_time × 10, und die Obergrenze ist 65535.
Mit anderen Worten: Das absolute Maximum sind 6553 Sekunden, also 1 Stunde 49 Minuten. Deine 3 Stunden werden nie in einem einzigen Befehl durchgehen, egal welchen Weg du nutzt. Deshalb ist dein 10800 auch mit der Zigbee2mqtt-Aktion gescheitert, zusätzlich zum Broker-Problem.
3. Variablen im Payload
Das Nachrichtenfeld akzeptiert Variablen, aber mit zwei wichtigen Einschränkungen:
- die Syntax ist
{{ }} (tippe {{ in das Feld, die Autovervollständigung erscheint), und die Variable muss von einer Aktion Letzten Zustand abrufen kommen, die vorher in einer früheren Gruppe platziert wurde;
- keine Berechnungen sind in diesem Feld möglich. Im Gegensatz zu
Wert festlegen oder Bedingungen gibt es hier keinen Formelmotor: {{0.0.last_value}}*3600 wird wörtlich als 3*3600 gesendet, nicht als 10800.
Und wenn die Variable nicht aufgelöst wird, wird sie durch eine leere Zeichenkette ersetzt, was ein kaputtes JSON wie {"state":"ON","on_time":,"off_wait_time":0} erzeugt — daher die Ablehnung auf der Z2M-Seite. Wir sollten den tatsächlich veröffentlichten Payload klar loggen, das ist eine echte Debug-Lücke. In der Zwischenzeit, um zu sehen, was wirklich rausgeht:
mosquitto_sub -h <dein_broker> -t 'zigbee2mqtt/relais_03/set' -v
Um deine Multiplikation durchzuführen, musst du sie aus dem Payload herausnehmen: eine Aktion Wert festlegen im Formelmodus auf einem MQTT-Nummer-Feature (pompe_on_time), mit der Formel {{...}}*3600, dann ein Letzten Zustand abrufen auf diesem Feature, und schließlich {{x.y.last_value}} im JSON.
4. Achtung, ein Fehler auf unserer Seite bei den Formeln
Bei der Überprüfung dieses Punktes habe ich festgestellt, dass unser Formelmotor ohne die Funktion subtract instanziiert wird: die Subtraktion funktioniert nicht. Die Formel {{0.0.last_value}} - 5, die ich dir oben gegeben habe, wirft eine Ausnahme, die stillschweigend verschluckt wird (die Aktion scheitert, die Szene geht weiter, nichts passiert). Meine Entschuldigung, das war falsch.
In der Zwischenzeit ist die Umgehung, {{0.0.last_value}} + -5 zu schreiben, was funktioniert. +, *, /, round() und mod sind OK.
Ticket erstellt: Scene formula engine: subtraction is not supported (`Function subtract missing in provided namespace "math"`) · Issue #2823 · GladysAssistant/Gladys · GitHub
5. Was ich dir schließlich empfehle: Der Countdown + Watchdog
Angesichts der Obergrenze von 1 Stunde 49 Minuten kombiniert der beste Ansatz die beiden Ideen, und es ist sogar besser als das, was ich ursprünglich vorgeschlagen habe, weil es auch bei einem Gladys-Ausfall nicht kaputt geht.
Erstelle ein MQTT-Nummer-Feature pompe_minutes_restantes.
Szene „Pumpe starten“:
Wert festlegen: pompe_minutes_restantes = 180MQTT-Nachricht senden auf zigbee2mqtt/relais_03/set: {"state":"ON","on_time":900,"off_wait_time":0}
Szene „Pumpenüberwachung“, geplanter Auslöser im Intervall alle 10 Minuten:
Letzten Zustand abrufen von pompe_minutes_restantesWenn / Sonst auf > 0:
- dann:
Wert festlegen = {{0.0.last_value}} + -10, dann {"state":"ON","on_time":900,"off_wait_time":0} erneut veröffentlichen
- sonst:
{"state":"OFF"} veröffentlichen
Der Grundsatz: Das Relais erhält nie mehr als eine 15-Minuten-Genehmigung, die die Überwachungsszene so lange erneuert, wie der Countdown positiv ist. Das Ergebnis ist, dass die Pumpe sich nach maximal 15 Minuten von selbst ausschaltet, wenn Gladys für ein Update, einen Neustart oder einen Absturz abgeschaltet wird, und beim Neustart wird der Countdown dort fortgesetzt, wo er war, da er in der Datenbank gespeichert ist. Kein Warten mehr, und nichts mehr zu reparieren beim Booten.
Lass off_wait_time auf 0: Es ist eine Schutzzeit, während der das Modul neue Befehle on with timed off ablehnt, es würde die erneute Aktivierung verhindern.
6. Deine Überwachungsszene alle Minuten
Nicht nötig. Der NodOn meldet seinen Zustand an Z2M, wenn er sich selbst ausschaltet, also reicht eine Szene mit dem Auslöser Ein Gerät ändert seinen Zustand auf dem Feature des Relais, Bedingung „ist ausgeschaltet“, um dir deine Benachrichtigung am Ende zu senden.
Ich erstelle die Tickets für die fehlende Subtraktion, das Log des veröffentlichten Payloads und den Z2M-Topic-Placeholder.
https://github.com/GladysAssistant/Gladys/issues/2825
https://github.com/GladysAssistant/Gladys/issues/2826
! … Gladys? Nein, Claude 
