feat: Command Response API WebSocket plumbing

[rusty-art]

Summary

WebSocket plumbing for the Zigbee2MQTT Command Response API. Routes device commands through the new /request/set|get topics and handles responses on /response/set|get with z2m_transaction correlation.

Depends on: Backend PR #30774 (Command Response API)
Related: Backend feature request #30679
Full implementation with visual feedback: transaction-response-api branch

Changes

New Files

• src/hooks/useDeviceCommands.ts — Centralised hook for device set/get routing via new topics

Modified

• WebSocketManager.ts — Transaction ID generation, callback registration with timeout, /response/* message interception
• types.ts — CommandResponse type definition
• Exposes.tsx, DashboardItem.tsx — Use useDeviceCommands hook
• GroupMembers.tsx — Route to /request/set
• store.ts — Suppress "request superseded" error toasts for sleepy devices
• mocks/ws.ts — Mock server handles new topic format

What this PR does NOT include (deferred to follow-up)

• Visual feedback components (StatusIndicator, SyncRetryButton, ApplyButton)
• Editor integration (useCommandFeedback hook)
• Read state management (useReadState, FeatureReadingContext)
• Tests for the above

How it works

1. Commands send to {ieee}/request/set and {ieee}/request/get instead of {ieee}/set and {ieee}/get
2. WebSocketManager intercepts /response/set and /response/get messages (preventing device state corruption)
3. Callback infrastructure is in place — callers can register for correlated responses via z2m_transaction, with automatic timeout cleanup
4. No UI changes — the plumbing works silently; visual feedback comes in a follow-up PR

Test Plan

• TypeScript compiles cleanly
• Biome lint/format passes
• All 47 existing tests pass
• Manual test: commands route to /request/set|get (confirmed via logs)
• Manual test: mock WS server responds on /response/set|get
• Verified: all code-in-common matches the full implementation branch byte-for-byte

[Nerivec]

Same problems as before, including the fact the PR tries to do far too much at once. The potential for issues/breaks is astronomical. (Same goes for the Z2M PR.)

[rusty-art]

understood. Will revert to bare-minimum; and replace with the zigbee2mqtt (backend) preferred MQTT topics approach in discussion. Thanks for your patience and guidance.

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.

[rusty-art]

@Nerivec This has been paired back to the bare minimum - no new device mocks/tests and no visual feedback. Just the WebSocket plumbing for the Command Response API:

• Route commands to /request/set|get (instead of /set|get)
• Handle /response/set|get messages (so they don't corrupt device state)
• Callback infrastructure with z2m_transaction correlation (ready for future use)
• Suppress "request superseded" toasts for sleepy devices

8 files, ~330 lines. (Visual feedback (StatusIndicator, retry buttons, etc.) will come in a follow-up PR once this is in):

• Production code (src/): 7 files, +175 / -49 (net +126 lines)
• Mock server (mocks/): 1 file, +151 / -9

The bulk of the production change is WebSocketManager.ts (+108) - the callback infrastructure. The rest is small: new
useDeviceCommands hook (+35), CommandResponse type (+15), and the three consumer components actually shrink because inline sendMessage calls are replaced by the hook.

Remains as 'draft' until zigbee2mqtt backend changes are merged.

[github-actions]

This pull request is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days.