Skip to main content

Notifications

Notifications let your deployment tell someone that something happened — a device came online, a parameter crossed a threshold, an automation fired. They go out over two independent channels: mobile push to users, and webhooks to your own systems.

What the user sees​

A push notification on their phone, delivered through APNs on iOS or FCM on Android. Because delivery goes to a registered device rather than an open app, a user gets it whether or not the app is running.

A push notification arriving on a phone

What the operator must do​

Push needs platform credentials before anything is delivered. In the Admin Dashboard, under Settings → Push notifications, provide the APNs and FCM credentials for your own app. Until that is configured, notification events are generated and simply have nowhere to go.

Webhooks are the other half: point them at your endpoint to receive the same events server-side, for analytics, alerting or ticketing.

What the firmware must do​

Nothing. Notifications are generated in the cloud from events it already sees — connection state, parameter reports, automation outcomes — so a node that reports its state correctly is already participating.

Limits and caveats​

  • A notification is addressed to a user, so fan-out follows Group membership: everyone with access to a Home can receive events for its nodes.
  • Push endpoints go stale when an app is uninstalled. Disabled endpoints are pruned rather than retried forever, so a user who reinstalls must register again.
  • Webhook delivery is best-effort. If your endpoint is down, treat the webhook as a notification, not as a durable queue.
  • Notification volume follows event volume. A parameter that changes every second is not a sensible notification source.