Respond to a push alert on mobile
When an alert rule fires on a camera assigned to you, NovaVMS can push a notification to your phone. Tapping the notification opens the matching screen directly — you do not have to navigate from the inbox.
This page explains the push flow, the deep-link routing rules, and what to do when push is silent.
How push reaches your phone
NovaVMS uses the Expo Push Service as the dispatcher. Expo Push relays to:
- APNs on iOS
- FCM on Android
The cloud stores your device’s push token in the device_tokens table (the same table the D48 mobile-API design future-proofed for this). One token type — Expo Push — covers both platforms; you don’t need to set up Firebase or APNs certificates locally. The cloud’s ExpoDispatcher posts each alert payload to Expo Push, which forwards to APNs or FCM based on the device.
Foreground vs. background presentation
| App state | What happens when a push arrives |
|---|---|
| App is open in foreground | The OS shows the banner + plays sound (you stay where you were). The Alerts tab badge increments immediately, before the next /api/v1/alerts poll. |
| App is in background | The OS shows the banner in the system tray. Tap it to open the app on the deep-link target. |
| App is killed (cold start) | The OS holds the notification. Tap it to launch the app; the launch flow finishes routing to the deep-link target after the splash. |
The app sets shouldShowBanner: true, shouldPlaySound: true, shouldSetBadge: true, shouldShowList: true so foreground arrivals are visible — the cloud already respects per-org quiet hours server-side, so if a push reached your device, the app is allowed to show it.
Deep-link routing
NovaVMS uses the custom URL scheme novavms://. Each push payload carries a data.deep_link string. When you tap the notification, the app opens the matching screen:
| Deep link | Screen | Use |
|---|---|---|
novavms://alert/<alert-id> | Alert detail | The alert that fired (default for alert-rule pushes) |
novavms://event/<event-id> | Event detail | A specific event with its clip + AI summary |
novavms://camera/<camera-id> | Live view | Direct live view (used by the Share button in Live view) |
novavms://alerts | Alerts inbox | The alerts list (used by aggregate-style pushes) |
The HTTPS-based universal link prefix https://novavms.novalien.com is also advertised by the linking config. iOS universal links require the cloud to serve apple-app-site-association and Android app links require assetlinks.json; treat HTTPS deep-link arrivals as best-effort until your admin confirms both files are served.
What happens after a tap
- The OS hands the deep-link URL to the NovaVMS app.
- The app’s notification handler parses
data.deep_linkand callsLinking.openURL(deep_link). - React Navigation matches the URL against the app’s linking config and pushes the matching screen onto the stack.
- Once you reach Alert detail, the timeline shows the rule that fired and the triggering event’s snapshot. From there you can Acknowledge, Resolve, or open the underlying event to watch the clip.
If the deep link is malformed or the underlying event was deleted, the app logs the error and falls back to the matching tab (Alerts) so you can locate the alert by hand.
Make sure push will actually arrive
Push requires three conditions to all hold:
- The OS has granted the app notification permission. On iOS this is “Allow notifications” in Settings → NovaVMS. On Android 13+ it is the
POST_NOTIFICATIONSruntime permission. Without this, the app cannot register its token. - You have toggled “Push notifications” ON in the app. See Manage notification preferences. Toggling it on is the contextual moment at which the app requests the OS permission.
- Your assigned alert rules are firing. Alert rules are configured on the web (mobile only surfaces fired alerts, not the rule editor).
Android — the alerts notification channel
Android 8+ requires notifications to be routed through a notification channel. The app registers a channel called alerts at boot with HIGH importance, so pushes ring through audibly even on devices that default to silent.
You can override the channel’s importance in Android Settings → Apps → NovaVMS → Notifications → Alerts. Setting it to “Silent” mutes pushes app-wide without changing your in-app preferences.
iOS — provisional permission and the system Settings fallback
On iOS, the app requests “provisional” notification permission at boot (silent delivery to Notification Center, no banner). This means even users who never explicitly tapped “Allow” still get their first few notifications delivered quietly. Once you toggle push ON in the app, the system upgrades to full permission with banner + sound.
If you previously tapped “Deny” on the OS prompt, the app cannot ask again — re-enable in iOS Settings → NovaVMS → Notifications, then return to the app.
If push is silent
- You toggled push ON but no alerts arrive: open More → Notification settings and check whether the row description says “Permission denied in system settings”. If so, tap Open System Settings and grant notification permission. The app re-checks on every focus return, so the toggle becomes live as soon as you switch back.
- Push works in the foreground but not when the phone is locked (Android): the
alertschannel was downgraded to silent. Re-enable in Android Settings → Apps → NovaVMS → Notifications. - Push works on Wi-Fi but not on LTE: Expo Push delivery depends on APNs / FCM, which require a working data connection. Your carrier may be filtering — try Wi-Fi to confirm.
- A specific alert never reached the phone but appears in the Alerts tab: the underlying rule fired but quiet-hours filtered the push, or the push payload was rejected by the OS. The web Alerts list is the canonical history; the phone push is a delivery surface only.
See Troubleshoot mobile for more recovery steps.
Related
- Manage notification preferences
- Acknowledge or dismiss an alert (operator how-to, web) — the same flow, web-side
- Why refresh tokens are bound to User-Agent — why your mobile session can survive a network change