Probleme bei "set <device> configRequestAll"

Begonnen von krikan, 31 August 2015, 19:09:21

Vorheriges Thema - Nächstes Thema

eddy242

Hallo zusammen,

ich finde in meinem Log ähnliche Einträge:
2020.05.26 14:07:48 2: ZWDongle_ProcessSendStack: no ACK, resending message 0109001321028408257f10 Stick ist ein Sigma Designs, Inc. Aeotec Z-Stick Gen5 (ZW090). Ist remote angeschlossen an einem RPI, der sonst eigentlich nicht viel zu tun hat. Ich kann die Remote-Connectivity als Fehlerquelle ausschließen, vorher war der Stick lokal angeschlossen, u.a. um genau diese Symptomatik auszuschließen. In meinem ZWave Netz habe ich im Wesentlichen Fibaro Multisensoren und EUROtronic EUR_SPIRIT Funkthermostate, die sind allerdings momentan saisonal disabled. Ich habe mit den letzgenannten auch immer wieder solche Logeinträge: 2020.04.29 19:28:06 2: ERROR: cannot SEND_DATA to Funkthermostat_Bernhard: transmit queue overflow Kann ich was tun um das zu debuggen?


Internals:
   CallbackNr 0
   Clients    :ZWave:
   DEF        192.168.178.8:3001
   DeviceName 192.168.178.8:3001
   FD         32
   FUUID      5e64050f-f33f-0759-0961-8b838f80623e1aca
   MaxSendRetries 3
   NAME       ZWDongle_RPi
   NR         403
   PARTIAL   
   RAWMSG     0004002d06310504220040
   ReadTime   1590506452.11447
   STATE      Initialized
   SendRetries 0
   SendTime   1590505469.11224
   TYPE       ZWDongle
   WaitForAck 0
   ZWDongle_RPi_MSGCNT 36075
   ZWDongle_RPi_TIME 2020-05-26 17:20:52
   homeId     <deleted>
   nodeIdHex  01
   nrNAck     0
   showSetInState 1
   MatchList:
     1:ZWave    .*
   READINGS:
     2020-05-25 13:53:31   caps            Vers:4 Rev:36 ManufID:0000 ProductType:0001 ProductID:0001 SERIAL_API_GET_INIT_DATA SERIAL_API_APPL_NODE_INFORMATION APPLICATION_COMMAND_HANDLER ZW_GET_CONTROLLER_CAPABILITIES SERIAL_API_SET_TIMEOUTS SERIAL_API_GET_CAPABILITIES SERIAL_API_SOFT_RESET UNKNOWN_09 ZW_SET_R_F_RECEIVE_MODE ZW_SET_SLEEP_MODE ZW_SEND_NODE_INFORMATION ZW_SEND_DATA ZW_SEND_DATA_MULTI ZW_GET_VERSION ZW_SEND_DATA_ABORT ZW_R_F_POWER_LEVEL_SET ZW_SEND_DATA_META ZW_GET_RANDOM MEMORY_GET_ID MEMORY_GET_BYTE MEMORY_PUT_BYTE MEMORY_GET_BUFFER MEMORY_PUT_BUFFER FLASH_AUTO_PROG_SET ZW_NVR_GET_VALUE NVM_GET_ID NVM_EXT_READ_LONG_BUFFER NVM_EXT_WRITE_LONG_BUFFER NVM_EXT_READ_LONG_BYTE NVM_EXT_WRITE_LONG_BYTE ZW_GET_NODE_PROTOCOL_INFO ZW_SET_DEFAULT ZW_REPLICATION_COMMAND_COMPLETE ZW_REPLICATION_SEND_DATA ZW_ASSIGN_RETURN_ROUTE ZW_DELETE_RETURN_ROUTE ZW_REQUEST_NODE_NEIGHBOR_UPDATE ZW_APPLICATION_UPDATE ZW_ADD_NODE_TO_NETWORK ZW_REMOVE_NODE_FROM_NETWORK ZW_CREATE_NEW_PRIMARY ZW_CONTROLLER_CHANGE ZW_SET_LEARN_MODE ZW_ASSIGN_SUC_RETURN_ROUTE ZW_REQUEST_NETWORK_UPDATE ZW_SET_SUC_NODE_ID ZW_DELETE_SUC_RETURN_ROUTE ZW_GET_SUC_NODE_ID ZW_SEND_SUC_ID ZW_EXPLORE_REQUEST_INCLUSION ZW_REQUEST_NODE_INFO ZW_REMOVE_FAILED_NODE_ID ZW_IS_FAILED_NODE ZW_REPLACE_FAILED_NODE UNKNOWN_66 UNKNOWN_67 ZW_FIRMWARE_UPDATE_NVM GET_ROUTING_TABLE_LINE LOCK_ROUTE_RESPONSE ZW_GET_PRIORITY_ROUTE ZW_SET_PRIORITY_ROUTE UNKNOWN_98 ZW_SET_WUT_TIMEOUT ZW_WATCHDOG_ENABLE ZW_WATCHDOG_DISABLE ZW_WATCHDOG_CHECK ZW_SET_EXT_INT_LEVEL ZW_RF_POWERLEVEL_GET ZW_TYPE_LIBRARY ZW_SEND_TEST_FRAME ZW_GET_PROTOCOL_STATUS WATCHDOG_START WATCHDOG_STOP ZW_SET_ROUTING_MAX UNKNOWN_ee UNKNOWN_ef
     2020-05-25 13:53:31   ctrlCaps       
     2020-05-25 13:53:31   homeId          HomeId:<deleted> CtrlNodeIdHex:01
     2020-05-25 13:53:31   random          <deleted>
     2020-05-25 13:53:31   state           Initialized
     2020-05-25 13:53:31   sucNodeId       no
   SendStack:
