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.

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 Ubunto 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"}'

[jerrm]

Try the dev branch. A pairing fix for ezsp was merged in the last day or two. No real clue it will be applicable, just have seen the activity.

SI Labs chips are still tagged as experimental, but there has been a good bit of chatter and work to get past that label.

[Element2]

Thanks for the tip.
I followed it through, did a clean install of the dev version and copied only the existing database.db and state.json files to the data directory.
The dev version works with the already paired and interviewed devices.
Paring altogether does not work, nothing happens, no pop-ups on screen and nothing in the logs.
Permit join is true in configuration.yaml

Switched back to the latest master branch and pairing works again, but still without a successful interview.

[jerrm]

Maybe @Koenkk or @kirovilya can chime in.

If you are inclined to help debug this, it's common for @Koenkk to ask for the zigbee-herdsman logs as well.

[jerrm]

Also...

May be better tracked as an issue instead of discussion? Not sure what @Koenkk prefers or if he cares.

[Element2]

No problem to help with debugging.
Now if I only knew how to move this to 'issue'..

[jerrm]

I'm sure the help will be welcome. I thought that would be the case, but didn't want to assume. I personally don't like it when a community expects every user to be a tech and invested in the project. OSS depends on those folks, but it's also OK for someone to want something that "just works," and to move on if it doesn't fit their needs.

I don't know, but expect the potential ezsp issues will escalate when HA releases their Skyconnect dongle. Probably best if things can be addressed sooner than later.

[Element2]

I certainly don't expect developers to spend there time solving every problem with esoteric hardware combinations.
In my case ezsp may not even be the culprit, since the Lidl/Tuya gateway is in the middle.
So I truly appreciate any assistance with this. If I can help just a tiny bit it's happily done.
And coming from Deconz/Phoscon with Domoticz I must say I am pleasantly surprised by the amount of supported hardware and the very nice and functional front end. I especially like the mqtt part, which I already use together with Node Red.
Anyway, figured out the zigbee-herdsman logs, so I am ready to supply them when they are needed.

[findusl]

I have the same problem with the Lidl window Contacts. I'm using a Conbee II Adapter.

I would appreciate help with this. My only alternative is to throw the contacts away and buy new ones as it seems to work fine with new contacts.

[findusl]

I do assume it is some value in the Lidl devices that prevents to correctly rejoin, as the window sensors light up red since the disconnect and reconnect. But it could also just be the triggered tamper sensor, although I did a reset of the sensors multiple times...

[Element2]

This was fixed some time ago.
See #14135