Open gbroll opened 6 months ago
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)'
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.
I tried, but unfortunately it didn’t work :(
Currently my solution was downgrading to version 1.35.1-1 which does not seem to cause this problem
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.
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.
Yes, and the workaround doesn't do the job for the LEDVANCE plug (https://www.zigbee2mqtt.io/devices/4058075729322.html) either.
This is probably related to https://github.com/Koenkk/zigbee-herdsman/issues/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.
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.
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)
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