Interview fails after deleting and re-pairing the same Zigbee device

[Element2]

Did some more testing. It happens with all previously paired/interviewed devices, regardless of type device. Tried dev branch, but that one does not pair at all.

Hi,
Zigbee2mqtt newbie her, long time Linux and home automation software user.
Hope this is in the right category.
Decided to try out Zigbee2mqtt because Deconz still does not support Lidl Silvercrest thermostat 368308_2010.

Installed Zigbee2mqtts (v1.27.2) on Ubuntu v20.04 and used a hacked Lidl gateway over TCP (coordinator EZsp v8 6.7.8.0 build 373).
This all worked as expected. I can pair different supported devices, they get interviewed and can be controlled from the front end web interface.
I paired and used a few Slivercrest thermostats without problems. Then deleted one from the interface, checked the database.db and state.json files that it was gone.

Reset the thermostat to default factory settings, pulled the battery and tried to re-pair it again. Zigbee2mqtt discovered it again, but now fails on interview. Tried countless (forced) deleting and re-paring, reconfigure, rebooting server and gateway, new batteries, put the thermostat next to the gateway, etc. Outcome always the same.
Paired this thermostat with other Zigbee software and it paired and worked.

Then tried this with another previously paired and working Silvercrest thermostat, with the same result, failed on interview.
Now I tried to pair a new, not paired with Zigbee2mqtt before Silvercrest thermostat, and it paired and interviewed with success.
So it looks like a problem specific with the repair/interview process and/or this device and this software setup.

Do I miss anything here?

Logfiles of re-pair:
ep 21 14:16:53 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:16:53: Device '0x0c4314fffe62fbe7' joined
Sep 21 14:16:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:16:54: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x0c4314fffe62fbe7","ieee_address":"0x0c4314fffe62fbe7"},"type":"device_joined"}'
Sep 21 14:16:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:16:54: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":{"friendly_name":"0x0c4314fffe62fbe7"},"type":"device_connected"}'
Sep 21 14:16:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:16:54: Starting interview of '0x0c4314fffe62fbe7'
Sep 21 14:16:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:16:54: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x0c4314fffe62fbe7","ieee_address":"0x0c4314fffe62fbe7","status":"started"},"type":"device_interview"}'
Sep 21 14:16:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:16:54: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_started","meta":{"friendly_name":"0x0c4314fffe62fbe7"},"type":"pairing"}'
Sep 21 14:19:54 Bob npm[3753]: Zigbee2MQTT:error 2022-09-21 14:19:54: Failed to interview '0x0c4314fffe62fbe7', device has not successfully been paired
Sep 21 14:19:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:19:54: MQTT publish: topic 'zigbee2mqtt/bridge/event', payload '{"data":{"friendly_name":"0x0c4314fffe62fbe7","ieee_address":"0x0c4314fffe62fbe7","status":"failed"},"type":"device_interview"}'
Sep 21 14:19:54 Bob npm[3753]: Zigbee2MQTT:info 2022-09-21 14:19:54: MQTT publish: topic 'zigbee2mqtt/bridge/log', payload '{"message":"interview_failed","meta":{"friendly_name":"0x0c4314fffe62fbe7"},"type":"pairing"}'

Originally posted by @Element2 in #14121

[samuelthng]

I am having the same issue with 3 different Tuya devices.

When I do try to remove, it will eventually fail without a force remove as well.
Pairing worked the first time, but after device reset, z2m sees the device and shows pairing but does not seem to fetch data from the device. Eventually pairing times out and fails with "device has not successfully been paired"

Let me know how I can help with this investigation! :)

[samuelthng]

Just tested a few devices on my network.
Brand new bulbs from IKEA and Tuya pair without any issues.

Paired bulbs that were reset and/or force removed:
Devices join but unable to complete interview process.
Even the image of the devices are not shown.

Seems only Aqara devices can pair again effortlessly after a reset.

Screenshot: trying to pair an IKEA TRÅDFRI GU10 bulb after resetting it for the 5th time.
Logs do not show anything very useful, just pairing failed error message after timeout.

[samuelthng]

Seems to be related: #13964

Also EZSP v6.7.*

[Koenkk]

