Autor Thema: ERROR: cannot SEND_DATA to <Device>: transmit queue overflow  (Gelesen 2947 mal)

Offline throbin

  • Full Member
  • ***
  • Beiträge: 167
Morgen,

ich bekomme immer wieder die Fehlermeldung im Logfile zu sehen:
2016.05.25 06:34:33 2: ZWave set ZWave_SWITCH_MULTILEVEL_11 dim 99
2016.05.25 06:34:35 2: ZWave set ZWave_SWITCH_MULTILEVEL_12 dim 99
2016.05.25 06:34:43 2: ZWave set ZWave_SWITCH_MULTILEVEL_8 dim 99
2016.05.25 06:34:45 2: ZWave set ZWave_SWITCH_MULTILEVEL_7 dim 99
2016.05.25 06:34:47 2: ZWave set ZWave_SWITCH_MULTILEVEL_6 dim 99
2016.05.25 06:34:47 2: ERROR: cannot SEND_DATA to ZWave_SWITCH_MULTILEVEL_6: transmit queue overflow
2016.05.25 06:34:52 2: ZWave: No ACK from ZWave_SWITCH_MULTILEVEL_6 after 5s for set:1306032601632505
2016.05.25 06:34:54 2: ZWDongle_0 transmit NO_ACK for CB 05, target ZWave_SWITCH_MULTILEVEL_6

Ich sende Befehl set <device> dim 99 im Abstand von ca. 2 Sekunden für mehrere ZWave FIBARO FGR-222. Das Notify (ein Teilausschnitt) zum Absetzen der Befehle ist wie folgt definiert:
Alle_Rollos_Wohnzimmer:Auf set ZWave_SWITCH_MULTILEVEL_8 dim 99;sleep 2;set ZWave_SWITCH_MULTILEVEL_7 dim 99;sleep 2;set ZWave_SWITCH_MULTILEVEL_6 dim 99
Das Device mit der Fehlermeldung ist das letzte in der Befehlskette. Komischerweise wird das Kommando dennoch ausgeführt.
Kann es sein, dass 2 Sekunden nicht ausreichen um die Befehle zu dispatchen?

Ich kann ein Log mit Verbose 5 nachliefern, da der Fehler nicht immer auftritt, könnte es ein Paar Stunden oder Tage jedoch dauern...

Gruß
[throbin]

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24670
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #1 am: 25 Mai 2016, 09:22:03 »
Warum die Meldung kommt, ist mir raetselhaft, braeuchte den verbose 5 log, bitte mit "attr global mseclog". Eigentlich haben wir eine Menge unternommen, damit man keine sleep's zwischen den Befehlen benoetigt, der Stack wird normalerweise nach dem ACK des letzten Befehls weiter abgearbeitet. In manchen kaputten Netzwerken sind 2 Sekunden bis zum Eintreffen des ACKs auch moeglich.

Offline Duncan

  • New Member
  • *
  • Beiträge: 33
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #2 am: 08 Juni 2017, 22:11:50 »
Hi,
sieht bei mir genau so aus:

2017.06.08 22:09:53 2: ERROR: cannot SEND_DATA to DACHBODENDOSE: transmit queue overflow
2017.06.08 22:09:58.547 2: ZWave: No ACK from DACHBODENDOSE after 5s for set:1315032501002501
2017.06.08 22:09:58.558 2: ERROR: cannot SEND_DATA to DACHBODENDOSE: transmit queue overflow
2017.06.08 22:10:01.484 3: ZWave set DACHBODENDOSE off
2017.06.08 22:10:03.432 3: ZWave set DACHBODENDOSE on
2017.06.08 22:10:03.553 2: ZWave: No ACK from DACHBODENDOSE after 5s for set:1315032501002501
2017.06.08 22:10:03.562 2: ERROR: cannot SEND_DATA to DACHBODENDOSE: transmit queue overflow
2017.06.08 22:10:08.559 2: ZWave: No ACK from DACHBODENDOSE after 5s for set:1315032501002501
2017.06.08 22:10:08.569 2: ERROR: cannot SEND_DATA to DACHBODENDOSE: transmit queue overflow
2017.06.08 22:10:13.566 2: ZWave: No ACK from DACHBODENDOSE after 5s for set:1315032501002501
2017.06.08 22:10:13.577 2: ERROR: cannot SEND_DATA to DACHBODENDOSE: transmit queue overflow
2017.06.08 22:10:18.575 2: ZWave: No ACK from DACHBODENDOSE after 5s for set:1315032501002501
2017.06.08 22:10:18.585 2: ERROR: cannot SEND_DATA to DACHBODENDOSE: transmit queue overflow

