IoT Product Development: From Low-Power Devices to the Cloud Platform, End to End

• Companies building a connected product from scratch: they have a product definition and need one team to build the device hardware, firmware, cloud and app together.

• Clients with a prototype that will not go to market: the demo works, but power, reliability and batch consistency stop it.

• Clients replacing an IoT supplier: the previous vendor only handled one end, and nobody can reconcile the tangle between device and cloud.

• Clients selling into western markets: the device needs FCC or CE certification, and remote management has to meet B2B customers' expectations.

An end-to-end solution means the whole chain from device to cloud: sensor and controller selection, device firmware, device connectivity and messaging, the cloud backend, and the mobile app and management interface. As an IoT product development company, XTELL delivers the development work along that chain; volume manufacturing is carried by the client's manufacturing partners, and we support the pilot run and fault isolation. The scope can also be narrowed - device and firmware only, or cloud and app only - with boundaries agreed per project in the contract.

The 433MHz security linkage system is the representative end-to-end delivery. An STC32G128K runs FreeRTOS to manage the 433MHz sub-GHz terminals, the TXW82x SDK drives the IPC/FPV camera, and an LCD/OLED shows local status. The Flutter app (iOS and Android) provisions devices by QR code, joins WiFi by scanning, plays RTSP/HLS video and receives alarm pushes. The NestJS, TypeORM and PostgreSQL backend manages authentication (JWT), devices and alarm state, with EMQX as the MQTT broker, ZLMediaKit for stream relay, Redis caching and Docker Compose orchestration. The challenge - keeping terminals, cameras and the app in sync through one backend, with video and alarms arriving reliably - was solved with the whole chain built in-house.

The challenge on the Apollo2 low-power IoT terminal was ultra-low-power deep sleep on the Apollo2 while keeping GPRS/GPS communication. The approach: deep sleep in the Apollo2's low-power modes, RTC timed wake-up, and GPRS and GPS started on demand - powered only when positioning or reporting is needed, with the radio fully off the rest of the time; Flash and a watchdog keep the system reliable, and the ADC collects sensor data. Development used the Keil, IAR and GCC toolchains. Battery life on a low-power terminal does not come from picking a low-power chip; it is calculated from the sleep strategy, wake cadence and radio duty cycle together.

The gas monitoring IoT system uses an ESP8266 (Espressif, the same family as the ESP32) as main controller: EEPROM for storage, an analog switch chip for multi-channel sensor switching, current sensing to monitor the battery, an LCD for local status, and a Node.js backend receiving data with configuration managed through config.yml. The challenge was doing multi-sensor acquisition and reliable battery power management together on the ESP8266. Small scale, battery powered, multi-channel acquisition - this kind of ESP8266/ESP32 IoT development is the most common entry-level need, and however small, it is delivered as a complete engineering project.

An IoT device's battery life is set by a weighted mix of three power figures: deep sleep current, active current on wake, and the share of time spent transmitting. The Apollo2 terminal turns the radio fully off, wakes on an RTC timer and starts GPRS/GPS on demand, pushing power during idle time to a minimum. Battery-powered devices such as the gas monitoring system also add current sensing to track battery state in real time. We calculate theoretical battery life from the product's duty cycle and then correct it with measurement - datasheet typical values and measured values with real sensors attached often differ widely, and only measured figures can serve as acceptance criteria.

The link is chosen by the application. The 433MHz security linkage system uses sub-GHz radio between terminals and the gateway side, cameras stream over RTSP/HLS, and messages all enter the backend through EMQX (the MQTT broker). The Apollo2 terminal reports over GPRS on demand, with GPS for positioning. The gas monitoring system connects directly from the ESP8266 to the backend. What they share: the code at every end of the link is with one team, so message formats, retry strategy and offline behaviour are defined together at the design stage, and there is no mismatch where the backend receives only part of what the device sends, or expects something the device never sends.

The core of an IoT product's software side is the platform: device onboarding and authentication, online status, alarm and event streams, and remote monitoring and operation. The backend of the 433MHz security linkage system is a complete example - EMQX carries device messages, PostgreSQL records device and alarm state, Redis caches hot data, JWT manages authentication, and administration happens through a web interface. As the device count grows, this structure decides whether alarms arrive and whether state is accurate - platform reliability is where an IoT product's reputation is made.

The everyday experience of an IoT product happens on the phone. The Flutter app of the 433MHz security linkage system covers the whole usage loop: QR code provisioning to bind devices, WiFi scanning to join the network, real-time RTSP/HLS video through VLC, and alarm push. This is where delivering device, backend and app from one team matters most visibly: whether a provisioning failure is a device problem or an app problem, we never have to ask a second company.

One team writes the firmware, the app and the backend. When a device misbehaves, a software-only supplier can only relay the symptom - the device didn't report; XTELL opens the firmware and sees what the device actually sent and whether the server received it. IoT faults often span device and cloud, and whether diagnosis can cross layers directly determines how fast problems are fixed after launch - the main reason clients choose us for complete solutions.

Connected devices cannot avoid RF certification. Clients' products routinely need FCC, CE or similar certification, and XTELL supports the related work: RF parameters and operating modes are configurable and reproducible at the firmware level, and we prepare the test builds and documentation the lab requires. Certificates are issued by accredited test labs; we make sure the device behaves consistently on the test bench.

1. Requirements review: share the product definition, target market and operating environment, and we confirm the technical route and the power and communication constraints.

2. Proposal and contract: architecture, milestones and delivery scope are written down. Whether source code and design files are delivered, and under an open or closed model, is agreed item by item. Nothing on this page constitutes a blanket commitment.

3. Development and integration: device, cloud and app progress in parallel and integrate against commonly defined messages and interfaces.

4. Delivery: scope follows the contract. Timeline and price are given after assessment; this page does not fix numbers.

XTELL (Shenzhen XTELL Future Technology) was founded in Shenzhen in 2016. Over the ten years since, it has delivered more than 100 projects, with clients predominantly western B2B companies. Its work covers every layer from circuit board to cloud: PCB design, FPGA, embedded firmware, Linux BSP, device interfaces, mobile apps, backends and IoT platforms.