Interview issues mostly with dyi devices and generated definitions

What happened?

I investigated some interview issues that I experienced when working with esphome devices. So most of them cover scenarios where the ieee address of a (re-)joining devices is already known but some parts of the definition change (could be modelID, could be endpoint/cluster/attributes or anything else.

Issues:

• On rejoin the interview is skipped completely
• Rejoin + modelID change skips the interview but still recreates the definition. This is a big issue as z2m potentially tries to read a ton of non existing attributes. (not fully confirmed)
• join reruns interview but skips recreation of definition if modelID doesn't change, also the node descriptor might be cached (need to verify) and not sure if endpoint are updated.

I would suggest:

• On join interview should always run without caching
• On rejoin always read modelID, version and maybe NodeDescriptor/active endpoints. This might be an issue for sleepy devices if they rejoin regularly. If there is a change run full interview. not sure if this is possible
• after interview the definition needs to be regenerated, not only when ModelID change. This could be limited to generated definitions and/or we could create a hash interview results (endpoints + basic cluster + node descriptors) and compare it.

Would appreciate some feedback. I might be missing some reasons why caching is used so heavily.

What did you expect to happen?

No response

How to reproduce it (minimal and precise)

No response

Zigbee2MQTT version

2.12.1-dev

Adapter firmware version

20211115

Adapter

cc2531 (just for testing)

Setup

pnpm, linux

Device database.db entry

No response

Debug log

No response

Notes

No response

Start by tracing the interview and definition-generation paths for rejoining devices, focusing on cached IEEE addresses, modelID, node descriptors, endpoints, and clusters. Compare the listed rejoin and join scenarios, then verify whether regenerated definitions cover changed interview results; the issue provides no reproduction, file, or test, so expected behavior needs maintainer agreement first.