"state ping pong" beim schalten (true->false->true) (Z2M)
-
-
Kommt das Log von dem Test um den ich oben gebeten habe ?
-
Ist sichergestellt, das
-- niemand die Lampe in der Zeit davor geschaltet hat ?
-- es keine durchlaufendes Skript gibt, welches daten von Z2M per polling regelmässig abholt ?
-- die betroffene Lame nicht bestandteil einer Gruppe ist ? -
wie ist das Log von Z2M sortiert ? Leider fehlen die ms, so das ich nicht sehen kann welche der Meldungen neu oder alt sind
-
Was macht der Publish auf
'zigbee2mqtt/0-2'da drin ?
du darfst nicht vergessen - Du kennst den Kontext, und was du machst, ich sehe nur die Texte die du postest.
A.
Nachtrag: Wenn die Antwort auf die meisten / alle Fragen die ich gestellt habe ja ist, dann ist das Problem bei Zigbee2mqtt.io zu suchen - dein Log legt nahe das Z2M den falschen Status sendet, und der ioBroker den nur Anzeigt.
-
-
Kommt das Log von dem Test um den ich oben gebeten habe ?
Ich habe mich bemüht das so zu machen.
Ist sichergestellt, das ...
Alle meine Lichter sind in Gruppen, weil ich die auch mit FB bediene.
Was macht der Publish auf 'zigbee2mqtt/0-2' da drin ?
Weiß ich nicht. Da bin ich nicht tief genug drin.
Ich habe das gemerkt als ich ganz auf Lovelace umgestellt habe. Da tippe ich auf das UI, der Schalter geht an. Kurz darauf springt er wieder zurück und wieder auf an. Das war in meinem alten UI (Jarvis) nicht so. Darum kann ich auch nicht sagen, ob das neu ist oder schon immer so war.
-
Hier das z2m log aus dem logfile. Da steht etwas mehr als im Logfenster des UI.
-
Scheint wirklich ganz auf Seite z2m zu liegen. Auch wenn ich direkt in z2m schalte, prellt es. Vielleicht gibt es da drüben eine Einstelliung, die das verhindert.
-
Ich (mit KI) habe es eingegrenzt:
Wenn ein Device keinen ordentlichen defaultRespose mit Attributen schickt, sonder nur "ja, habe ich gemacht", und last_seen aktiv ist, sendet z2m eine Nachricht mit dem letzten Zustand.
Ich habe bei mir jetzt last_seen (settings - advanced) ausgeschaltet. -
last_seen sollte eigentlich default auf disabled stehen. HA sollte auch default auf false sein. Bei wir war beides enabled. Ich habe das eigentlich nie aktiviert. HA ganz bestimmt nicht. Hat sich wahrscheinlich mal ein Update verhaspelt.
-
@asgothian @arteck ich hatte last_seen, weil ich es aus dem getting started von hier übernommen hatte: https://github.com/arteck/ioBroker.zigbee2mqtt/blob/main/docs/DE/DE_get-started.md
Gibt es einen Grund, warum das hier aktiv ist, obwohl in z2m default disabled?
-
Hallo Zusammen
oh mann... ja, bei mir lag es scheinbar auch am "last seen". Hatte ich aktiviert um Probleme in meinem Zigbee-Netzwerk zu finden. Jetzt habe ich es wieder deaktiviert und das Pingpong, also die Meldung mit dem alten, vorherigen Status ist weg.
Vielen Dank :)
-
ich hab die Kiste (klaus) mal analysieren lassen
Da beide ack:true-Zeilen aus getrennten eingehenden Nachrichten stammen müssen, liegt die Ursache außerhalb des Adapters – bei Zigbee2MQTT bzw. dem Zigbee-Funkgerät selbst. Typische Erklärungen:
-
ListenpunktOptimistic Mode von Z2M (Standard: optimistic: true): Z2M published sofort nach dem Senden des Zigbee-Kommandos den erwarteten Zielwert – trifft danach noch ein reales reportAttributes-Frame vom Gerät mit einem kurzzeitig abweichenden Ist-Wert ein (z. B. weil der Schaltvorgang de facto etwas verzögert/mit Zwischenzustand abläuft), entstehen zwei Nachrichten kurz hintereinander.
-
ListenpunktBekanntes Relais-/Firmware-Verhalten bei Xiaomi/Aqara-Geräten (IEEE-Präfix 0x00158d0003... = Aqara): Manche Aqara-Steckdosen/Schalter senden beim Umschalten zwei onOff-Reports kurz hintereinander (Relais-Bounce bzw. internes Verifikationsverhalten), die Z2M 1:1 weiterreicht.
-
ListenpunktNetzwerk-/MQTT-Duplikate: Ein Zigbee-Mesh-Retry (kein App-Level-ACK erhalten → erneutes Senden) oder eine doppelte MQTT-Zustellung (QoS-Redelivery) kann ebenfalls zwei fast identische, aber leicht unterschiedliche Publishes erzeugen.
-
ListenpunktFalls advanced.last_seen bei dir aktiv ist, kann u. U. eine zusätzliche last_seen-only-Nachricht kurz vor/nach der echten state-Nachricht eintreffen – das erklärt aber nicht den Wertewechsel false→true, sondern höchstens den zeitlichen Abstand
-
-
-
Ja, was einfach strange ist, ist dass das deaktivieren von "last seen" in z2m das Problem behebt. Aber ja, liegt sicher nicht am Adapter. Ich habe mal noch ein kurzes Video gemacht:
-
wird der nicht gesendet funktioniert device-watcher nicht richtig
was meinst du mit device-watcher? last_seen hat jedenfalls nichts mit availablitiy zu tun.
-
btw, hier haben die gearde was Ähnliches gefixt, so dass solche Sachen mit debounce abgefangen werden können: https://github.com/Koenkk/zigbee2mqtt/commit/10611654c711ba2cd7c17b42effc01b66bdcb81d
Evtl sollte man das auch für den Pfad, der hier eine Rolle spielt ändern.
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden546
Online33.1k
Benutzende83.8k
Themen1.4m
Beiträge