Forem: ZedIoT

Tuya OEM App vs Tuya SDK: When Should You Switch?

ZedIoT — Thu, 12 Mar 2026 18:26:00 +0000

Many IoT device companies start with Tuya OEM apps when launching their first smart products.

OEM apps allow manufacturers to quickly deploy a branded application without building a mobile app from scratch. For early-stage products, this approach works very well.

However, as the device ecosystem grows, companies often face limitations that make OEM apps less suitable.

In this article, we share a real commercial HVAC project where a company migrated from a Tuya OEM app to a fully customized application built with the Tuya App SDK.

Why Companies Start with Tuya OEM Apps

Tuya OEM apps are popular for a reason.

They allow device manufacturers to:

Launch smart devices quickly
Avoid mobile development complexity
Use Tuya’s built-in device management features

For many companies entering the smart device market, this approach significantly reduces development time.

But over time, new requirements appear.

When OEM Apps Start Becoming Limiting

In our HVAC project, the client initially used a Tuya OEM app to launch their connected HVAC products.

As their product line expanded, several challenges emerged.

1. Limited Branding Flexibility

OEM apps offer basic branding, but deeper customization can be difficult.

The client wanted a stronger brand identity and a more customized user experience.

2. Advanced Device Control Requirements

Commercial HVAC systems often require more advanced device configuration and monitoring.

The OEM app could not fully support the device control logic the client wanted.

3. Future Product Expansion

The company planned to release additional smart HVAC devices.

They needed an architecture that could scale with their product ecosystem.

The Migration Approach

To address these challenges, the client decided to migrate from the OEM app to a custom mobile application built with the Tuya SDK.

Our development team focused on three areas.

Custom Mobile Application

A new mobile application was developed using the Tuya App SDK, allowing full customization of:

UI and UX design
Brand identity
Device interaction logic

Advanced Device Management

The custom application enabled:

Real-time device monitoring
More flexible device control
Better support for commercial HVAC scenarios

Scalable IoT Architecture

The system architecture was designed to support future smart device expansion.

As new HVAC products are introduced, the platform can easily integrate additional devices.

Results

After migrating from the OEM app to the SDK-based solution, the company achieved:

A fully branded mobile application
Greater flexibility in device feature development
A scalable platform for future IoT devices

This transition allowed the company to move from a quick-launch solution to a long-term smart device platform.

Final Thoughts

Tuya OEM apps are a great starting point for launching smart devices quickly.

However, as device ecosystems grow, companies often need more flexibility and control.

Migrating to a custom Tuya SDK solution can provide the foundation for long-term product development.

If you’re interested in the full project details, you can read the original case study here:

https://zediot.com/case/tuya-oem-to-sdk-migration-commercial-hvac/

ESP32 Series Comparison: ESP32 vs C3 vs S2 vs S3

ZedIoT — Wed, 11 Mar 2026 09:45:16 +0000

ESP32 is often treated as the default answer for embedded and IoT projects.
But “ESP32” alone is not a specification — it’s a family name.

Each ESP32 variant is optimized for a different goal, and using the wrong one usually doesn’t fail immediately. It fails later — when requirements grow.

Common ESP32 selection mistakes

In real projects, I often see:

Using high-end chips for simple sensor nodes
Ignoring security features until compliance becomes mandatory
Assuming all ESP32 chips handle AI workloads the same way

Most of these issues come from treating ESP32 as a single option instead of a range.

How the ESP32 series really differs

This comparison focuses on the practical differences between:

ESP32
Dual-core Xtensa MCU, flexible and mature, still widely deployed

ESP32-C3
RISC-V architecture, lower cost, better suited for secure and cost-sensitive devices

ESP32-S2
Single-core with native USB, useful for USB-based products and peripherals

ESP32-S3
Vector instructions and improved support for edge AI and vision-related workloads

Instead of going deep into datasheet-level details, the comparison looks at:

Architecture trade-offs
Memory and peripheral constraints
Realistic AI and OTA expectations
Product scenarios where each chip fits best

Why this matters for engineers

Chip selection affects:

Firmware complexity
Power consumption
BOM cost
Long-term maintainability

Once hardware is locked, software flexibility is limited. Making a clearer decision early often saves more time than any later optimization.

**👉 Full breakdown and comparison:
**https://zediot.com/blog/esp32-chip-series-comparison/

Using AI to Understand Employee Behavior in Retail Environments

ZedIoT — Fri, 09 Jan 2026 09:30:19 +0000

Retail operations rely heavily on frontline staff, yet managing service quality at scale remains a persistent challenge. Even with advanced systems in place, many stores still depend on manual supervision and subjective performance reviews.

As store networks grow, these traditional approaches struggle to provide consistent visibility into daily operations. Managers can’t be everywhere at once, and important behavioral signals are often missed during busy periods.

AI-based behavior analysis introduces a different way of thinking about staff management — one focused on patterns rather than individual monitoring.

From Observation to Insight

Modern retail AI systems use computer vision and real-time analytics to recognize operational behaviors such as task completion, service timing, and workflow adherence. Instead of isolated incidents, managers gain aggregated insights across shifts, locations, and timeframes.

These insights help answer practical questions:

Where do service delays most often occur?
Are operational procedures followed consistently?
Which stores benefit most from additional training or process adjustments?