wie soll ich das Loglevel ändern?
« Letzte Änderung: 08 Juni 2017, 22:25:48 von Duncan »

Offline we5

  • New Member
  • *
  • Beiträge: 20
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #3 am: 27 Dezember 2018, 16:08:18 »
Hallo,

ich habe jetzt schon des öfteren von "kaputten Netzwerken" gelesen, wenn es um solche Fehlermeldungen in Verbindung mit Z-Wave geht. Was meint ihr denn damit? Ich bin mehrerer Hinsicht mittlerweile echt auch am Ende mit meinem Latein.

Ich habe diese Meldungen auch, nicht regelmässig, aber des öfteren. Gerade in Verbindung mit SECURE Geräten (Aeotec Garage Door Controller und Danalock V3 Türschloss). Selbst mit einer Fibaro-Steckdose. Mich stört vor allen Dingen, dass ich immer öfter massive Laufzeiten habe von 2-10 Sekunden für manche Befehle habe. Laut neighborList sehen sich alle Geräte wirklich mehr als ausreichend.

Ich muss dazu sagen, dass das Netz eigentlich recht stabil war, bis ich alle Thermostate durch die EUROtronic ersetzt habe. Kurzum, seit überall quasi FLIR-Geräte verteilt sind. Früher scheint der Weg immer direkt gewählt worden zu sein, auch von den WakeUp-Geräten, jetzt scheinen die FLIR-Geräte manchmal "im Weg zu stehen".

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24670
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #4 am: 27 Dezember 2018, 17:22:50 »
Zitat
Laut neighborList sehen sich alle Geräte wirklich mehr als ausreichend.
Neighborlist wird mW vom Controller nur fuer Geraete ohne ZWave+ (genauer, ohne Explorer Frames) verwendet, und selbst bei den "alten" verstehe ich den Routing-Algorithmus nicht. Wie genau die Pakete geroutet werden kann man nur mit einem CUL + ZWCUL im monitor Mode verfolgen, ob sich der Aufwand lohnt, kann ich aber nicht beurteilen.

Offline we5

  • New Member
  • *
  • Beiträge: 20
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #5 am: 07 Februar 2019, 18:39:27 »
Naja, ich hab die "transmit queue overflow" schon echt regelmässig und es ist momentan zu beobachten, dass das FHEM/ZWave nach ungefähr maximal 48 Stunden komplett spinnt irgendwie. Dann muss ich immer den Raspi booten dann ist es wieder ok.

Bei mir sieht das Log nach einem FHEM start etwa so aus, ist aber über den Tag verteilt immer mal wieder so:

