Devices stuck in pair/interview loop

[gbroll]

What happened?

I have a functional Zigbee network with zigbee2mqtt. It does however seem that I can no longer communicate at all with newly added devices. I can add new devices to the network as usual (interview complete), the devices are being correctly identified and so on. But when I try to e.g. toggle the light or poll state afterwards, I only get "no response received". I've tried with different devices (IKEA bulbs of different types, Ledvance outlets) and the problem is the same. I have rebooted everything, tried join through various router devices nearby. Without success.

The strange thing is that all devices already on the network works well and can be controlled without any issues whatsoever. I have 35 devices (24 routers) on the network, if that is relevant. When I look at the network map, I see that there are no lines connecting the new device to any other node in the network.

What did you expect to happen?

I expected that the light bulb should be controllable after successful interview.

How to reproduce it (minimal and precise)

1. Reset a zigbee router device, e.g. a IKEA Trådfri bulb
2. Open network (permit join)
3. See that the light joins the network in the zigbee2mqtt logs without errors
4. Try to toggle the light in the UI and see that nothing happens, except from error messages in the logs ("no response received")

Zigbee2MQTT version

1.35.1 commit: 9eaaa0f

Adapter firmware version

0x26400500

Adapter

Conbee

Setup

Docker container on debian in proxmox (x86-64 machine)

Debug log

debug 2024-02-11 23:01:58Publishing 'set' 'state' to '0xf0d1b8be24094590'
error 2024-02-11 23:02:08Publish 'set' 'state' to '0xf0d1b8be24094590' failed: 'Error: Command 0xf0d1b8be24094590/1 genOnOff.off({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received (45))'
debug 2024-02-11 23:02:08Error: Command 0xf0d1b8be24094590/1 genOnOff.off({}, {"sendWhen":"immediate","timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (no response received (45)) at DeconzAdapter.sendZclFrameToEndpoint (/app/node_modules/zigbee-herdsman/src/adapter/deconz/adapter/deconzAdapter.ts:666:23) at Request.send (/app/node_modules/zigbee-herdsman/src/controller/helpers/request.ts:81:20) at Endpoint.command (/app/node_modules/zigbee-herdsman/src/controller/model/endpoint.ts:739:28) at Object.convertSet (/app/node_modules/zigbee-herdsman-converters/src/converters/toZigbee.ts:46:17) at Publish.onMQTTMessage (/app/lib/extension/publish.ts:249:36) at EventEmitter.wrappedCallback (/app/lib/eventBus.ts:167:17)
info 2024-02-11 23:02:08MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"Publish 'set' 'state' to '0xf0d1b8be24094590' failed: 'Error: Command 0xf0d1b8be24094590/1 genOnOff.off({}, {\"sendWhen\":\"immediate\",\"timeout\":10000,\"disableResponse\":false,\"disableRecovery\":false,\"disableDefaultResponse\":false,\"direction\":0,\"srcEndpoint\":null,\"reservedBits\":0,\"manufacturerCode\":null,\"transactionSequenceNumber\":null,\"writeUndiv\":false}) failed (no response received (45))'","meta":{"friendly_name":"0xf0d1b8be24094590"},"type":"zigbee_publish_error"}'
``

[EddyDevProject]

I have the same problem but with only one device. I did the latest update and after doing it a device (sonoff mini l2) stopped responding to commands. I can see its status correctly but I cannot command it.
I use a Sonoff ZBDongle-E as an adapter, all connected to a Raspberry 3B+ (HA OS).

error 2024-02-12 01:00:35Publish 'set' 'state' to 'pianerottolo_1_piano' failed: 'Error: Command 0x94deb8fffe41e65c/1 genOnOff.on({}, {"timeout":10000,"disableResponse":false,"disableRecovery":false,"disableDefaultResponse":false,"direction":0,"srcEndpoint":null,"reservedBits":0,"manufacturerCode":null,"transactionSequenceNumber":null,"writeUndiv":false}) failed (Timeout - 49569 - 1 - 197 - 6 - 11 after 10000ms)'

[eskholm]

I have a similar problem, which has been going on for more than a year. I have found a workaround:

1. Start pairing device as per usual
2. Watch pairing messages
3. When you see 'Device has been successfully configured' - immediately pull the power to the device
4. Wait a few seconds
5. Reapply power to the device

The device should work as expected now.

I have absolutely no idea why this is neccessary, but it's really annoying.

[EddyDevProject]

I tried, but unfortunately it didn’t work :(

[EddyDevProject]

Currently my solution was downgrading to version 1.35.1-1 which does not seem to cause this problem

[gbroll]

I have a similar problem, which has been going on for more than a year. I have found a workaround:

1. Start pairing device as per usual

2. Watch pairing messages

3. When you see 'Device has been successfully configured' - immediately pull the power to the device

4. Wait a few seconds

5. Reapply power to the device

The device should work as expected now.

I have absolutely no idea why this is neccessary, but it's really annoying.

Thanks a million for the tip, it worked here as well.
Really feels like it shouldn't bee needed though, so I'll not close the issue.

[sjorge]

That would only work for the non DIN devices, as usually if you power those off you power of the entire rail which often powers of large swats of the electrical system. But there are so many tickets on this rn it's hard to follow which devices are effected, it looks like all legrand/bticino devices, and the workaround is available for the non DIN ones.

[gbroll]

Yes, and the workaround doesn't do the job for the LEDVANCE plug (https://www.zigbee2mqtt.io/devices/4058075729322.html) either.

[gbroll]

#21497 seems to describe the same problem

[sjorge]

This is probably related to Koenkk/zigbee-herdsman#979, until this is fixed you can theoretically manually comment the readResponse coming from inside zh. I've tried this and then the device pairs again.

[TomaszGaweda]

Hey, just wanted to say that on latest Zigbee2MQTT and HA I still have this issue (more precisely - I just started having this issue). Re-pairing with workaround mentioned here worked.