Handling of poll check-in from <device> failed with Tuya 19JWZ Door/Window Sensor

[mrebbert]

What happened?

I got five of the Tuya 19JWZ Door/Window sensors. They work as expected but I get the error message below nearly every 30 minutes from each of them. In general i got no connection issues.

zigbee2mqtt | [2024-10-27 15:30:40] error: zh:controller:device: Handling of poll check-in from 0xa4c1380c6c3aa1e1 failed (ZCL command 0xa4c1380c6c3aa1e1/1 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 63813 - 1 - 53 - 32 - 11 after 10000ms))

Currently the sensor is recognized as Sonoff SNZB-04 - i already raised an issue for this: #24499 I already tried to make device individual configuartions but it seems that they are completely ignored.

Any hints?

My configuration.yaml:

homeassistant: true
permit_join: false
frontend: true
mqtt:
  base_topic: zigbee2mqtt
  server: '!secrets.yaml mqtt_server'
  user: '!secrets.yaml mqtt_user'
  password: '!secrets.yaml mqtt_password'
serial:
  port: tcp://<ip>:6638
  baudrate: 115200
  adapter: zstack
  disable_led: true
advanced:
  pan_id: <pan_id>
  ext_pan_id:
    <..>

  channel: 20
  network_key: '!secrets.yaml network_key'
  transmit_power: 20
  homeassistant_legacy_entity_attributes: false
  legacy_api: false
  legacy_availability_payload: false
  log_level: debug
  last_seen: ISO_8601_local
  log_output:
    - console
device_options:
  legacy: false
availability:
  active:
    timeout: 10
  passive:
    timeout: 1500
devices: devices.yaml
groups: groups.yaml

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

1.40.2 commit: e06848d

Adapter firmware version

20221226

Adapter

SMLIGHT SLZB-06

Setup

docker

Debug log

zigbee2mqtt  | [2024-10-27 15:30:16] debug:     zh:controller:device: check-in from 0xa4c1380c6c3aa1e1: declining fast-poll
zigbee2mqtt  | [2024-10-27 15:30:16] debug:     zh:controller:endpoint: ZCL command 0xa4c1380c6c3aa1e1/1 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"})
zigbee2mqtt  | [2024-10-27 15:30:16] debug:     zh:controller:endpoint: Request Queue (0xa4c1380c6c3aa1e1/1): send checkinRsp request immediately (sendPolicy=immediate)
zigbee2mqtt  | [2024-10-27 15:30:16] debug:     zh:zstack: sendZclFrameToEndpointInternal 0xa4c1380c6c3aa1e1:63813/1 (0,0,1)
zigbee2mqtt  | [2024-10-27 15:30:26] debug:     zh:zstack: Response timeout (0xa4c1380c6c3aa1e1:63813,0)
zigbee2mqtt  | [2024-10-27 15:30:26] debug:     zh:zstack:znp: --> SREQ: UTIL - assocGetWithAddress - {"extaddr":"0xa4c1380c6c3aa1e1","nwkaddr":63813}
zigbee2mqtt  | [2024-10-27 15:30:26] debug:     zh:zstack: Response timeout recovery: Node relation 8 (0xa4c1380c6c3aa1e1 / 65534)
zigbee2mqtt  | [2024-10-27 15:30:30] debug:     zh:zstack: sendZclFrameToEndpointInternal 0xa4c1380c6c3aa1e1:63813/1 (1,0,1)
zigbee2mqtt  | [2024-10-27 15:30:40] debug:     zh:zstack: Response timeout (0xa4c1380c6c3aa1e1:63813,1)
zigbee2mqtt  | [2024-10-27 15:30:40] debug:     zh:controller:endpoint: Error: ZCL command 0xa4c1380c6c3aa1e1/1 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 63813 - 1 - 53 - 32 - 11 after 10000ms)
zigbee2mqtt  | [2024-10-27 15:30:40] error:     zh:controller:device: Handling of poll check-in from 0xa4c1380c6c3aa1e1 failed (ZCL command 0xa4c1380c6c3aa1e1/1 genPollCtrl.checkinRsp({"startFastPolling":false,"fastPollTimeout":0}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"reservedBits":0,"writeUndiv":false,"sendPolicy":"immediate"}) failed (Timeout - 63813 - 1 - 53 - 32 - 11 after 10000ms))

[chris-1243]

Have a look there #23983

Regarding your error, I would unbind genPollCtrl.

[mrebbert]

thanks for your response, Chris. Unbind genPollCtrl did not work and i get an error.

I pushed to zigbee2mqtt/bridge/request/device/unbind:

{
  "id": 1,
  "type": "unbind",
  "clusters": [ "genPollCtrl" ],
  "from": "0xa4c138b9fa84e8a0",
  "to": "coordinator"
}

z2m: Failed to unbind cluster 'genPollCtrl' from 'Esszimmer/Fenster links' to 'Coordinator' (Error: Unbind 0xa4c138b9fa84e8a0/1 genPollCtrl from '0xa4c138b9fa84e8a0/1' failed (AREQ - ZDO - unbindRsp after 10000ms))

Unbinding genBasic with the same payload works, but did not solve the problem.

Any other advise?

[chris-1243]

Could you provide some information on the binding ? A picture should be enough

Before sending your command, did you ensure the device was awake? End device must be awaken before you send such command. Otherwise, you will get an error.

[mrebbert]

I'm not sure what you mean.. this one?

i activate the sensor before sending the unbind cmd. No change. The unbind from the ui resulkts in the same error msg.

[chris-1243]

Yes, your picture was enough to see the bidings.

This is strange you may not unbind this cluster. In my opinion, the error comes from this bound cluster.

[mrebbert]

Thanks, Chris! - It looks like to work now.

The time, the sensor is active seems to be really short. Had to try it several times. The procedere was, 1. sending req (via ui), 2. quickly open the contact.

I have now been able to unbind genPollCtrl on 4 out of 5 sensors. I still have problems with the last one.

Any clou, how to extend the time the sensor is active?

[chris-1243]

Any clou, how to extend the time the sensor is active?

Instead of opening/closing why don't you use the pairing button ? Check the user manual first. On my temperature sensors when I need to send a command (binding, reporting) I shortly press the pairing button at regular interval. Like this, the end device is always awake. In your case, I suspect your device to quickly change from awake to sleepy in order to save battery. This is why it was hard to send the command.

As you unbind the genPollCtrl, check if all data required are still updated and sent correctly. If not and in the reporting tab, add the data required to get those values reported again.

[mrebbert]

you are right, sounds obvious and works perfectly. all data (PowerCfg) are updated.

Thanks again, Chris.