2019.02.07 18:30:21 2 : ZWave: No ACK from eg.esszimmer.Thermostat after 5s for sentset:1331064301012200d22503
2019.02.07 18:30:21 2 : ZWave: No ACK from ug.studio.Thermostat after 5s for sentset:1334064301012200c82504
2019.02.07 18:30:22 2 : ZWave: No ACK from og.bad.Thermostat after 5s for sentset:132e064301012200e62506
2019.02.07 18:30:22 2 : ZWave: No ACK from og.kinderzimmer.Thermostat after 5s for sentset:1336064301012200f02507
2019.02.07 18:30:30 2 : ERROR: cannot SEND_DATA to og.kinderzimmer.Thermostat: transmit queue overflow
2019.02.07 18:30:31 2 : ZWave: No ACK from og.schlafzimmer.Thermostat after 5s for sentget:132f034302012509
2019.02.07 18:30:32 2 : ZWave: No ACK from og.bad.Thermostat after 5s for sentget:132e03430201250a
2019.02.07 18:30:32 2 : ZWave: No ACK from og.kinderzimmer.Thermostat after 5s for get:133603430201250b
2019.02.07 18:30:33 2 : ERROR: cannot SEND_DATA to og.kinderzimmer.Thermostat: transmit queue overflow
2019.02.07 18:30:35 2 : ERROR: cannot SEND_DATA to og.kinderzimmer.Thermostat: transmit queue overflow
2019.02.07 18:30:37 2 : ZWave: No ACK from og.kinderzimmer.Thermostat after 5s for get:133603430201250b
2019.02.07 18:30:37 2 : ERROR: cannot SEND_DATA to og.kinderzimmer.Thermostat: transmit queue overflow

Wie gesagt, auffallend oft sind das auch alles einfach FLIRS-Geräte (EUROtronic Spirits), aber auch gerne mal ne Steckdose von Aeotec oder Fibaro.

Mit anderen Worten ich muss damit leben?
Die Geräte sind recht gleichmässig über das Haus verteilt und in der Regel sehe ich auch keine auffälligen ACKs in den Readings. Bis es dann irgendwann wieder anfängt zu spinnen.
Echt ekelhaft ist es dann, wenn die Garage (Aeotec Garage Door Controller) oder das Schloss (Danalock V3) mit starker Verzögerung reagieren oder gar nicht (wie eben wieder).

Ich würde dem gerne mehr auf den Grund gehen. Du sagst also, mit einem CUL kann ich das machen? Kannst Du mir da genauer sagen, was ich benötige?
Am Ende bringt mich das weiter als wenn ich jetzt wirklich alle Z-Wave-Devices austauschen müsste (mal von den Kosten abgesehen). Aber ruhig schlafen lässt mich das aktuell nur bedingt.

Offline Deckoffizier

  • Sr. Member
  • ****
  • Beiträge: 576
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #6 am: 07 Februar 2019, 22:23:18 »
Hallo we5,

bei mir sieht es ähnlich aus mit vielen Logeińträgen wie bei Dir.

Vom Gefühl je mehr Geräte um so schlimmer ist es geworden.
Hatte hier schon mal nachgefragt bin momentan arbeitsmäßig stark
eingespannt um dem mehr nachzusteigen obwohl USB Kabel tauschen wäre
erst mal das   einfachste.

Gruß

Hans-Jürgen
FHEM 5.8 auf "yakkaroo Emu A1FL.1" mit CUL 868MHz, SIGNALduino,1 Wire USB Busmaster, diverse 1 Wire Sensoren,Landroid,Aeotec USB Dongle Z-Wave Plus

Offline krikan

  • Developer
  • Hero Member
  • ****
  • Beiträge: 7028
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #7 am: 08 Februar 2019, 07:59:56 »
Um aus dem Log Rückschlüsse/Hinweise ziehen zu können, braeuchte man mehr Infos:
[..] braeuchte den verbose 5 log, bitte mit "attr global mseclog". [..]
Die Fehlermeldung "transmit queue overflow" könnte bspw. auch durch "ungünstiges" Absetzen von ZWave-Befehlen verursacht sein.

Beispiel:
An mehrere Geräte wird durch eine structure gleichzeitig, d.h. ohne Pause zwischen den Befehlen mittels Attribut https://fhem.de/commandref.html#async_delay, ein Befehl verschickt. Das führt zwangsläufig zum Überlaufen der transmit queue; insbesondere bei FLIRS-Geräten bei denen die Telegrammlaufzeit lange ist.

Siehe auch https://forum.fhem.de/index.php/topic,92899.0.html

