deCONZ driver has a 60ms delay when reading a button press

I am trying to make my lights as responsive as possible. However, when I press the button on any of my remotes there is a noticeable delay for the press to appear in the logs. The button I am using here is bound to a light, and the light turns on noticeably quicker than the Z2M logs show.

I pulled some debug logs with DEBUG=zigbee-herdsman* /usr/bin/npm start and you can clearly see the sequence here:

• we get a DEVICE_STATE frame from the button indicating something happened, that gets logged exactly when I press the button
• we send the read data request to the button to (I guess) know exactly what happened 79ms after that
• 6ms later the button answers with what changed, and Z2M logs that as a button press

Basically we introduce an artificial 80ms delay when reading button clicks. Looking at the source code, even if adapter_delay set to 0 we are still setting PROCESS_APS_QUEUES_DELAY to 50ms and READY_TO_SEND_TIMEOUT to 10ms for a total of 60ms waiting to send any message.

Why do we need to wait that long, when nothing is happening in the network and presumably in the deCONZ stick? Can’t we just cut all of these delays to 0 and look at the deCONZ stick’s message queue (or whatever indicates it is under load) and only delay sending commands if it is busy / will drop messages if we don’t? Or is this for devices in the Zigbee network which might not respond well to a high frequency of network frames?

I would be happy to run a custom version of Z2M with delays set to 0 to see if my network (which is composed of IKEA and Philips bulbs and switches) works well that way, but am not super familiar with node.js and how to set a specific package to dev mode. The way zigbee-herdsman uses TypeScript which then gets transpiled also makes it difficult to do a few changes in the dependent packages after you run npm ci.

I tried checking what the behaviour is for the z-stack adapters but the code is laid out differently which makes this a bit more challenging.

This is with the latest dev checkout from today, adapter_delay set to 0, an IKEA E1743 switch bound to an IKEA LED driver and the ConBee 2 adapter with firmware 0x26680700.

Details of the debug logs here:

zigbee-herdsman:deconz:frameParser DEVICE_STATE changed: 10101010 +7s
zigbee-herdsman:deconz:driver networkstate: 2 apsDataConfirm: 0 apsDataIndication: 1 configChanged: 0 apsRequestFreeSlots: 1 +7s
zigbee-herdsman:deconz:driver query aps data indication +1ms
zigbee-herdsman:deconz:driver DATA_INDICATION - sending read data request - SeqNr. 25 +79ms
zigbee-herdsman:deconz:frameParser DATA_INDICATION RESPONSE - seqNr. 25 srcAddr: 0xcac7 destAddr: 0xcd profile id: 0x104 cluster id: 0x6 +86ms
zigbee-herdsman:deconz:frameParser response payload: 1,57,0 +0ms
zigbee-herdsman:controller:log Received 'zcl' data '{"frame":{"Header":{"frameControl":{"frameType":1,"manufacturerSpecific":false,"direction":0,"disableDefaultResponse":false,"reservedBits":0},"transactionSequenceNumber":57,"manufacturerCode":null,"commandIdentifier":0},"Payload":{}},"address":51911,"endpoint":1,"linkquality":231,"groupID":205}' +9s
Zigbee2MQTT:debug 2020-12-16 11:35:15: Received Zigbee message from 'office_desk_remote', type 'commandOff', cluster 'genOnOff', data '{}' from endpoint 1 with groupID 205
zigbee-herdsman:controller:endpoint DefaultResponse 0xccccccfffee13f8f/1 6(0, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":true,"direction":1,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null}) +9s
zigbee-herdsman:deconz:adapter zclFrame.payload: +9s
zigbee-herdsman:deconz:adapter { cmdId: 0, statusCode: 0 } +0ms
zigbee-herdsman:deconz:adapter no response expected +1ms
zigbee-herdsman:deconz:driver networkstate: 2 apsDataConfirm: 0 apsDataIndication: 0 configChanged: 0 apsRequestFreeSlots: 1 +10ms
Zigbee2MQTT:info  2020-12-16 11:35:15: MQTT publish: topic 'zigbee2mqtt/office_desk_remote', payload '{"action":"off","battery":5,"click":"off","linkquality":231,"update_available":false}'
zigbee-herdsman:deconz:driver DATA_REQUEST - destAddr: 0xcac7 EP:1 SeqNr. 26 request id: 4 +84ms
zigbee-herdsman:deconz:frameParser DATA_REQUEST RESPONSE - request id: 4 status: 0 +94ms
zigbee-herdsman:deconz:driver networkstate: 2 apsDataConfirm: 0 apsDataIndication: 0 configChanged: 0 apsRequestFreeSlots: 1 +3ms
zigbee-herdsman:deconz:frameParser DEVICE_STATE changed: 10100110 +10ms
zigbee-herdsman:deconz:driver networkstate: 2 apsDataConfirm: 1 apsDataIndication: 0 configChanged: 0 apsRequestFreeSlots: 1 +10ms
zigbee-herdsman:deconz:driver query aps data confirm +0ms
zigbee-herdsman:deconz:driver DATA_CONFIRM - sending data state request - SeqNr. 27 +93ms
zigbee-herdsman:deconz:frameParser DATA_CONFIRM RESPONSE - destAddr: 0xcac7 request id: 4 confirm status: 0 +96ms
zigbee-herdsman:deconz:driver networkstate: 2 apsDataConfirm: 0 apsDataIndication: 0 configChanged: 0 apsRequestFreeSlots: 1 +3ms
zigbee-herdsman:deconz:adapter sendZclFrameToEndpoint - message send with transSeq Nr.: 57 +194ms

Mentioning #72 as this issue might be of interest to the community, but that master ConBee issue is not very actionable given the number of different problems it covers.

[ndfred]

It turns out the delay set in the configuration file are never actually fully honoured:

• HANDLE_DEVICE_STATUS_DELAY will always be 100ms
• PROCESS_APS_QUEUES_DELAY will always be 100ms
• READY_TO_SEND_TIMEOUT will be honoured

That is because the driver constructor is called before setDelay is called, when really the constructor should take the delay as a parameter and call setDelay on that. I’ll try and get a PR out that fixes it.

In the meantime I would suggest tweaking the constructor:

• editing node_modules/zigbee-herdsman/dist/adapter/deconz/driver/driver.js
• setting HANDLE_DEVICE_STATUS_DELAY and PROCESS_APS_QUEUES_DELAY to the desired values in constructor (I just set them to 100000 and 1, then update READY_TO_SEND_TIMEOUT to 0 in setDelay)

[Koenkk]

@ChrisHae can you check this?