Attributes:
   DbLogExclude .*
   DbLogInclude .*
   alias      ZWave Dongle (an RaspPi)
   group      Communication
   homeId     <deleted>
   networkKey <deleted>
   room       Server
   showSetInState 1
   verbose    3


rudolfkoenig

Die wahrscheinlichste Ursache von "no ACK" ist ein Funkproblem, configRequestAll erzeugt eine starke Funklast, da kann schon mal was schiefgehen.
"transmit queue overflow" zeigt, dass der Stick schlechte Laune hat, vmtl. auch wegen Funkproblemen. Es kann aber auch sein, dass das FHEM Modul fehlerhaft ist, insb. wenn man mehrere Geraeten parallel abfragen will.
Batteriebetriebene Geraete sind eine Herausforderung, da sie meist schlafen, und nicht zum Mesh beitragen.

Wegen debuggen kann man mit neighborUpdate anfangen, danach FHEM verbose Logging hochdrehen, ZWave Doku lesen, und mit einem ZWCUL die Funktelegramme einzeln verfolgen.

eddy242

Ich hätte erwähnen sollen, dass ich diesen Thread misbraucht habe weil er am nächsten zu meiner Situation bzgl. der Logeinträge ist. Ich setze keine "set <device> configRequestAll" Befehle ab, das habe ich schon früh gelernt, dass es Unglück bringt. D.h. wir sprechen in meinem Netz nur über gelegentlich Set-Befehle und Rückmeldungen der Sensoren (Temp, Luminosity, Presence). Ich konnte und kann mir kaum vorstellen, dass das die Transmit Queue sprengen könnte.

Nach Deiner Beschreibung hätte mein Stick eigentlich immer schlechte Laune. Aber ja, ich sehe an den Logeinträgen dass eigentlich die Laune nur bei den batteriebetriebenen Geräten schlecht ist, bei den Fibaro Wallplugs mit permanenter Stromversorgung scheint es keine Einträge zu geben. ZWCUL scheidet für mich persönlich aus, da reicht die Bastel-Energie nicht.

krikan

Gleichzeitige set-Befehle (bspw. über devspec oder structure) insbesondere an mehrere FliRS-Geräte (Spirit ist eines) führen tendenziell zu "transmit queue overflow. Die Befehle muss man durch Pausen entzerren.

Um die Ursache Deines Problems zu finden, würde ich erst mal mit Rudis verbose-Ratschlag anfangen.

Vereinzelte resending sind übrigens nicht tragisch, so lange das Resending funktioniert.