Neuer Installer und neuer Fixer: übersichtliche Oberfläche und `iob docker`

[FernetMenta]

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.

[FernetMenta]

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.

[FernetMenta]

@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?

[nevermind]

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 :)

[arteck]

"last seen"

wovon redet ihr wo soll das sein ??

der hier +

wird der nicht gesendet funktioniert device-watcher nicht richtig

[arteck]

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

[FernetMenta]

[nevermind]

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:

https://www.youtube.com/watch?v=Md6h4tV19GI

[FernetMenta]

wird der nicht gesendet funktioniert device-watcher nicht richtig

was meinst du mit device-watcher? last_seen hat jedenfalls nichts mit availablitiy zu tun.

[FernetMenta]

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.

[arteck]

@FernetMenta sagte:

last_seen hat jedenfalls nichts mit availablitiy zu tun.

das ist richtig aber inner halb von device-watcher wird es auch genutzt um den timeSelector zu füllen..anderes Thema

@FernetMenta sagte:

btw, hier haben die gearde was Ähnliches gefixt,

als Test Device ist da ein Tempfühler : WSDCGQ11LM der Sendet relativ viel.. kann antürlich auch Zufall als Test Device sein..