Gruß, Christian
Informativ Informativ x 1 Liste anzeigen

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24670
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #8 am: 08 Februar 2019, 10:18:52 »
Zitat
FHEM/ZWave nach ungefähr maximal 48 Stunden komplett spinnt
Wird das Problem behoben, wenn man nur FHEM neu startet?
Wenn ja, dann koennte ein "define zwfix at *03:30 set zwDongle reopen" ein Workaround sein.
Wenn nicht, dann evtl. ein Firmwareupdate des ZWave Controllers.

Das ist zusaetzlich/parallel zu den Ratschlaegen von krikan zu sehen.

Offline th0nix

  • New Member
  • *
  • Beiträge: 42
ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #9 am: 11 April 2021, 21:01:38 »
Hi zusammen,

da ich mit den Auswirkungen der Meldung: ERROR: cannot SEND_DATA to <Device>: transmit queue overflow gerade auch konfrontiert bin habe ich diesen Thread nochmal eröffnet. Die Google Suche bringt bei der Meldung nur diesen Thread und die Stellen in dem Sourcecode ...

Lieder habe ich in den Tipps (https://forum.fhem.de/index.php/topic,92899.0.html) auch nicht so recht was gefunden, was mir weitergeholfen hat.

Ich habe 6  FLiRS Geräte (Spirit Z-Wave PLUS Thermostate) welche gesteuert werden. Da aufgrund von unterschiedlichen Trigger und Dashboards Informationen eingeholt werden bzw Werte gesetzt müssen bekomme ich sehr häufig die Meldung, über die volle ZWAVE Queue - ERROR: cannot SEND_DATA to <Device>: transmit queue overflow bzw die Geräte nicht antworten - ZWave: No ACK from <Device>  after 5s for sentset:1308064301012200cd2507

Gibt es eine Möglichkeit die Events FHEM-Seitig zu puffern, so das der ZWAVE Controller nicht alle gleichzeitig bekommt, so das ich bei in den DOIFs, notify etc keine Rücksicht darauf nehmen muss ?
An vielen Stellen bringt mir eine structure mit async_delay leider nichts ...

Würde mich freuen wenn jemand einen Tipp für mich hätte.

Vielen Dank schon mal.

Offline rudolfkoenig

  • Administrator
  • Hero Member
  • *****
  • Beiträge: 24670
Antw:ERROR: cannot SEND_DATA to <Device>: transmit queue overflow
« Antwort #10 am: 12 April 2021, 09:15:46 »
Zitat
Gibt es eine Möglichkeit die Events FHEM-Seitig zu puffern, so das der ZWAVE Controller nicht alle gleichzeitig bekommt
Ich habe mir relativ viel Muehe gemacht, um genau das zu implementieren. Es gibt zwei unterschiedliche Queues: eins pro ZWDongle, wo der naechste Befehl erst geschickt wird, wenn der Controller ihn bestaetigt hat, und eins pro ZWave Instanz, wo Befehle nur nach Funk-ACK bzw. Antwort auf get an das ZWDongle weitergegeben werden.

Da mir keine Dokumentation fuer die FHEM<=>Controller Schnittstelle bekannt ist, ist moeglich, dass die FHEM Implementierung fehlerhaft ist, z.Bsp. ist mir nicht klar, ob mehrere gets an unterschiedliche Geraete austehen koennen, und wenn ja, wieviele. Security verkompliziert die Sache zusaetzlich, ist aus dieser Perspektive wie ein get zu sehen. Womoeglich waere das Zusammenlegen aller einzeln-Queues hilfreich, das ist aber relativ viel Arbeit, dazu kommt, dass die Pruefung, ob es hilft, aufwendig ist.

Ich hege den Verdacht, dass manche Controller mit simultane Kommunikation ihre Schwierigkeiten haben. Es wuerde micht nicht wundern, wenn neuere Controller oder ein neues Firmware hier Abhilfe schafft.

 

decade-submarginal