Cloud Alerting Platform for Connected Sensors

A connected-hardware product team came to us with a working sensor prototype. When a reading crossed a configured threshold it fired an alert through a third-party notification service. It proved the concept, but it could not be sold: there was no device registry, no structured event data, and no way to reach units already installed in the field. CYBORG designed and built the entire cloud platform underneath it, and stayed on through every phase of the rollout.

• Delivered end to end: discovery and architecture, the MVP platform, the operational layer and the customer portal.
• Sensors connect over cellular LTE-M, independent of the customer's own network.
• Threshold events reach the user's phone as a push notification within seconds.
• Alerts arrive through a Progressive Web App, with no app store in the loop.
• Devices already in the field are managed and updated over the air, with no site visit.

Dependency on a third party:
Every alert in the prototype was routed through an external notification service that also owned the device names, the recipient lists and the message text. The product roadmap, and the customer data, sat inside a tool the business did not control.

No device identity:
Sensors had no unique credentials and no registry behind them. There was no way to tell which physical unit sent an alert, to revoke a unit, or to know whether a deployed device was still online.

Unstructured events:
The prototype sent an ad hoc API call rather than a defined message. Without a stable schema there was no notification history, no reporting, and no safe way to evolve the firmware and the cloud independently.

No route back to the device:
Communication was one way. Thresholds could not be adjusted, units could not be activated or deactivated, and firmware could only be updated by physically visiting the installation.

No model for installations:
One sensor notifying one phone works as a demo. A commercial rollout needs customers, sites, device groups and multiple recipients per group, and none of that existed.

No path to self-service:
Every change to a recipient list or a threshold would have landed on the product team as a support request, which puts a hard ceiling on how many installations the business can carry.

Discovery before build:
We opened with a short discovery phase alongside the hardware team to lock the system architecture, the device-to-cloud communication model and the exact event message structure. That contract let firmware and cloud work run in parallel without blocking each other.

Managed IoT connectivity:
Devices publish over MQTT to AWS IoT Core using a per-device certificate and a persistent connection. A cellular LTE-M connection keeps the unit off the customer network entirely, which removes the most common cause of failed installs.

A defined event contract:
Every alert carries a device identifier, event type, timestamp, sensor value and firmware version. That single decision unlocked notification history, device health monitoring and later analytics without another firmware change.

Event-driven notification routing:
An incoming event is validated, stored and matched against the recipients for that device group immediately on arrival. Nothing waits for a scheduled job, which is what keeps end-to-end delivery inside seconds.

Progressive Web App for alerts:
Users install the alert app straight from a browser link and receive Web Push notifications on the phone. One codebase covers iOS and Android, and fixes ship the same day instead of waiting on app store review.

A structured data model:
Customers, installations, device groups, individual sensors and registered user devices are modelled explicitly in PostgreSQL. Adding a site or moving a device between groups is an admin action rather than a code change.

Operational dashboard:
An internal web dashboard gives the operations team live online and offline status for every deployed unit, full notification history, and delivery monitoring, so a silent sensor is noticed before a customer reports it.

Two-way control and OTA:
The same MQTT channel carries commands back to the device. Thresholds can be tuned, units activated or deactivated, diagnostics requested, and signed firmware pushed over the air to sensors already installed.

Customer self-service portal:
Customer administrators manage their own device groups, users and notification rules, with reporting over their own event history. Routine changes stop being support tickets while central operational control stays with the product team.