feat: route User Code CC setValue calls through access control API, bump schema to 51

[raman325]

Summary

zwave-js (zwave-js/zwave-js#8930, targeting next) made the unified Access Control API the source of truth for User Code CC: the userCode/userIdStatus/adminCode values became internal and their setValue/pollValue support was removed. Clients that manage user codes via the node.set_value path (e.g. existing Home Assistant installs) would silently break once the server ships a driver containing that change.

This PR routes those legacy setValue calls through the access control API on a best-effort basis, covering every path the old UserCodeCC SET_VALUE implementation supported:

Legacy setValue call	Routed to
userCode (string)	accessControl.setCredential(...)
userIdStatus = Available	accessControl.deleteCredential(...)
userIdStatus = Enabled	accessControl.setUser(userId, { active: true })
userIdStatus = Disabled	accessControl.setUser(userId, { active: false })
userIdStatus = Messaging	accessControl.setUser(userId, { active: true, userType: NonAccess })
adminCode / masterCode (string)	accessControl.setAdminCode(...)

Not routed: keypadMode still works through setValue upstream, and userIdStatus = PassageMode has no access control equivalent (documented as no longer supported).

Implementation notes:

• The credential type is derived from getCredentialCapabilitiesCached() (PIN code, or Password for locks that allow non-PIN characters) rather than hardcoded
• The endpoint is resolved from valueId.endpoint, and anything unroutable (other properties/values, non-numeric propertyKey, unsupported endpoint/type) falls back to node.setValue unchanged
• Results are converted back to SetValueResult (SetCredentialResult/SetUserResult via local converters, setAdminCode's supervision result via supervisionResultToSetValueResult) so the response shape is unchanged for callers

The routing intentionally applies to all schema versions: the clients that need it are the ones that have not adopted the access control API, and the legacy behavior it would otherwise preserve no longer exists in zwave-js. Schema 51 documents the behavior change; clients targeting schema 51+ should use the endpoint.access_control commands directly.

Changes

• src/lib/node/message_handler.ts: trySetUserCodeValue() shim + result converters
• src/lib/const.ts: maxSchemaVersion 50 → 51
• API_SCHEMA.md: Schema 51 entry

Testing

• prettier --check, tsc --noEmit, and eslint pass
• tsx src/test/integration.ts passes

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR preserves compatibility for legacy clients that use node.set_value to manage User Code CC credentials by routing those specific setValue calls through the unified Access Control API introduced/required by upstream zwave-js changes. It also bumps the documented API schema to reflect this behavioral change while keeping the response shape stable for callers.

Changes:

• Add a best-effort shim in the node setValue handler to translate legacy User Code CC writes into accessControl.setCredential(...) / accessControl.deleteCredential(...).
• Convert SetCredentialResult back into a SetValueResult so the outward node.set_value response remains consistent.
• Bump maxSchemaVersion to 51 and document the behavior in API_SCHEMA.md.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
src/lib/node/message_handler.ts	Adds User Code CC setValue routing via Access Control API and result conversion logic
src/lib/const.ts	Bumps supported schema max from 50 to 51
API_SCHEMA.md	Documents schema 51 behavior change for legacy User Code CC node.set_value writes

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[AlCalzone]

LGTM. Do you have any way to test this?

[raman325]

If I build everything locally I can try the old services in HA which will exercise this path. I can't test all the conditions but I can validate at least the set and delete get done properly. I'll look into this later today

[raman325]

tested and successfully working (I had to send Websocket commands manually since, per my comment on Discord, HA services are going to break and there's nothing we can do about it)