Every consumer IoT solution on the market failed on battery economics. Devices drained power within months, requiring regular site visits to swap batteries. For deployments at scale, this maintenance overhead destroyed unit economics. The requirement was clear: build an IoT infrastructure capable of multi-year operation without human intervention while maintaining continuous, real-time communication.

Off-the-shelf cloud platforms couldn't meet the requirement. Most relied on polling architectures that kept radios active, draining batteries. Vendor-locked ecosystems offered no control over alert routing, device configuration, or data ownership.

CXAlerts platform dashboard showing live device status streaming. Each entry displays Device ID (Shelly DW2 model identifier), battery level (100% indicates full charge), door state (open/close), and last update timestamp. Periodic heartbeat updates from devices in deep sleep mode confirm connectivity without draining battery.

Complete system architecture showing five layers: IoT hardware (Shelly DW2 sensors with deep sleep), MQTT messaging infrastructure (Mosquitto broker), backend services (Node.js API, Python event handler, MySQL database), frontend interfaces (Angular web and mobile applications), and multi-channel alert delivery (SMS, voice call, email). Configuration flow via HTTP API shown on right.

Device Provisioning: Each Shelly DW2 pre-configured via HTTP API with MQTT broker credentials (IP address, port, username, password) and assigned unique device ID before deployment. Settings configured remotely without physical access.

User Account Creation: End users created accounts via web or mobile app, entered location details, set initial alert preferences (SMS, call, email, or combinations).

Device Pairing: Users scanned device QR codes or entered device IDs to link sensors to their accounts. Assigned human-readable names for easy identification.

Testing and Validation: Each paired device transmitted test event to confirm end-to-end connectivity—from sensor to MQTT broker to backend to alert delivery across selected channels.

Live Monitoring: Once validated, devices entered operational mode. All door events triggered alerts per user preferences. Deep sleep heartbeat updates confirmed device health without manual checks.

MQTT Over HTTP Polling: MQTT's publish-subscribe model meant devices only transmitted data when events occurred or on scheduled heartbeat intervals. HTTP polling would have required devices to check for updates repeatedly, consuming battery even when no events occurred. Event-driven architecture preserved battery life while maintaining real-time responsiveness.

Self-Hosted MQTT Broker: Running Mosquitto on owned infrastructure gave full control over message routing, data retention, and device management. Vendor cloud platforms would have limited control over alert logic, introduced third-party dependencies, and increased operational costs at scale.

Multi-Channel Alert Support: Different users have different notification preferences. Some need immediate phone alerts for critical access points. Others prefer silent email logs for non-urgent monitoring. Supporting SMS, call, email, and combinations meant the platform adapted to user behavior rather than forcing users to adapt to platform limitations.

HTTP API Configuration: Remote device configuration via HTTP API eliminated need for physical access to deployed sensors. Settings changes, troubleshooting, and updates could be performed from backend without dispatching technicians to client locations.

Battery Economics Determine IoT Viability: Deep sleep mode isn't optional—it's the difference between a deployable product and an operational tax. Multi-year battery life eliminates maintenance overhead that destroys unit economics at scale.

Event-Driven Architectures Outperform Polling: MQTT's publish-subscribe model delivered sub-second alerts with multi-year battery life. Protocol-level optimization matters when building for real-time response with power constraints.

Vendor-Agnostic Infrastructure Reduces Risk: Self-hosted MQTT and HTTP API control mean no dependency on third-party cloud platforms that can change terms, raise prices, or shut down. Operational ownership matters.

Multi-Channel Alerts Increase Engagement: Users who configured their own notification preferences—SMS, call, email, or combinations—showed higher response rates than single-channel systems. Platforms should adapt to user behavior, not force behavior change.

Remote Management Eliminates Site Visits: HTTP API configuration capability allowed team to troubleshoot, update, and manage hundreds of devices from dashboard. 80% reduction in operational overhead came from eliminating physical access requirements.