How much does it cost to develop an autonomous battery-operated asset monitoring device?
Project Context & System Requirements
The client approached us with a specific operational challenge: they were managing critical assets spread across remote locations using manual checks and a legacy system. It was inefficient, error-prone, and costing more than it should — both in downtime and maintenance. On top of that, they were pushing raw telemetry to the cloud with no filtering. Comms costs were piling up, and the whole thing didn’t scale well.
The ask was clear:
Build a autonomous asset monitoring device that could run on battery for years, handle its own basic logic locally, and only send relevant events to the backend.
Current Key Pain Points Identified
To solve these issues, the project needed reliable, low-power hardware built specifically for asset monitoring.
Hardware Stack
Firmware Stack
Solution Overview
The device is a compact, autonomous unit for long-term remote monitoring with minimal maintenance. It processes and filters data locally, sending only essential updates to the cloud to reduce communication costs and data volume. Using low-power wireless connectivity for status reporting and updates, its hardware and firmware can be adapted to different asset types and installation environments, enabling effective monitoring and maintenance of distributed equipment across multiple locations.
Architecture Overview
Sensors – Accurate temperature and humidity sensors integrated via UART, I2C, or RS485. Sensor selection is optimized for reliability, cost, and low power consumption.
Control – Handles sensor polling, basic signal filtering, and time-based triggers. Designed with predictable power profiles and a deterministic event model.
MCU + LTE Modem – Ultra-low-power MCU with LTE modem (e.g., nRF, ESP32, or STM32) selected based on regional network compatibility and certification readiness. Runs WizzDev’s modular firmware stack with MQTT communication, OTA update support, and robust error recovery mechanisms.
Custom Logic Module (e.g., Occupancy Engine) – Represents domain-specific logic (e.g., rule evaluation, ML model inference, event handling). Built to be modular and replaceable depending on use case. Compatible with popular embedded frameworks and MCU families (e.g., nRF, ESP32, STM32), ensuring efficient implementation of logic engines.
Device Provisioning – Secure and scalable provisioning pipeline. Supports credential injection, device grouping, and seamless onboarding — integrated with Cloud IoT Core or client-specified platform.
Web API – Exposes REST endpoints for frontend apps, third-party services, or automation scripts. Designed for long-term maintainability with clear API versioning and documentation.
Web Services – Application logic layer for data processing, command handling, and OTA coordination. Deployed using containerized infrastructure or serverless (e.g., AWS Lambda) depending on project size and SLA.
Data Storage – Time-series and metadata storage optimized for retrieval, aggregation, and dashboard rendering. Architecture is cloud-agnostic but cloud-native by default.
Database – Stores device registry, configuration data, user accounts, and permissions. Supports integrations with analytics or alerting tools.
Mobile App – Internal App dashboard for managing devices, monitoring sensor status, and running diagnostics. Secure access with role-based permissions.
WebApp – Client-facing interface for data visualization. Built for responsiveness and extensibility, with support for real-time updates and historical views.
User – Interacts with the system via browser-based apps over REST API.
Project Duration Estimate
| Stage | Description | Min h | Max h |
|---|---|---|---|
|
Project setup and initial analysis |
Requirements gathering and scope definition. |
8 |
12 |
|
Schematics and PCB Design |
Schematics and board layout. |
72 |
114 |
|
Enclosure design |
Mechanical CAD and iterations. |
54 |
80 |
|
Firmware development |
Power mgmt, LTE, edge filtering, OTA support. |
108 |
172 |
|
Project Management |
Weekly coordination and updates. |
30 |
38 |
|
Testing |
Functional and edge-case validation. |
20 |
24 |
|
Summary time for project: |
|
292 |
440 |
Risk Assessment
| Risk | Description | Min h | Max h |
|---|---|---|---|
|
Component Availability |
Component Availability
Long lead times or shortages
|
0 |
42 |
|
Firmware Optimization |
Edge tuning, power mode bugs |
0 |
63 |
|
Design Iterations |
PCB or enclosure adjustments post-testing |
0 |
56 |
|
Testing Delays |
Debugging unexpected failures |
0 |
30 |
|
Connectivity Issues |
Connectivity hiccups, especially in poor signal areas |
0 |
48 |
|
Regulatory Approvals |
Delays in CE/FCC/RoHS approvals |
0 |
32 |
|
Cloud Integration |
MQTT setup, token handling, retries |
0 |
35 |
|
Power Management Optimization |
Getting sleep modes and wake-ups right |
0 |
54 |
|
Total risk estimates: |
|
0 |
360 |