Operational Benefits

When implemented responsibly, AI-driven behavior insights can support:

More objective performance evaluation
Early detection of operational risks
Measurable training effectiveness
Consistent service standards across stores

Rather than replacing human judgment, AI acts as a supporting layer — providing data that helps teams focus on improvement instead of guesswork.

Responsible Use Matters

Employee-facing analytics must be deployed with care. Clear guidelines, transparency, and privacy-aware system design are essential to ensure trust and long-term adoption.

For a detailed, real-world explanation of how this approach is used in retail environments, refer to the full article here:

👉 https://zediot.com/blog/retail-employee-tracking-ai/

Designing an AI Foot Traffic Analysis System for Retail

ZedIoT — Wed, 31 Dec 2025 02:10:00 +0000

TL;DR

AI foot traffic analysis goes beyond people counting.

This article breaks down the system architecture, data flow, and deployment considerations behind modern retail traffic analytics.

Why Foot Traffic Analytics Needs AI

Traditional foot traffic systems focus on entry and exit counts.

While useful, they fail to explain how customers actually move and behave inside a store.

AI-driven foot traffic analysis addresses this gap by turning raw video and sensor data into behavioral signals that support operational decisions—such as layout optimization, staffing, and conversion analysis.

From a system design perspective, the key challenge is not detection accuracy alone, but building a pipeline that connects perception, analytics, and business context.

Core System Components

A typical AI foot traffic analysis system consists of several layers working together.

1. Data Collection Layer

Retail environments rely on multiple signal sources, including:

In-store cameras (ceiling-mounted or zone-specific)
IoT sensors for entrances and high-traffic areas
POS or transaction context for behavioral correlation

These data sources provide the raw inputs required for traffic and movement analysis.

2. AI Detection and Tracking

Computer vision models process video streams to:

Detect visitors
Track movement paths across zones
Measure dwell time
Avoid duplicate counts in crowded scenarios

Multi-object tracking is crucial for maintaining consistent identity signals without storing personal data.

3. Behavior and Traffic Analytics

Once detection and tracking are complete, the system generates higher-level insights:

Heatmaps for engagement intensity
Flow paths between store zones
High-traffic, low-conversion areas
Dwell-time distributions by zone

This layer transforms raw perception data into interpretable metrics.

Deployment Considerations: Edge vs Cloud

From an engineering standpoint, deployment architecture plays a major role.

Edge processing reduces latency and improves privacy by keeping video on-site.
Cloud processing supports centralized analytics and cross-store benchmarking.
Hybrid models balance scalability with compliance requirements.

System designers must account for bandwidth, compute constraints, and privacy regulations when selecting deployment strategies.

Turning Analytics into Operational Signals

Analytics alone do not create value unless they are operationalized.

Well-designed systems expose insights through:

Real-time dashboards
Alerts for congestion or staffing gaps
Historical comparisons across stores and time periods

These outputs allow retail teams to link traffic behavior directly to operational decisions.

Why Architecture Matters More Than Accuracy

In practice, most modern computer vision models achieve acceptable detection accuracy.

The real differentiator lies in system architecture:

How data flows across layers
How insights are integrated into operations
How scalable and maintainable the system is over time

AI foot traffic analysis succeeds when it is designed as part of a broader retail analytics ecosystem, not as a standalone tool.

Final Thoughts

AI-driven foot traffic analysis is fundamentally a systems problem.

For retail teams and engineers alike, understanding the architecture behind these solutions is critical to building scalable, privacy-aware, and decision-ready analytics platforms.

Original Source

Originally published at:

https://zediot.com/blog/ai-foot-traffic-analysis/

How to Use Node-RED as a Modbus TCP Server (Without Writing Custom Code)

ZedIoT — Thu, 25 Dec 2025 08:06:48 +0000

If you’ve worked with industrial systems, you’ve almost certainly encountered Modbus TCP.

It’s reliable, widely supported, and still heavily used across PLCs, meters, and industrial controllers. At the same time, building or simulating a Modbus server often feels more complex than it should—especially when the goal is integration testing or edge gateway development.

Many teams default to writing custom Modbus servers just to expose registers or simulate devices. In practice, this approach often slows projects down.

Node-RED as a Modbus Server

Node-RED is usually associated with low-code automation, but in industrial IoT projects, it can serve as a powerful middleware layer.

With the right setup, Node-RED can:

Run as a Modbus TCP server
Expose virtual Modbus registers
Simulate industrial devices before hardware is available
Bridge Modbus data into MQTT, HTTP, or cloud platforms

This makes it especially useful for edge gateways, industrial protocol bridging, and early-stage integration testing.

Typical Use Cases

This approach is commonly used in scenarios such as:

Factory or system integration testing
Industrial IoT gateways aggregating Modbus data
Proof-of-concept environments for SCADA or MES systems
Legacy device integration with modern IoT platforms

Instead of building everything from scratch, Node-RED allows teams to validate communication flows early and iterate faster.

Looking for the Actual Configuration Steps?

This post intentionally avoids pasting full configurations or screenshots. In real Modbus projects, small details—such as address offsets, register types, and connection modes—often make or break a setup.

The complete tutorial walks through:

