na wenn du schon einen hast (für zigbee2mqtt als beispiel) dann kannst du den auch nutzen also externen auswählen und die bridge mit diesen verbinden . wenn du keinen hast so überhaupt keinen dann kannst du vom adapter dir einen erstellen lassen.. also internen .. dann die bridge mit diesen verbinden
TeamSpeak
Privat
The Members of this group are also core member of the teamspeak team.
Beiträge
-
X-Sense Adapter -
Timeot für "read repository" ändern.hab ich auch
das komische an der Meldung ist.. drücke cih PF5 zum reload ..gehts wieder ganz normal.
wechsel ich auf andere Maschiene (hab ja multihost), gehts da auch nicht
bis ich wieder PF5 drücke..
dann wieder schon.. meine Vermutung ist der WS aber validieren kann ich es nicht
-
TibberLink Adapterder Server wird wohl nicht erreichbar sein
-
Fehler bei Installation IOBroker unter LINUX Debiandas passt schon mal und jetzt noch das komplette LOG ..
und welche Distribution ?
-
Fehler bei Installation IOBroker unter LINUX DebianMoin, die Installation bricht ab mit Meldung:
nach welcher Anleitung ?
-
cod.m ZigBee Coordinator (PoE/non-PoE) - made in Germany -
"state ping pong" beim schalten (true->false->true) (Z2M)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
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..
-
"state ping pong" beim schalten (true->false->true) (Z2M)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
-
-
"state ping pong" beim schalten (true->false->true) (Z2M)"last seen"
wovon redet ihr wo soll das sein ??
der hier +
wird der nicht gesendet funktioniert device-watcher nicht richtig
-
"state ping pong" beim schalten (true->false->true) (Z2M)ist das eine HUE Lampe ??? da wurde die Verarbeitung umgestellt
