Notifications and buzzer profiles

Devices MAY surface received messages through haptics, buzzer, screen, or LED. LowMesh separates channel policy from payload type.

Per-channel mute

Each configured channel slot (0–15, aligned with lowmesh::nvm::Crypto::channels[] / ChannelPrefs) has:

Setting	Description
muteNotifications	If true, no user-visible notification for new messages (still MAY log to buffer).
muteBuzzerOnly	If true, silent on buzzer but allow screen/LED (optional fine control).

These settings are local UI policy stored in device NVM. They do not alter RF behavior.

Buzzer audio profiles

To distinguish which channel fired without looking at the screen, each channel binds to a buzzer profile ID (0–15).

Profile record

Field	Size	Description
profileId	1	0–15
patternCount	1	Number of beep segments
segments	4 × N	Each segment: onMs (uint16), offMs (uint16)

Example: Configured channel slot 0 → default buzzer profile 0 (single beep); configured channel slot 1 → profile 1 (short-long); configured channel slot 2 → profile 2 (two short pulses). These are local NVM channel slots, not on-air channelHash values — see Channels & security.

Default

If buzzerProfileId is not set for a channel, implementations SHOULD use profile 0.

Priority override

Payload flag PRIORITY_ALERT MAY force buzzer even when muteBuzzerOnly is set (e.g., SOS). This MUST be user-configurable to avoid abuse.

Emoji and multilingual text

Notification title/summary uses the same UTF-8 decoding as Text encoding. Buzzer patterns are not language-dependent.

API exposure

See USB & BLE hex API for NOTIFY_POLICY_SET and NOTIFY_POLICY_GET framing examples.