ERROR: cannot SEND_DATA to <Device>: transmit queue overflow

[throbin]

Morgen,

ich bekomme immer wieder die Fehlermeldung im Logfile zu sehen:

Code Auswählen Erweitern


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

Code Auswählen Erweitern

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:

Code Auswählen Erweitern


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]

[rudolfkoenig]

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.

[Duncan]

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?

[we5]

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".

[rudolfkoenig]

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.

[we5]

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:

Code Auswählen Erweitern


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.

[Deckoffizier]

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

[krikan]

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

[rudolfkoenig]

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.

[th0nix]

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.

[rudolfkoenig]

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.

[pittbullpower]

Hallo Zusammen,

habe seit kurzem auch wieder diese Lock-Einträge.

Habe ein Raspi4 mit Bullseye (aktuell) und fahre Fhem in der neusten Variante (6.1, gerade upgedatet).

Aus dem Event-Monitor habe ich mal die Meldungen kopiert, welche mir zu viel vorkommen:

Code Auswählen Erweitern

2021-12-06 08:18:22 ZWave Varmo_A_Bad desired-temp 20
2021-12-06 08:18:23 ZWave Varmo_A_Bad desired-temp: 20
2021-12-06 08:18:33 ZWave Varmo_WZ dim 55
2021-12-06 08:18:33 ZWave Varmo_WZ reportedState: dim 55
2021-12-06 08:18:33 ZWave Varmo_WZ valve: 55
2021-12-06 08:18:33 ZWave Varmo_WZ temperature: 19.46 C
2021-12-06 08:18:33 ZWave Varmo_WZ temperature: 19.46 C
2021-12-06 08:18:34 ZWave Varmo_WZ temperature: 19.46 C
2021-12-06 08:18:36 ZWave Varmo_A_WZ dim 59
2021-12-06 08:18:36 ZWave Varmo_A_WZ reportedState: dim 59
2021-12-06 08:18:36 ZWave Varmo_A_WZ valve: 59
2021-12-06 08:18:36 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:36 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:36 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:36 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:36 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:36 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:37 ZWave Varmo_A_WZ temperature: 18.49 C
2021-12-06 08:18:38 ZWave LUX_Eingang luminance: 61 Lux
2021-12-06 08:18:52 ZWave Varmo_A_SZ desired-temp 20
2021-12-06 08:18:53 ZWave Varmo_A_SZ desired-temp: 20
2021-12-06 08:18:56 ZWave Varmo_GZ dim 49
2021-12-06 08:18:56 ZWave Varmo_GZ reportedState: dim 49
2021-12-06 08:18:56 ZWave Varmo_GZ valve: 49
2021-12-06 08:19:03 ZWave LUX_Garage luminance: 94 Lux
2021-12-06 08:19:04 ZWave Varmo_SZ dim 57
2021-12-06 08:19:04 ZWave Varmo_SZ reportedState: dim 57
2021-12-06 08:19:04 ZWave Varmo_SZ valve: 57
2021-12-06 08:19:21 SYSMON sysmon cpu_freq: 600
2021-12-06 08:19:21 SYSMON sysmon eth0_diff: RX: 1.15 MB, TX: 10.62 MB, Total: 11.77 MB
2021-12-06 08:19:21 SYSMON sysmon loadavg: 0.19 0.18 0.11
2021-12-06 08:19:21 SYSMON sysmon stat_cpu_percent: 1.66 0.00 0.67 97.46 0.11 0.00 0.10
2021-12-06 08:19:21 SYSMON sysmon cpu_temp_avg: 41.6
2021-12-06 08:19:21 SYSMON sysmon wlan0_diff: RX: 0.00 MB, TX: 0.00 MB, Total: 0.00 MB
2021-12-06 08:19:21 SYSMON sysmon cpu_temp: 41.87
2021-12-06 08:19:21 SYSMON sysmon ram: Total: 3888.27 MB, Used: 202.98 MB, 5.22 %, Free: 3365.85 MB
2021-12-06 08:19:22 structure Heizung_Gruppe_Anbau desired-temp 20
2021-12-06 08:19:22 ZWave Varmo_A_Flur desired-temp 20
2021-12-06 08:19:24 structure Heizung_Gruppe_Anbau desired-temp 20
2021-12-06 08:19:24 ZWave Varmo_A_Flur desired-temp: 20
2021-12-06 08:19:38 ZWave LUX_Eingang luminance: 69 Lux
2021-12-06 08:20:03 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:03 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:03 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:03 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux
2021-12-06 08:20:04 ZWave LUX_Garage luminance: 103 Lux

Mir fällt auf, das die FLIRS Geräte nach dem Hochfahren, zuviele Temperatur Einträge zurück geben. Auch bei den Steinel Sensoren kommt zuviel luminance.
Ich habe bereits einiges eingestellt, bzw. verstellt, leider ohne Erfolg....

Code Auswählen Erweitern

