Consistent devLabel use: pass the model where it is in scope

[krobipd]

What this does

Addresses #2933 — the requested review of every devLabel call site, split into the three cases from the issue. 172 active call sites (plus 5 in comment blocks) were read in their function context and classified individually; the full classification is reflected 1:1 in the diff:

Case 1 — the model is in scope (111 sites): they now pass it as third parameter. The expression is always the mapped model (the common.type key space, 'group' for groups, 'Coordinator' for the coordinator) — taken from the enclosing function's model parameter, mappedModel/mappedDevice, or entity.mapped?.model. No site passes a raw modelID where a mapped model exists. In the receive path (onZigbeeEvent and below) the in-scope model is entity.mapped?.model ?? device.modelID, which is exactly what updateDev writes to common.type, so the label lookup stays in one key space.

Case 2 — calling devLabel makes no sense (review round, now 14 sites + 2 name-only warnings): all messages concerning missing, empty or orphaned states/objects are object-tree diagnostics — the raw id is the key for finding them there, the device name is not desired information. These now print the id instead of the label:

• the elevated-debug missing-state/value messages in publishFromState (NOSTATES, NOVAL1) and publishToState (NOSTATE ×2, ESTATE, "No value published"); their sibling NOSTKEY identified the object neither by name nor by id and now carries the id as well
• the disconnected-state cleanup messages in deleteOrphanedDeviceStates (keeping/deleting, both log and admin dialog output)
• the delete-device debug in leaveDevice (the identity was logged one line above by the leave event)
• the deleteObj warning (the original case-2 site): devId there can be any object path, e.g. a state id
• two icon warnings (AddModelFromHerdsman, updateDev) printed a bare device name with no id at all — they now print the id, and the name lookup that only served the first message is gone

Traffic-, converter- and event-level messages (incoming events, publishes, pings, OTA, queries) keep the label — there the device identity is the useful information, and the id stays part of the label anyway.

Case 3 — no model available at the call site (35 sites): deliberately left id-only: paths before/without entity resolution, admin message handlers, delayed actions, availability paths that only have the herdsman device. The per-device override and the cached object name still resolve there; only the last-resort model default is unavailable.

The devLabel methods on StatesController, ZigbeeController and BaseExtension remain exact (idOrIeee, model) pass-throughs to lib/deviceLabel.js.

Name resolution order

With the model now arriving at the resolver, the default chain in devLabel is:

1. local-config override — per-device wins over per-model; the per-model lookup is what was dead while no call site passed the model
2. cached object name — matches what the admin shows, and keeps real group names: a group publish arrives with model === 'group', and that string must not beat a cached "Kitchen"
3. the model itself — covers devices without an object, e.g. while pairing, where the previous fallback chain ended at unnamed (ieee)
4. unnamed (id) / unknown device for an invalid id — unchanged

An empty-string model is treated as absent (publishFromState can be reached with model === '' for unsupported devices; '' is not nullish and would otherwise suppress the fallbacks).

Label bugs fixed on the way

• publishPayload error path built the label from payload.device — payload may be the raw JSON string, so the log said unknown device. Now payloadObj.device (with the model, which is resolved at that point).
• The removeDevFromGroup exception message printed the device label a second time where the group id belongs.
• Two group member read labels in readMemberStatus used member.id, which does not exist on the members the zigbee controller's getGroupMembersFromController returns ({ieee, model, epid, deviceNetworkAddress, ep}) — now member.ieee like the neighbouring labels in the same function.

Verification

• every edit was applied by an exact-match, line-addressed transform and the complete diff re-reviewed hunk by hunk; the remaining id-only sites were enumerated afterwards and match the case-3 classification exactly
• node --check on all touched files, ESLint clean, npm test green
• resolution chain covered by a 17-case functional test against lib/deviceLabel.js plus the real StatesController.verifyDeviceName (custom-name precedence, per-model override with/without model, group name vs 'group', empty-string model, ns-prefixed/bare/numeric ids, never-throw contract)
• rebased onto current master (the insertedDeviceLeave overlap with Fix ignore_device_delete: TypeError on device leave, option lookup never matched #2935 is resolved on top of the merged version)

🤖 Generated with Claude Code

[asgothian]

I'm afraid this change falls short of the requirements. Please verify all instances within the statescontroller, where errors / messages concerning missing states, missing objects or similar occur. For all those cases, the given name of the device is not desired information, as the correct ID for the object is the key for finding them in the object tree.

I only did a rough check - all messages of that case still called devName, even though they really should not.

A.

[krobipd]

Sorry for the inconvenience — I clearly read the requirement too narrowly the first time, and I appreciate you taking the time for another round on this.

Now implemented: all messages in the statescontroller concerning missing, empty or orphaned states/objects print the raw object id instead of the label — the missing-state/value debug messages in publishFromState/publishToState, the keeping/deleting messages in deleteOrphanedDeviceStates, and the delete-device debug in leaveDevice. Two icon warnings (AddModelFromHerdsman, updateDev) even printed a bare device name with no id at all — they now print the id as well.

Traffic-, converter- and event-level messages keep the label — there the device identity is the useful information, and the id stays part of the label anyway. If I've still missed messages you'd want switched to the id, just name them and I'll adjust right away.

Also rebased onto current master (the insertedDeviceLeave overlap with #2935).

[asgothian]

can you please rebase onto the current master to resolve the conflict ?

A