Quiet Time settings currently seem to be all or nothing (iOS, Pebble Time 2). I need better controls on what notifications get through during quiet time, not just “allow all calls” or “hide/show notifications.”
iOS already has granular settings to allow starred contacts to “get through” when the iPhone is in DND, can the Pebble not just mimic those settings? I want to be able to let texts from my daughter or my mom to get through during “quiet time” but not all of the other texts. Same with phone calls - certain contacts only should get through.
Same with specific apps - I need to know if the alarm is going off at my business, so I need to allow those notifications through on a certain app, but I don’t need other apps interrupting quiet time.
4 Likes
Shawn
July 25, 2026, 6:32am
2
I also want this feature. I assumed marking the star next to a contact would allow them through quiet time but that’s not the case.
A “quiet time bypass” list of contacts and apps could then be added to the drop down rather than only allowing calls.
1 Like
There are open PRs for the mobileapp and the watch here:
master ← vvzvlad:rfc/respect-phone-dnd
opened 02:11AM - 22 Jul 26 UTC
> **Paired PR:** the firmware half lives in [coredevices/PebbleOS#1772](https://… github.com/coredevices/PebbleOS/pull/1772) (branch `rfc/phone-dnd-silent`) — it reads the ANCS silent flag, honours the wire `SILENT` bit platform-neutrally, and enforces quiet delivery when the synced `notifRespectPhoneSilence` pref is on. Each PR stands alone: firmware without this app change is inert; this app change without the firmware syncs a pref no watch reads.
>
> **Not compiled:** this machine has no JDK 17 / Android SDK, so the change was verified by manual compile-correctness passes (property/interface threading, exhaustive `when`s, signatures, wire encoding) but has NOT been built. Build + run before treating as working code.
## What this does
The [firmware half](https://github.com/coredevices/PebbleOS/pull/1772) honors a per-notification "silent" wire flag (bit 6 of the TimelineItem flags byte) and a syncable watch pref `notifRespectPhoneSilence`: when the pref is on, silent-flagged notifications get quiet delivery — stored and listed, no popup/vibration/backlight. This PR is the minimal app side that turns it on, **reusing the existing toggle instead of adding a second one**.
**The single control is the existing "Respect Phone Do Not Disturb" toggle** (Phone → Notifications). It was Android-only — gated on notification-filtering support, which iOS lacks because ANCS delivers notifications straight to the watch, bypassing the app. This PR:
- un-gates that one toggle so it shows on **both** platforms, and
- on change, mirrors it to a **hidden** synced watch pref `notifRespectPhoneSilence` — a `BoolWatchPref` with `userVisible = false`, so it is the firmware key and rides the existing watch-pref sync, but renders **no row of its own** (no duplicate toggle).
**iOS** — the app can't see the notification stream (ANCS goes phone→watch directly), so enforcement is firmware-side ([coredevices/PebbleOS#1772](https://github.com/coredevices/PebbleOS/pull/1772)); toggling just syncs the pref and the firmware acts on the ANCS silent bit.
**Android** — unchanged: the toggle still writes the existing `respectDoNotDisturb` config (the local-drop behaviour), and additionally syncs the pref, which is a harmless no-op there. See the next section for why the Android *behaviour* is deliberately left as-is.
This PR also declares `TimelineItem.Flag.SILENT(6)` — the wire-protocol counterpart of the firmware header bit — so the contract is documented in one place, even though nothing in this PR emits it.
## ⚖️ The Android wiring is a maintainer decision — this PR deliberately does NOT change Android
On Android the app *is* in the notification path, so unlike iOS it can act on DND itself. What should it do with a notification the phone delivered silently (DND/Focus)? Two defensible answers, and **which one ships is your call — this PR takes neither on Android, it leaves the status quo in place**:
**Option A — drop (status quo, what this PR keeps).** The existing `respectDoNotDisturb` toggle doesn't forward DND-suppressed notifications; they never reach the watch. Pros: watch stays clean, zero new moving parts, no firmware dependency. Cons: the notification is *gone* from the watch — it exists in the phone's shade but leaves no trace on the wrist; and it diverges from what the firmware currently does on iOS (lists it silently). That divergence is a design choice, not a platform limit — the firmware could equally discard silent notifications on iOS instead of listing them — but as written, iOS lists and Android drops.
**Option B — forward-but-quiet (NOT implemented here).** The app would forward the notification tagged with `SILENT`; the firmware stores and lists it without alerting. Pros: the watch stays a complete mirror of the phone's list, just without the buzz — identical to iOS, and matches how the phone itself treats DND (deliver quietly, not discard). Cons: changes what existing Android users see (notifications that used to vanish would appear, silently); on old firmware that ignores bit 6 they would arrive *alerting*.
**My preference: Option B (keep them on the watch).** I think keeping the notifications on the watch is the more correct behaviour — they can still be read, they just don't interrupt while DND is on. That mirrors the phone itself, where DND'd notifications stay visible in the shade rather than being discarded; dropping them on the watch throws away information the user may still want. I've left this PR on the conservative status quo (Option A) rather than change Android behaviour unilaterally, but my vote is Option B on both platforms.
The only Android-relevant addition here is the `SILENT(6)` wire-flag *definition*, so that if maintainers later choose Option B it needs no protocol change — just the emit path (set the flag when `matchesInterruptionFilter()` is false, per-notification, so Focus per-sender exceptions still alert).
## Tests
- `TimelineFlagSilentTest` (commonTest): `TimelineItem.Flag.SILENT.value == 6` and `makeFlags(listOf(SILENT))` emits bit 6 (`0x40`).
Not run locally (no toolchain) — see the warning at the top.
## Known trade-offs
- **Old firmware + new pref:** on iOS, enabling the toggle while running firmware that doesn't understand the pref simply does nothing (the firmware ignores an unknown synced pref). No misbehaviour — the feature just stays off until the firmware half ships.
- **No reverse sync:** the toggle's checked state reads the `respectDoNotDisturb` config and its handler mirrors that value to the synced pref, so the two stay consistent from the UI (reset-to-defaults also skips the hidden pref). Nothing reads the pref back into the config, so they could only diverge if something wrote the pref watch-side independently — a path that doesn't exist today (the pref has no watch UI). Noted for completeness.