meshcore-client

Commit Graph

Author	SHA1	Message	Date
Strycher	4b337be586	feat(#483 ): Button and buzzer settings for headless devices Client UI for the button-action matrix (#474) and the device notification scope (#475), under Settings > Node Settings. Speaks the canonical 0xC5 contract published by firmware in OffbandConfigProtocol.h: one command byte, sub-code selects the surface (0x01/0x02 scope get/set, 0x03/0x04 matrix get/set, 0x7F error). Not folded into 0xC0, which is observer-only and would make the feature unreachable on the headless trackers it exists for. - Notification scope All/Self/None, labelled as this radio's buzzer and kept distinct from the per-channel app notify mode. Re-read on open and on every device-info refresh so a scope changed by triple-pressing the device is never shown stale. - Button actions per press sequence, assignable only from the action set the DEVICE reports via its supported-actions mask, so a board with no buzzer or no GPS never offers a choice it would refuse. Single press defaults to unassigned. - Long press is deliberately not assignable. Firmware owns it for CLI rescue and power off, and remapping it could leave a screenless board unrecoverable. - Failures show the device's own reason via the firmware-owned reason codes, not a generic error, and the banner persists until dismissed. An unrecognised reason is surfaced with its raw code rather than swallowed. - State only ever follows the device's reply, never the request, so the UI can never show an assignment the radio rejected and nothing is faked or stored unacknowledged. - A radio advertising neither capability bit gets a diagnosis, its raw caps byte 2 and an explicit statement that no command will be sent, rather than a blank screen that is indistinguishable from a bug. caps2 bit assignment is firmware-confirmed: 0x01 notification scope, set only where PIN_BUZZER is defined, 0x02 button matrix. That is the reverse of the order the epics were filed in, so it cannot be inferred from issue numbers. 21 protocol tests: gating, frame encoding, a lying count byte, unknown sequence/action/scope codes, truncated and foreign frames, reason-code mapping, and that no sequence models a long press. NOT YET EXERCISED AGAINST A DEVICE. The firmware 0xC5 handler is written but unmerged, so until it answers, a read shows its loading row and a write is not confirmed. Hardware validation of the pair is the owner's gate and has not happened. Full suite 740 pass, analyze clean, format clean. Epic: #474, #475 Agent: CalmBay (session d14220d9)	2 months ago

Author

SHA1

Message

Date

Strycher

4b337be586

feat(#483 ): Button and buzzer settings for headless devices

Client UI for the button-action matrix (#474) and the device notification
scope (#475), under Settings > Node Settings.

Speaks the canonical 0xC5 contract published by firmware in
OffbandConfigProtocol.h: one command byte, sub-code selects the surface
(0x01/0x02 scope get/set, 0x03/0x04 matrix get/set, 0x7F error). Not
folded into 0xC0, which is observer-only and would make the feature
unreachable on the headless trackers it exists for.

- Notification scope All/Self/None, labelled as this radio's buzzer and
  kept distinct from the per-channel app notify mode. Re-read on open and
  on every device-info refresh so a scope changed by triple-pressing the
  device is never shown stale.
- Button actions per press sequence, assignable only from the action set
  the DEVICE reports via its supported-actions mask, so a board with no
  buzzer or no GPS never offers a choice it would refuse. Single press
  defaults to unassigned.
- Long press is deliberately not assignable. Firmware owns it for CLI
  rescue and power off, and remapping it could leave a screenless board
  unrecoverable.
- Failures show the device's own reason via the firmware-owned reason
  codes, not a generic error, and the banner persists until dismissed.
  An unrecognised reason is surfaced with its raw code rather than
  swallowed.
- State only ever follows the device's reply, never the request, so the
  UI can never show an assignment the radio rejected and nothing is
  faked or stored unacknowledged.
- A radio advertising neither capability bit gets a diagnosis, its raw
  caps byte 2 and an explicit statement that no command will be sent,
  rather than a blank screen that is indistinguishable from a bug.

caps2 bit assignment is firmware-confirmed: 0x01 notification scope, set
only where PIN_BUZZER is defined, 0x02 button matrix. That is the reverse
of the order the epics were filed in, so it cannot be inferred from issue
numbers.

21 protocol tests: gating, frame encoding, a lying count byte, unknown
sequence/action/scope codes, truncated and foreign frames, reason-code
mapping, and that no sequence models a long press.

NOT YET EXERCISED AGAINST A DEVICE. The firmware 0xC5 handler is written
but unmerged, so until it answers, a read shows its loading row and a
write is not confirmed. Hardware validation of the pair is the owner's
gate and has not happened.

Full suite 740 pass, analyze clean, format clean.

Epic: #474, #475
Agent: CalmBay (session d14220d9)

1 Commits (dev)