Running Node-RED in Modbus TCP server mode
Defining and updating holding and input registers correctly
Testing communication with real Modbus client tools
Debugging common connection and data consistency issues

👉 Full step-by-step walkthrough (with screenshots):

https://zediot.com/blog/node-red-modbus-server-guide/

If you’re building or testing industrial IoT gateways, this guide can save you a lot of trial and error.

About ZedIoT

ZedIoT builds and integrates industrial IoT and edge solutions, with a focus on Node-RED workflows, Modbus-based systems, and device-to-cloud integration.

We work with teams that need reliable bridges between legacy industrial protocols and modern IoT platforms.

Building AI-Enhanced Tuya IoT Products: Architecture, Patterns & Real Use Cases

ZedIoT — Fri, 05 Dec 2025 06:08:10 +0000

Tuya is one of the fastest ways to launch IoT hardware — but the next stage of the ecosystem is evolving fast.

With AI becoming increasingly accessible, more developers are looking to layer automation, prediction, and context-aware logic on top of existing Tuya devices.

In this post I’ll walk through how you can integrate:

Tuya Cloud API
Tuya App SDK
AI workflow engines or decision logic
Device data (sensors, user events, usage stats)

…into a scalable system that delivers smart, context-aware behaviors without rewriting device firmware or changing hardware.

Full deep-dive (with diagrams & real project examples) here:

➡️ https://zediot.com/blog/tuya-ai-integration/

Why AI Makes Sense When You Use Tuya

Tuya handles the heavy lifting for IoT: device enrollment, connectivity, consistent DP data reporting, and stable control channels.
What it doesn’t provide is higher-level reasoning — context awareness, cross-device logic, or predictive behaviors. That’s where AI adds real value.

Especially in modern deployments with multiple sensors, complex device interactions, or fluctuating environmental variables, static rules quickly become insufficient. AI brings the flexibility to make sense of messy data and make intelligent decisions.

Common Integration Patterns: Tuya + AI Without Firmware Changes

Here are some patterns developers use to integrate AI + Tuya in real projects.

Pattern A — Server-Side AI with Tuya Cloud API

Device → Tuya Cloud → Webhook → AI Service → Tuya Cloud API → Device

Works for automation, energy optimization, and multi-sensor logic
Easiest to scale and maintain

Pattern B — App-Side AI with Tuya App SDK

App SDK → AI Model → App SDK → Device Control

Useful when you need UI interaction, user-driven logic, or adaptive UI/UX
Good for smart dashboards, explanations, or natural-language control interfaces

Pattern C — Workflow Orchestration (no custom server)

Use a visual automation tool or workflow engine to link Tuya events → AI logic → actions
Great for prototypes, quick MVPs, or when you don’t want to build full backend

Because none of these require modifying device firmware, you keep full compatibility with existing Tuya hardware.

✅ Real Use Cases That Show Tangible Benefits

These are scenarios where “smart + connected” becomes genuinely useful — not just gimmicks.

Energy management & optimization — AI analyzes usage patterns, load cycles, occupancy / environmental data, then triggers devices intelligently or suggests savings.
Smart HVAC / environmental control — Combine data from sensors (temp, humidity, CO₂, light, occupancy) → AI decides optimal environment settings, more adaptive than static timers or thresholds.
Multi-sensor context awareness — Instead of triggering on a single sensor event, AI reasons over multiple inputs (motion, light, time, occupancy) to make smarter decisions and reduce false positives.
Predictive maintenance (industrial or appliance usage) — Historical data — runtime, cycles, temperature fluctuations — used to detect abnormal patterns, warn potential issues ahead of failure.
Better user experience & insights — AI can translate raw data into human-readable summaries: e.g. “Your system has used 30% more energy than usual today — consider lowering the thermostat,” or send meaningful alerts.

These examples illustrate that AI + Tuya is not just a fancy idea — it’s a practical enhancement path for real-world IoT products.

What This Means for Developers & Product Teams

You can add “intelligence” to existing Tuya-based devices without changing any hardware or firmware.
AI + cloud-side architecture allows rapid iteration, easier updates, and better maintenance compared to embedded firmware logic.
For teams without deep embedded or hardware experience, this approach significantly lowers the barrier to building “smart” functionality.
Using AI and workflows as a differentiation helps you stand out in a crowded IoT market, where many products remain just “connected.”

