Manage notification preferences on mobile
Mobile notification preferences live at More → Notification settings. The screen exposes four toggles. Every change persists locally (in MMKV) and is PATCHed to the cloud user-preferences endpoint so the values follow your account.
Push notifications (master toggle)
The first toggle controls whether NovaVMS sends alerts to this phone at all.
- Off → On: the app requests the OS notification permission (iOS / Android 13+ prompt), then registers this device’s Expo Push token with the cloud. The row description reads “Push enabled” on success.
- On → Off: the app revokes this device’s push token from the cloud. Pushes for this phone stop immediately; alerts still appear in the Alerts tab when you open the app.
When the OS has permanently denied permission
If you previously tapped “Don’t Allow” on the OS prompt (or set it to “Off” in system Settings), the in-app toggle alone cannot recover. The app surfaces an Open System Settings button below the toggle. Tap it to deep-link to the OS notification settings for NovaVMS. Grant permission there and return to the app — the screen re-checks permission on every focus return, so the CTA disappears and the toggle becomes operable immediately.
Below the toggle, a status string describes the current OS permission:
| Status text | What it means |
|---|---|
| ”Permission granted” | The OS allowed push; the app will deliver |
| ”Push enabled” | The toggle is on and the device is registered |
| ”Permission denied — toggle to grant” | The OS denied but can still ask again — toggle the row to retry |
| ”Permission denied in system settings” | The OS permanently denied — use Open System Settings |
| ”Permission not yet requested” | The toggle was never turned on |
| ”Push disabled on this device” | Either the toggle is off or revoke succeeded |
| ”Push notifications not available on this device” | You are on a simulator / emulator (Expo Push needs a real device token) |
| Various specific errors | ”Push setup error — please reinstall the app”, “Could not get push token — try again”, “Expo Push registration failed: …”, “Server registration failed (HTTP 5xx): …” — each maps to one well-known failure inside the registration pipeline so operations can diagnose without a debugger |
Critical alerts only
When ON, the app stores your intent to receive only high-severity pushes. Cloud-side enforcement is NOT yet wired in v1 — the dispatcher does not currently read settings_json.push.critical_only before fan-out. The toggle persists locally and PATCHes the cloud so the value is ready when dispatcher honors it in a future release.
Off by default. Operators who only want to be paged for life-safety or perimeter intrusion (not analytics chatter) should turn this on — but verify with your admin that the cloud dispatcher honors it before relying on it.
The row is disabled when Push notifications is OFF — there is no push to filter.
Quiet hours (22:00 – 07:00 local)
When ON, the app stores your intent to suppress push delivery between 22:00 and 07:00 local time, every night. Cloud-side enforcement is NOT yet wired in v1 — the dispatcher does not currently read the quiet-hours preference before fan-out. The window is fixed in v1 — there is no per-rule scheduler and no custom start/end time. When the cloud honors it, critical-severity alerts will still deliver during quiet hours.
The row is disabled when Push notifications is OFF.
Daily email digest
When ON, the cloud emails you a once-per-day roll-up of all alerts. This is a profile-level preference (not specific to this device) — turning it on or off here flips the same flag the web Account screen flips.
This row is always enabled, even when Push notifications is OFF. Email is independent of push.
What changes are saved where
| Setting | Persisted to | Synced to backend |
|---|---|---|
| Push master | MMKV (local) + cloud user-preferences endpoint | Yes |
| Critical only | MMKV + cloud | Yes (settings_json.push.critical_only) |
| Quiet hours | MMKV + cloud | Yes |
| Daily email digest | Cloud user-preferences | Yes |
If a backend sync (PATCH /api/v1/user/preferences) fails (offline, server 5xx), the local choice applies on this device. Replay of failed PATCHes on next boot is not yet implemented in v1 — track and re-toggle if you depend on the cloud value being current.
What this screen does NOT do (v1)
- No per-rule notification routing. Mobile cannot mute individual alert rules in v1; rules are configured on the web.
- No per-camera mute. Mobile cannot silence a specific camera; the granularity is org-wide.
- No custom quiet-hours window. The 22:00–07:00 window is hardcoded for v1; a per-day scheduler is a future release.
- No SMS notifications. Out of scope for v1.
Related
- Respond to a push alert
- Troubleshoot mobile — when push goes silent
- Watch live on mobile