2021-12-06 08:49:47 Global global SHUTDOWN
2021.12.06 08:50:20 2 : CUL_433: CheckVersionResp, initialized v3.4.4
2021.12.06 08:50:20 3 : CUL_433: CheckVersionResp, enable receiver (XE)
2021.12.06 08:50:21 3 : ZWave set Varmo_A_WZ desired-temp 20
2021.12.06 08:50:21 3 : CUL_433: CheckCcpatableResponse, patable: C0
2021.12.06 08:50:26 2 : ZWave: No ACK from Varmo_A_WZ after 5s for sentset:131d064301012200c82501
2021.12.06 08:50:30 3 : ZWave set Varmo_SZ desired-temp 20
2021.12.06 08:50:30 2 : ERROR: cannot SEND_DATA to Varmo_SZ: transmit queue overflow
2021.12.06 08:50:35 2 : ZWave: No ACK from Varmo_SZ after 5s for set:131c064301012200c82502
2021.12.06 08:50:35 2 : ERROR: cannot SEND_DATA to Varmo_SZ: transmit queue overflow
2021.12.06 08:50:40 2 : ZWave: No ACK from Varmo_SZ after 5s for set:131c064301012200c82502
2021.12.06 08:50:41 3 : ZWave set Varmo_GZ desired-temp 20
2021.12.06 08:50:41 2 : ZWDongle_ProcessSendStack: no ACK, resending message 010d00131c064301012200c8250275
2021.12.06 08:50:42 2 : ZWDongle_ProcessSendStack: no ACK, resending message 010d00131c064301012200c8250275
2021.12.06 08:50:43 2 : ZWDongle_ProcessSendStack: no ACK, resending message 010d00131c064301012200c8250275
2021.12.06 08:50:44 2 : ZWDongle_ProcessSendStack: no ACK, resending message 010d00131c064301012200c8250275
2021.12.06 08:50:44 1 : ERROR: max send retries reached, removing 010d00131c064301012200c8250275 from dongle sendstack
2021.12.06 08:50:44 2 : ERROR: cannot SEND_DATA to Varmo_GZ: transmit queue overflow
2021.12.06 08:50:45 2 : ZWave: No ACK from Varmo_SZ after 5s for sentset:131c064301012200c82502
2021.12.06 08:50:46 2 : ZWave: No ACK from Varmo_GZ after 5s for set:1323064301012200c82503
2021.12.06 08:50:46 2 : ERROR: cannot SEND_DATA to Varmo_GZ: transmit queue overflow
2021.12.06 08:50:48 2 : ZWDongle_1 transmit NO_ACK for CB 03, target Varmo_GZ
2021.12.06 08:50:51 3 : ZWave set Varmo_A_Bad desired-temp 20
2021.12.06 08:50:51 2 : ZWave: No ACK from Varmo_GZ after 5s for set:1323064301012200c82503

Kann man mir hier weiterhelfen?

Gruß

Markus

[rudolfkoenig]

Vermutlich sollte man die beiden Probleme zunaechst separat betrachten:

Mehrere identische Meldungen: werden diese Nachrichten von FHEM explizit (per at/notify/etc) abgefragt? Wenn ja: sind da evtl. Fehler dabei (d.h. mehrere Abfragen)? Ich habe solche mehrfachen Nachrichten dann gesehen, wenn Daten ueber mehrere Repeater versendet wurden, aber nicht alle Repeater sauber den Empfang per Ack bestaetigt haben.

"no ACK" zeigt Probleme bei der Funk-Uebertragung.

"transmit queue overflow" ist vermutlich auf mein falsches Verstaendnis der FHEM<=>Dongle Kommunikation zurueckzufuehren, zu meiner Rettung muss ich sagen, dass ich dafuer noch keine Beschreibung gefunden habe. Vmtl. wird ein Sonderfall, wenn die Kommunikation nicht problemlos klappt (s.o.) nicht richtig behandelt. Es kann aber auch einfach ein Firmware-Problem sein.

Insgesamt vermute ich Netzwerkprobleme, vulgo nicht gut funktionierende Funk-Uebertragung.

Als Erstes wuerde ich fuer alle Geraete "set dev neigborUpdate" durchfuehren (das kann pro Geraet etliche Sekunden dauern, und der Contoller will in dieser Zeit nicht gestoert werden).
Wenn das Problem dadurch nicht geloest ist,  get dev neighborList" fuer alle Geraete, und/oder routeFor der einzelnen Geraete notieren, und die Topologie durch hinzufuegen/entfernen von Repeatern aendern. Dann wieder mit neighborUpdate weitermachen.

[pittbullpower]

Hallo,

danke für die schnelle Hilfe.

Ich frage nichts ab, diese Meldungen kommen von den Geräten selber.
Der ZMEEUZB hat die aktuelle Software drauf.
NeighborUpdate und NeighborList habe ich bereits mehrfach gemacht. Das Verhalten hat sich leider nicht verbessert.

Ich habe nur 3 Hersteller in meinem Netz: Fibaro, Varmo/Eurotronics, Steinel.

Ich werde mal die routefor-Variante ausprobieren.

Markus
Danke für den Hinweis.

[pittbullpower]

Mahlzeit allerseits,

kurze Rückinfo zu meinem Problem:

Die Kombi Weekdaytimer mit structure hat bei mir die Fehlermeldungen erzeugt.
Immer wenn ich neu gestartet habe hat der WDT auf die structure zugegriffen und, egal was ich eingegeben hatte als delay, kamen die Fehlermeldung.

Es waren nur 4 Euroronics Thermostate in einer structure und auf die hat der WDT zugegriffen.

Hatte heute pro Thermostat ein WDT eingegeben, was mir nicht gefällt, aber es hat funktioniert.

Jetzt muss ich den Neustart nochmal abwarten.

Da dies mit dem WDT an einen anderen Thread gehört, danke nochmal für die Hilfe.

Markus