Please test with the latest dev branch, @kirovilya added an improvement for pairing with the EZSP adapter (https://www.zigbee2mqtt.io/advanced/more/switch-to-dev-branch.html)

[Element2]

Tried to pair two different re branded Tuya devices. Those two were paired and working before and were deleted.
When I tried to pair them with latest dev just now, nothing happened. No popups in front end, nothing in logs.

[samuelthng]

Can confirm same behaviour for me - on master it shows up but can't pair. On dev doesn't show up.

[TTR6214]

I think I have the same problem.
I sucessfully paired brand new MS-108ZR out of the box (so Tuya device).
Then I force-removed this device and try to pair it again.
Zigbee2mqtt cannot recognize the manufacturer, model etc ... and cannot finish the pairing process.

I also use EZSP 6.7.8.0 (Hacked silvercrest gateway) and zibgee2mqtt in Home Assistant.

Sometimes Zigbee2mqtt success to interview this device, but it remains unsupported since Zigbee2mqtt does not recognize manufacturer and model.

Info 2022-09-25 17:28:04Successfully interviewed '0xe0798dfffe77ff04', device has successfully been paired Warning 2022-09-25 17:28:04Device '0xe0798dfffe77ff04' with Zigbee model 'undefined' and manufacturer name 'undefined' is NOT supported, please follow https://www.zigbee2mqtt.io/advanced/support-new-devices/01_support_new_devices.html

[t112013]

I have experienced a similar issue and i almost becase homeless after a mad wife had no lights :P
Well, it all started when i lost one Elko thermostat (connected but no state change,nothing), i tried repairing it and it never worked, it never came any message, almost like the device never talked to the coordinator.
So tried another dongle, i have also the sonoff dongle (the new version). and it didnt work. Then i made a new network. tried repairing all devices for the 15th time and this time some remotes and motion sensor where never coming on. Tried then ZHA and there they worked almost on the second so i though it had to be something with ZigbeetoMqtt. Then i even reinstalled home assistant to try a blank installation (though it had something to do with HA) .
I also tried now the edge branch where it actually works, but sometimes its not very responsive to pair, i have stopped and stated the add on many times, some times mqtt broker becomes unresponsive too, i have one ikea motion sensor that was very difficult to pair, i even changed batties but, sometimes its not repporting the status, it works again when i restart the whole box.
I have tried adding a develco smoke sensor, which in the DB says its supported but it also fails to interview. And a few Ikea lightbulbs that dont even show up when pairing.
Also one Namrom 4 buttons remote never shows up, but when i factory reset the remote it show device left the network ( i have two more of those, both paired with no issue)

Iam bit lost but i can patiantly wait too.
If i can somehow help, please let me know.

Btw, if it helps. for those that have no response when pairing in the edge version, remember to remove the offical add on, eventually restart the add on a few times and pair a bulb or something on mains before adding end-devices
Cheers

[samuelthng]

Hello, wanted to check if anyone else with pairing issues faced this:

• Repeated trustCenterJoin frame
• No action taken by z2m after

Not sure if it's related to the pairing issue but wanted to get some opinions and eyes on this.
https://github.com/Koenkk/zigbee-herdsman/blame/85c277f82204be6d7419df396896645da549def6/src/adapter/ezsp/driver/driver.ts#L298

2022-09-26T15:30:37.090Z zigbee-herdsman:adapter:ezsp:ezsp Time to watchdog ... 0
2022-09-26T15:30:37.090Z zigbee-herdsman:adapter:ezsp:ezsp ==> nop: null
2022-09-26T15:30:37.090Z zigbee-herdsman:adapter:ezsp:ezsp ==> {"_cls_":"nop","_id_":5,"_isRequest_":true}
2022-09-26T15:30:37.090Z zigbee-herdsman:adapter:ezsp:uart --> DATA (0,2,0): 6000010500
2022-09-26T15:30:37.091Z zigbee-herdsman:adapter:ezsp:uart --> [022221a9512a7d33367e]
2022-09-26T15:30:37.091Z zigbee-herdsman:adapter:ezsp:uart -?- waiting (1)
2022-09-26T15:30:37.095Z zigbee-herdsman:adapter:ezsp:uart <-- [2122a1a9512a35e67e]
2022-09-26T15:30:37.095Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (2,1,0): 2122a1a9512a35e67e
2022-09-26T15:30:37.095Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (3)
2022-09-26T15:30:37.095Z zigbee-herdsman:adapter:ezsp:uart --> [83401b7e]
2022-09-26T15:30:37.095Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 6080010500
2022-09-26T15:30:37.095Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x5: {"_id_":5,"_cls_":"nop","_isRequest_":false}
2022-09-26T15:30:37.096Z zigbee-herdsman:adapter:ezsp:uart -+- waiting (1) success
2022-09-26T15:30:44.368Z zigbee-herdsman:adapter:ezsp:uart <-- [3122b1a9702ae2cb24d2fb7d5d946d53ed9d4e27abe5037e]
2022-09-26T15:30:44.368Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (3,1,0): 3122b1a9702ae2cb24d2fb7d946d53ed9d4e27abe5037e00
2022-09-26T15:30:44.368Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (4)
2022-09-26T15:30:44.369Z zigbee-herdsman:adapter:ezsp:uart --> [8430fc7e]
2022-09-26T15:30:44.369Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 6090012400f7797d46b1583e38c1a40100000008
2022-09-26T15:30:44.369Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x24: {"_id_":36,"_cls_":"trustCenterJoinHandler","_isRequest_":false,"newNodeId":31223,"newNodeEui64":[164,193,56,62,88,177,70,125],"status":1,"policyDecision":0,"parentOfNewNodeId":0}
2022-09-26T15:30:47.091Z zigbee-herdsman:adapter:ezsp:ezsp Time to watchdog ... 0
2022-09-26T15:30:47.091Z zigbee-herdsman:adapter:ezsp:ezsp ==> nop: null
2022-09-26T15:30:47.091Z zigbee-herdsman:adapter:ezsp:ezsp ==> {"_cls_":"nop","_id_":5,"_isRequest_":true}
2022-09-26T15:30:47.091Z zigbee-herdsman:adapter:ezsp:uart --> DATA (1,4,0): 6100010500
2022-09-26T15:30:47.091Z zigbee-herdsman:adapter:ezsp:uart --> [142321a9512a2e027e]
2022-09-26T15:30:47.092Z zigbee-herdsman:adapter:ezsp:uart -?- waiting (2)
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:uart <-- [4223a1a9512a0e4f7e]
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (4,2,0): 4223a1a9512a0e4f7e
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (5)
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:uart --> [8520dd7e]
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 6180010500
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x5: {"_id_":5,"_cls_":"nop","_isRequest_":false}
2022-09-26T15:30:47.096Z zigbee-herdsman:adapter:ezsp:uart -+- waiting (2) success
2022-09-26T15:30:57.091Z zigbee-herdsman:adapter:ezsp:ezsp Time to watchdog ... 0
2022-09-26T15:30:57.092Z zigbee-herdsman:adapter:ezsp:ezsp ==> nop: null
2022-09-26T15:30:57.092Z zigbee-herdsman:adapter:ezsp:ezsp ==> {"_cls_":"nop","_id_":5,"_isRequest_":true}
2022-09-26T15:30:57.092Z zigbee-herdsman:adapter:ezsp:uart --> DATA (2,5,0): 6200010500
2022-09-26T15:30:57.092Z zigbee-herdsman:adapter:ezsp:uart --> [252021a9512aaafc7e]
2022-09-26T15:30:57.092Z zigbee-herdsman:adapter:ezsp:uart -?- waiting (3)
2022-09-26T15:30:57.096Z zigbee-herdsman:adapter:ezsp:uart <-- [5320a1a9512abfb97e]
2022-09-26T15:30:57.096Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (5,3,0): 5320a1a9512abfb97e
2022-09-26T15:30:57.097Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (6)
2022-09-26T15:30:57.097Z zigbee-herdsman:adapter:ezsp:uart --> [8610be7e]
2022-09-26T15:30:57.097Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 6280010500
2022-09-26T15:30:57.097Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x5: {"_id_":5,"_cls_":"nop","_isRequest_":false}
2022-09-26T15:30:57.097Z zigbee-herdsman:adapter:ezsp:uart -+- waiting (3) success
2022-09-26T15:30:58.435Z zigbee-herdsman:adapter:ezsp:uart <-- [6320b1a9702ae2cb24d2fb7d5d946d53ed9d4e27abf4447e]
2022-09-26T15:30:58.435Z zigbee-herdsman:adapter:ezsp:uart <-- DATA (6,3,0): 6320b1a9702ae2cb24d2fb7d946d53ed9d4e27abf4447e00
2022-09-26T15:30:58.435Z zigbee-herdsman:adapter:ezsp:uart --> ACK  (7)
2022-09-26T15:30:58.435Z zigbee-herdsman:adapter:ezsp:uart --> [87009f7e]
2022-09-26T15:30:58.435Z zigbee-herdsman:adapter:ezsp:ezsp <== Frame: 6290012400f7797d46b1583e38c1a40100000019
2022-09-26T15:30:58.435Z zigbee-herdsman:adapter:ezsp:ezsp <== 0x24: {"_id_":36,"_cls_":"trustCenterJoinHandler","_isRequest_":false,"newNodeId":31223,"newNodeEui64":[164,193,56,62,88,177,70,125],"status":1,"policyDecision":0,"parentOfNewNodeId":0}

Reposted in #13964

[y8s]

I recently added a Sonoff ZDongle-E (using adapter: ezsp)and was doing fine but wanted to add some range and picked up a couple Sonoff S40LiteZB and they both paired fine at first but upon re pair of one, it fails interview and sits in the device list as unsupported.

I did try the docker latest-dev tag today but then z2m wouldn't see it at all.

Current non dev setup:
Zigbee2MQTT version
1.27.2 commit: 7dc48fb
Coordinator type
EZSP v8
Coordinator revision
6.10.3.0 build 297

[FabiJa]

I am having the exact same problem after deleting a device. Also, with the current dev version, the device is not found at all.

I have a smabit Bitron USB dongle (EM3587) flashed to 6.7.10.

[Element2]

The latest dev modifications (Update Herdsman to 0.14.61) fixed the problem for me. The dev now pairs and interviews successful.
And after a forced remove again pairs and interviews successful.

[FabiJa]

I can confirm this. Nevertheless, for some devices I first get the message device has left when pairing. But then the device joins successfully.

[y8s]

I will try to get a herdsman log on the docker latest-dev sometime today.

[Element2]

Closed as this is fixed in latest dev with Herdsman 0.14.61.
See also #13964