👉 Next Steps (If You're Curious to Try)

Read the full guide (with architecture diagrams, patterns, and real-world examples): https://zediot.com/blog/tuya-ai-integration/
If you have Tuya-based devices (or plan to), consider whether adding AI-driven workflows could improve their value — for automation, user experience, energy saving, or maintenance.
Experiment with a prototype: wire up a few sensors → Tuya Cloud API → simple AI logic → device control — see how it behaves.

If you want feedback on feasibility or a second opinion on architecture, feel free to reach out here：https://zediot.com/contact/. We're happy to help brainstorm or review your setup.

Building Tuya IoT Workflows With n8n (Cloud API + Automation Guide)

ZedIoT — Wed, 03 Dec 2025 07:20:53 +0000

This post walks through a clean and practical way to connect Tuya smart devices with n8n workflows, allowing you to automate device commands, process sensor data, and integrate external APIs.

Architecture

Tuya Cloud → n8n Webhook / HTTP Node
n8n Logic → Branching → AI → External API
n8n → Tuya Command API → Device Action

This pattern allows n8n to act as a lightweight IoT orchestration engine.

Why Use n8n For Tuya Integrations?

Works with any Tuya device
Supports OEM App, Cloud API, Link SDK
Enables cross-system automations
Easy to incorporate AI models
No need to build an IoT backend

Example: Energy Monitoring Workflow

1. Fetch device energy data from Tuya API  
2. Check thresholds in n8n  
3. If abnormal → trigger alert  
4. If action required → send command back to Tuya device  
5. Store logs in DB

Flexible, repeatable, and ideal for multi-device environments.

Typical Use Cases

Smart energy dashboards
Cold-chain temperature alerts
Lighting & occupancy automations
Smart home → AI notifications
Retail IoT workflows

Extending the Integration

If you work with:

Tuya Link SDK
Custom sensors
Edge gateways
Multi-site automation
Enterprise-level workflows

You’ll likely need custom development for device-level data parsing, security, and cloud synchronization.

Want the Full Guide?

The full breakdown (screenshots, flow examples, API notes) is here:

👉 https://zediot.com/blog/n8n-tuya-integration/

If you're building a Tuya + n8n automation system and need help with SDK development or device integration, feel free to reach out:

👉 https://zediot.com/contact/

Building a Lightweight, Multi-Store Restaurant Management System for a QSR Brand

ZedIoT — Fri, 28 Nov 2025 06:48:35 +0000

This case breaks down how we designed and implemented a cross-platform restaurant management system that works reliably across multiple branches — even with inconsistent network conditions and mixed hardware environments.

Core requirements

Real-time sales and inventory sync
Offline-first operation for unstable WiFi
Role-based access control
Multi-store data aggregation
Cross-platform UI (desktop + tablet)
Fast response time under peak load

System architecture

We used a modular, API-driven design:

[Frontends]
- Tablet Dashboard (Vue)
- Desktop Admin Panel (Web)

[APIs]
- RESTful service layer
- WebSocket for real-time sync

[Core Services]
- Stock management
- Sales records
- Employee roles & permissions
- Multi-store aggregation

[Data Layer]
- Cloud DB (Primary)
- Local SQLite fallback (Offline mode)

The offline-first approach ensures all store operations keep running even when the network drops.
Once reconnected, local records auto-sync to the cloud.

Device compatibility

Branch hardware varied widely:
old Windows PCs, Android tablets, and low-spec terminals.

To handle this:

The UI was optimized for low-memory devices
API responses were lightweight
Sync operations were incremental, not full-dataset

Performance results

After deployment, the system improved:

Stock update accuracy
Data sync stability
Operational efficiency during peak hours
Manager visibility across all stores

Reusable components

This architecture is well-suited for:

Multi-store retail management
POS extensions
Kitchen automation dashboards
IoT-connected restaurant systems (smart freezers, energy sensors, etc.)

✅ Read the full engineering write-up

👉 https://zediot.com/case/restaurant-management-software-qsr/

✅ Need custom restaurant or retail software?

We build production-grade systems for QSR, retail, kitchen automation, and AI/IoT-enabled operations.
👉 https://zediot.com/contact/

ESP32-S3 + TensorFlow Lite Micro: A Practical Guide to Local Wake Word & Edge AI Inference

ZedIoT — Tue, 25 Nov 2025 05:56:28 +0000

This post breaks down how we deploy TensorFlow Lite Micro (TFLM) on ESP32-S3 to run real-time wake word detection and other edge-AI workloads.
If you're exploring embedded ML on MCUs, this is a practical reference.

Why ESP32-S3 for embedded inference?

ESP32-S3 brings a useful combination of:

Xtensa LX7 dual-core @ 240 MHz
Vector acceleration for DSP/NN ops
512 KB SRAM + PSRAM options
I2S, SPI, ADC, UART
Wi-Fi + BLE

It’s powerful enough to run quantized CNNs for audio, IMU, and multimodal workloads while staying power-efficient.

Pipeline: From microphone to inference

1. Audio front-end

I2S MEMS microphones (INMP441 / SPH0645 / MSM261S4030)
16 kHz / 16-bit / mono
40 ms frames (~640 samples)

Preprocessing steps:

High-pass filter
Pre-emphasis
Windowing (Hamming)
VAD (optional)

ESP-DSP supports optimized FFT, DCT, and filtering primitives.

2. Feature extraction (MFCC)
MFCC remains the standard for low-power speech workloads:

FFT
Mel filter banks
Log scaling
DCT → 10–13 coefficients

On ESP32-S3, MFCC extraction typically takes 2–3 ms per frame.

3. Compact CNN model

Typical architecture for wake-word detection:
| Layer           | Output Example |
| --------------- | -------------- |
| Conv2D + ReLU   | 20×10×16       |
| DepthwiseConv2D | 10×5×32        |
| Flatten         | 1600           |
| Dense + Softmax | 2 classes      |

Model size after int8 quantization: 100–300 KB.
Convert & quantize:

converter = tf.lite.TFLiteConverter.from_saved_model("model_path")
converter.optimizations = [tf.lite.Optimize.DEFAULT]
converter.target_spec.supported_types = [tf.int8]
tflite_quant_model = converter.convert()

4. Deployment to MCU
Convert .tflite → C array:

xxd -i model.tflite > model_data.cc

Load + run with TensorFlow Lite Micro:

const tflite::Model* model = tflite::GetModel(model_data);
static tflite::MicroInterpreter interpreter(...);
interpreter.AllocateTensors();

while (true) {
    GetAudioFeature(input->data.int8);
    interpreter.Invoke();
    if (output->data.uint8[0] > 200) {
        printf("Wake word detected!\n");
    }
}

Performance on ESP32-S3:

| Metric            | Value    |
| ----------------- | -------- |
| Inference latency | 50–60 ms |
| FPS               | 15–20    |
| Model size        | ~240 KB  |
| RAM usage         | ~350 KB  |

Beyond wake words: What else runs well on TFLM?

Because the workflow is generalizable, simply swapping the model unlocks new tasks:

Environmental sound classification
Glass break, alarm, pet sound detection
(8–12 FPS depending on model)

Vibration & anomaly detection
Predictive maintenance for pumps, motors, or fans.

IMU-based gesture recognition
Hand-wave, wrist-raise, walking/running classification.

Multimodal environmental semantics
Fuse sound + IMU + temperature/light for context-aware devices.

OTA updates = evolving intelligence

A major advantage of MCU-based AI:

Cloud trains models
Device runs inference locally
OTA delivers updated .tflite models

This keeps devices adaptable across noise changes, accents, or new product features.

Use cases we see in real deployments

Offline voice interfaces
Industrial sound/vibration monitoring
Wearable gesture recognition
Smart home acoustics
Retail terminals with local AI

ESP32-S3 provides a good balance of cost, flexibility, and inference performance.

Full article with diagrams / extended explanation

This Dev.to post is the short version.
Full technical deep-dive is here:
👉 https://zediot.com/blog/esp32-s3-tensorflow-lite-micro/

Need help building an ESP32-S3 or embedded AI system?

We design:

Wake-word engines
TensorFlow Lite Micro model deployment
Embedded AI prototypes
IoT + Edge AI solutions

Contact: https://zediot.com/contact/

A Technical Overview of Tuya Smart Mini-Apps (Panel vs. Smart Mini-App)

ZedIoT — Thu, 20 Nov 2025 07:27:07 +0000

We recently published a full breakdown of Tuya Smart Mini-Apps on our website, and here’s the condensed, developer-focused version for Dev.to readers who want the essentials without the marketing layer.

If you’re building for Tuya, OEM apps, or Tuya’s App SDK, Mini-Apps are quickly becoming the standard way to deliver UI and multi-device services.

1. Mini-App Types: Panel vs. Smart

Panel Mini-App (Device-Bound)

Attached to a PID
Controls a single device
Replaces the previous built-in Tuya panels
Ideal for manufacturers shipping hardware

Smart Mini-App (Scenario-Centric)

Not tied to any single device
Can query multiple devices through Tuya Cloud
Great for dashboards, analytics, scenes, cross-device logic

Summary:

| Feature   | Panel Mini-App | Smart Mini-App                      |
| --------- | -------------- | ----------------------------------- |
| Binding   | Single device  | None                                |
| Use Case  | Control UI     | Multi-device services               |
| API level | DP points      | Cloud APIs + user/device list       |
| Developer | Manufacturers  | OEM, integrators, service providers |

2. Architecture Overview

A Mini-App is essentially:

HTML / JS / CSS (frontend)
↓
Tuya Mini-App Runtime (webview container)
↓
Tuya JS SDK (device, cloud, BLE, scene, user)
↓
Tuya Cloud (auth, device data, scenes)

This abstraction enables much faster development and iteration compared to native mobile development.

3. Development Tools

Official IDE

Real-time preview
Built-in device simulator
Upload & version management

Mini-App CLI

npm install -g @tuya/miniapp-cli
tuya-miniapp init myApp
npm run dev

Project structure resembles WeChat Mini Programs, but tuned for IoT:

/project
  app.json
  app.js
  pages/
  utils/
  assets/

4. What You Can Build

Mini-Apps support:

multi-device dashboards
environment monitoring (CO₂, temp, humidity)
energy/water consumption analytics
BLE device onboarding
automation & scene control
OEM branding & custom UI

These functions run natively within Smart Life/OEM apps.

5. Integration Paths

1. Panel Mini-App only
Manufacturers replacing older device UIs

2. OEM App + both Mini-Apps

Most common model today
Combines device control + service modules

3. Full SDK App + Mini-Apps

Custom IoT app with complete UI freedom
Still uses Tuya’s JS SDK for device/cloud access

6. Deployment Workflow

Build tuya-miniapp build
Upload to Tuya IoT Platform
Fill metadata & permissions
Await review
Publish to Smart Life / OEM / SDK App
Users access Mini-App through in-app runtime

7. When You Should Use Mini-Apps

Use Mini-Apps when:

You need rapid iteration
You don’t want to maintain native app code
You need multi-device dashboards
You offer services beyond single-device UI
You want to ship analytics modules inside OEM apps

Mini-Apps are not ideal if:

You require heavy native functionality
You need very low-level mobile hardware access
You’re building an app unrelated to IoT

Conclusion

Tuya Smart Mini-Apps give developers a fast, extensible, and cloud-driven way to build IoT experiences across devices and apps. They sit in the perfect middle ground:

faster than native
more flexible than fixed device panels
secure & cloud-backed
easy to scale into OEM or SDK apps

If you’re building IoT applications in the Tuya ecosystem, Mini-Apps are now one of the strongest tools available.

📘 Full Article (Full-Length Version)
https://zediot.com/blog/tuya-smart-mini-apps-guide/

We also work on Tuya SDK, OEM App, and Smart Mini-App development.
If you’re exploring these architectures, feel free to connect here: https://zediot.com/contact/

Deploying YOLOv8 on RK3566 Using RKNN Toolkit: Notes, Pitfalls, and Benchmarks

ZedIoT — Tue, 18 Nov 2025 06:39:00 +0000

Running YOLOv8 on RK3566 is a practical choice for edge AI devices where cost, thermal stability, and NPU acceleration matter.

This post summarizes the key technical steps, conversion notes, and pitfalls we encountered while deploying YOLOv8 on an RK3566 board — without repeating the full tutorial.

(Full detailed tutorial is linked at the end.)

1. Model Preparation

YOLOv8 exports cleanly into ONNX, but RKNN Toolkit requires strict operator compatibility.

Recommended export:

yolo export model=yolov8n.pt format=onnx opset=12 dynamic=False

Why opset=12?
RKNN Toolkit (especially on RK3566) has the best stability with opset 11–13. Higher versions may break resize/activation layers.

2. Convert ONNX → RKNN

Using RKNN-Toolkit2:

from rknn.api import RKNN

rknn = RKNN()

rknn.config(
    mean_values=[[0, 0, 0]],
    std_values=[[255, 255, 255]],
    quantized_dtype='asymmetric_quantized-u8'
)

rknn.load_onnx('yolov8n.onnx')

rknn.build(
    do_quantization=True,
    dataset='./dataset.txt'
)

3. Inference on RK3566

Minimal runtime example:

import cv2
from rknn.api import RKNN

rknn = RKNN()
rknn.load_rknn('yolov8n.rknn')
rknn.init_runtime()

img = cv2.imread('test.jpg')
img_resized = cv2.resize(img, (640, 640))

outputs = rknn.inference(inputs=[img_resized])

Post-processing (NMS, decoding) runs on the ARM CPU.
Optimizing this step often gives the biggest FPS improvement.

4. Performance Notes (Real Tests)

Approximate results on RK3566 NPU:

| Model   | Precision | FPS       |
| ------- | --------- | --------- |
| YOLOv8n | INT8      | 16–22 FPS |
| YOLOv8n | FP32      | 4–6 FPS   |
| YOLOv8s | INT8      | 8–12 FPS  |

Quantization accuracy is highly dependent on dataset representativeness — especially for small-object detection.

5. Common Pitfalls

✔ 1. Quantization dataset too small
INT8 accuracy drops significantly without enough real-scene samples.

✔ 2. Resize mismatch
Letterboxing vs raw resize affects detection stability.

✔ 3. Preprocessing not aligned
Mismatch between training normalization and RKNN config = confidence drift.

✔ 4. CPU-side post-processing bottleneck
Consider:

vectorized NumPy
C++ post-processing
offloading compatible steps to RKNN ops

Full Tutorial With Code + Benchmarks

📌 Full step-by-step guide:
👉 https://zediot.com/blog/how-to-deploy-yolov8-on-rk3566/

Need Help?

Working on RK3566/RK3588 deployments or YOLO/TensorRT optimization on edge hardware?

We help teams with quantization, model conversion, NPU optimization, and embedded integration. If you're running into conversion errors or performance drops, feel free to reach out — happy to help. Contact us here: https://zediot.com/contact/

SmolRTSP: Open-Source Practices for Efficient RTSP Streaming in Embedded Systems

ZedIoT — Wed, 12 Nov 2025 06:12:04 +0000

A complete guide for technical developers: From RTSP protocol principles to SmolRTSP implementation in embedded systems

1. Introduction: Importance of RTSP Protocol in Embedded Systems

With the rapid growth of the Internet of Things (IoT) and the increasing prevalence of smart devices, real-time audio and video transmission has become increasingly vital in embedded systems. Whether for smart cameras, drones, or industrial monitoring equipment, efficient, low-latency streaming solutions are essential. Among various protocols, RTSP (Real-Time Streaming Protocol) is preferred due to its flexibility and broad support for implementing streaming in embedded systems.

2. Overview of RTSP Protocol

2.1 What is RTSP?

RTSP is an application-layer protocol designed to control streaming media servers. It allows clients to send commands like "play," "pause," and "stop" to control audio and video streams in real-time. Note that RTSP itself does not transport media data; it uses RTP (Real-time Transport Protocol) for data transmission and RTCP (Real-time Control Protocol) for control information.

2.2 How Does RTSP Work

RTSP uses a client-server model, and its communication typically involves the following steps:

OPTIONS: The client queries the server for supported commands.
DESCRIBE: The client requests media description information, usually returned in SDP (Session Description Protocol) format.
SETUP: The client requests to establish a transport channel for the media stream.
PLAY: The client requests to start streaming the media.
PAUSE: The client requests to pause the media stream.
TEARDOWN: The client requests to terminate the media stream.

These commands allow clients to flexibly control media playback, enabling functions like fast forward, pause, and stop.

2.3 How To Use RTSP Protocol in Browsers

Using the RTSP (Real-Time Streaming Protocol) in browsers can be challenging since most modern web browsers do not natively support RTSP streams. However, there are several methods you can use to enable RTSP streaming in a browser:

Use a Media Server: Convert RTSP streams to a format supported by browsers, such as HLS (HTTP Live Streaming) or WebRTC. Media servers like Wowza, Red5, or Ant Media Server can perform this conversion.
HTML5 Video Player with Plugins: Utilize HTML5 video players with specific plugins or extensions that support RTSP streams. Some players offer plugins that can handle RTSP or integrate with third-party services.
Browser Extensions: Some browser extensions or add-ons can enable RTSP streaming by acting as a bridge between the RTSP source and the browser.
Custom Web Applications: Develop custom web applications using libraries that support RTSP streaming. Libraries such as JSMpeg or video.js can be used in conjunction with a backend service to handle RTSP streams.
Use VLC Plugin: Although less common due to security and compatibility issues, using the VLC web plugin can allow RTSP playback in browsers that support it.

By implementing these methods, you can effectively stream RTSP content in a browser environment, providing users with seamless access to real-time video streams.

2.4 Challenges of RTSP in Embedded Systems

Implementing an RTSP server in embedded systems faces several challenges:

Resource Constraints: Embedded devices typically have limited processing power and memory, making it difficult to run resource-intensive RTSP servers.
High Real-Time Requirements: Audio and video streaming demands strict latency and synchronization.
Protocol Complexity: RTSP involves multiple commands and state management, making implementation complex.

Thus, a lightweight and easy-to-implement RTSP server solution is needed to meet the demands of embedded systems.

3. SmolRTSP: A Lightweight RTSP Server for Embedded Systems

SmolRTSP is a lightweight server library compliant with the RTSP 1.0 standard, designed specifically for embedded devices. It supports TCP and UDP transport, allows any data payload format, and provides a flexible API for developers to implement RTSP functionality in resource-constrained environments.

3.1 Features of SmolRTSP

Lightweight: The core library includes only necessary features, suitable for the resource limitations of embedded devices.
Easy Integration: Offers clear API interfaces for seamless integration with existing systems.
High Performance: Optimized data processing ensures low-latency media streaming.
Open Source: Licensed under MIT, encouraging community contributions and custom development.

3.2 Applications of SmolRTSP

SmolRTSP is suitable for various embedded system scenarios, including but not limited to:

Smart Cameras: Enable remote access and control of real-time video streams.
Drones: Transmit real-time aerial video streams.
Industrial Monitoring Equipment: Facilitate remote monitoring and control functions.
Home Automation Systems: Integrate video surveillance features.

4. SmolRTSP Architecture and Module Analysis

SmolRTSP is designed as a modular, low-resource, highly customizable RTSP service library. Its core follows principles of simplicity and practicality, suitable for running on bare-metal or embedded Linux systems.

Below is a typical architecture of SmolRTSP:

graph TD
    Client[RTSP Client] -->|TCP/UDP| SmolRTSP[SmolRTSP Server]
    SmolRTSP --> Parser[RTSP Parsing Module]
    SmolRTSP --> Dispatcher[Command Dispatch Module]
    SmolRTSP --> SessionManager[Session Manager]
    SmolRTSP --> RTPStack[RTP Sending Module]
    RTPStack --> EncodedStream[Encoded Video/Audio Stream]

4.1 Detailed Core Modules

✅ RTSP Parsing Module (Parser)

• Receives RTSP requests from clients (e.g., DESCRIBE, SETUP, PLAY)

• Parses RTSP messages using a state machine

• Supports standard RTSP 1.0 protocol format and extended SDP (Session Description Protocol)

✅ Command Dispatch Module (Dispatcher)

• Calls the corresponding handler functions based on different RTSP commands

• Supports custom handlers, such as hooks to the application layer for dynamic control of streaming/recording

✅ Session Manager (SessionManager)

• Tracks client states, including session_id, channel, port, etc., after SETUP

• Supports concurrent connections from multiple clients (relies on underlying task scheduler or select/poll)

✅ RTP Sending Module (RTPStack)

• Constructs RTP packets and pushes them to clients via UDP/TCP at fixed intervals

• Adapts to mainstream video encoding formats like H264/H265 (requires external encoder support)

5. Deploying SmolRTSP on Embedded Platforms

5.1 Compilation Dependencies and Resource Requirements

SmolRTSP is written in Rust, requiring the following toolchain support:

• Rust compiler (can use cross for cross-compilation)

• libc / musl toolchain (depending on the platform)

• Minimum memory usage: ≈ 100KB (depending on feature trimming)

📌 For mainstream embedded SoCs like STM32MP1, Allwinner V851, and RK3588S, SmolRTSP can run smoothly within 256MB of memory.

5.2 Typical Integration Methods

Integration Scenario	Description	Interface Method
🧠 Integration with Proprietary Video Encoder	Pass frame buffers, SmolRTSP handles RTP packaging and pushing	Provide raw frame interface (YUV/H264 buffer)
🎥 Integration with Camera Driver	Video capture thread pushes frames in real-time	Use mmap/V4L2 to capture frames and send to SmolRTSP
🎯 Collaboration with Media Server (e.g., FFmpeg)	Acts as upstream streaming server for FFmpeg/OBS to pull streams	Directly listen to socket, standard SDP description support
📡 Simultaneous WebRTC/RTMP Streaming	Parallel streaming with other protocols	Reuse the same video capture layer, register socket for pushing

5.3 Sample Integration Code (Embedded Pseudo Code)

fn start_streaming() {

    // Initialize the camera

    let video_capture = V4l2Capture::new("/dev/video0");

    // Start the SmolRTSP server

    let server = SmolRTSPServer::bind("0.0.0.0:8554");

    loop {

        // Read a frame

        let frame = video_capture.read_frame();

        // Encode as H264 (assuming software encoding)

        let encoded = h264_encode(frame);

        // Push to RTSP session

        server.broadcast_rtp(encoded);

    }

}

📌 Note: SmolRTSP itself does not include an H264 encoder; external libraries (e.g., x264, OpenH264, FFmpeg) are required for encoding.

5.4 Embedded Debugging Tips

Issue	Cause	Debugging Method
No data after client connection	broadcast_rtp not called correctly / session not established	Print SessionManager status, confirm if SETUP is complete
Playback black screen or stuttering	Timestamp errors / I-frame loss / encoder issues	Use Wireshark to capture packets + FFplay to compare latency
Compilation failure	Rust toolchain mismatch	Use ⁠rustup target add to install cross-compilation target

6. Comparison with Other RTSP Servers

When choosing an RTSP service framework for embedded systems, developers face several options, such as Live555, EasyRTSPServer, and FFserver. How does SmolRTSP compare in terms of advantages or limitations?

Project	SmolRTSP	Live555	EasyRTSPServer	FFserver
Language	Rust	C++	C++	C
Memory Usage	≈ 100–200KB	1MB+	5MB+	Discontinued
Embedded Suitability	✅ Excellent	Moderate (requires trimming)	Heavy	❌ Not recommended
Development Flexibility	✅ Fully customizable streams	❌ Heavy on general API	⚠️ Fixed stream structure	❌ Maintenance stopped
RTP Sending Performance	Moderate to high	Excellent	Excellent	Moderate
Encoder Dependency	None (requires external)	Built-in support for some	Built-in	Built-in
Multi-Protocol Support	RTSP only	Supports full RTCP/RTP link	Supports RTMP extension	Supports various (but not maintained)

📌 Conclusion: If you are working on embedded systems, are sensitive to resource usage, and want high customization, SmolRTSP is a great choice. However, if you need ready support for RTMP / HLS / HTTPS and other protocols, Live555 may be more suitable.

7. Performance Optimization Suggestions and Production Practices

7.1 SmolRTSP Performance Bottleneck Analysis

Bottleneck	Cause	Optimization Suggestions
RTP Latency Fluctuations	Unstable timer / network jitter	Use timer thread + high-priority socket
High Encoding Overhead	Inefficient software encoder	Use hardware H264 encoder (e.g., VENC)
Session Context Memory Usage	Accumulation with many clients	Limit maximum connections + timeout recovery
Frequent Context Switching	IO/encoding not decoupled	Use asynchronous + single-threaded data pipeline structure

7.2 Recommended Practice Scenarios

Application Scenario	Description	Recommended Configuration
🏠 Home Smart Cameras	Plug-in cameras/battery doorbells	Use V4L2 + YUV capture + SmolRTSP
🚁 Drone Video Transmission System	Real-time stream transmission	Integrate hardware encoding + custom SDP
🏭 Industrial Inspection Terminals	Multi-channel image upload	Multi-process collaborative streaming, each with an independent socket
🐕 Pet Feeder/Visual Door Lock	Embedded edge video	Single-threaded minimalist push architecture (frame rate ≤15)

7.3 Future Expansion Directions for SmolRTSP

• ✅ Support ONVIF / RTSP over TLS

• ✅ Simplify SDP generation, compatible with more clients (e.g., VLC, FFplay, Hikvision SDK)

• ✅ Implement Web embedded streaming with Rust + WASM

• ✅ Provide turn-key framework with hardware platforms (e.g., Raspberry Pi, ESP32-S3)

8. Developer Recommendations

"If you want to run an efficient, customizable RTSP server on embedded systems, rather than using traditional heavy server frameworks—SmolRTSP is worth trying."

Pros	Cons
✅ Minimal design, easy to embed	❌ No encoder, requires external H264 support
✅ Fully open-source, flexible interface	❌ Lacks UI management interface (requires command-line debugging)
✅ Low resource usage, suitable for edge devices	❌ Documentation is relatively brief, requires source code for understanding architecture

🧰 Engineering Recommendations:

• Use cross-compilation for Rust projects when integrating, recommended to use ⁠cross

• For encoding, consider using FFmpeg CLI or OpenH264 SDK

• For multi-streaming, implement asynchronous concurrency with ⁠tokio or ⁠async-std

📎 Project Links:

GitHub: GitHub - OpenIPC/smolrtsp: A lightweight real-time streaming library for IP cameras

Technical Documentation: [SmolRTSP: SmolRTSP)

For more real-world IoT streaming projects: See ZedIoT IoT Device Development Services