Tuya HVAC product case

Tuya OEM-to-SDK Migration for Commercial HVAC

A North American commercial HVAC provider had reliable connected devices, but its Tuya OEM application could no longer support the coordination, permissions, and operating strategies required at scale.

See the engineering approach
Commercial HVAC equipment managed through a Tuya SDK application
Tuya SDK · Ray Framework · HVAC strategy
Project context

The devices worked, but the application layer constrained the product

Independent equipment behavior created energy conflicts, while fixed OEM templates made it difficult to coordinate building-level strategies or evolve the product without workarounds.

Starting point
Working Tuya OEM product
Upgrade
SDK app + MiniApps
Published outcome
25% operating-cost reduction
01What had to work

The field data needed business and operating context

  1. 01

    Preserve installed Tuya hardware and device connectivity

  2. 02

    Gain control of application structure, users, groups, and permissions

  3. 03

    Update operating strategies without waiting for full app releases

  4. 04

    Show system state and energy behavior at a building level

02Engineering approach

Upgrade the application layer without rebuilding the device estate

ZedIoT moved the product to a custom Tuya SDK application, used the Ray Framework for native product experiences, and decoupled frequently changing strategies into MiniApps.

SDK application

Custom navigation, roles, groups, device models, and business logic replace OEM-template constraints.

MiniApp strategy

Frequently changing HVAC logic can evolve independently of the main application release.

System coordination

Equipment actions are evaluated against building state and energy objectives.

Operations view

Dashboards focus on system conditions, conflicts, trends, and action history.

Comparison of legacy Tuya OEM HVAC control and the coordinated SDK application solution
Project evidence from the delivered system.
03Project evidence

An operating view connected to the system architecture

The source case compares isolated OEM control with the coordinated SDK and MiniApp operating model.

04System workflow

A controlled application architecture above the existing Tuya devices

01

Tuya devices

Installed hardware continues to use the proven Tuya device and cloud layer.

02

SDK app

The application owns product structure, identity, permissions, and experience.

03

MiniApps

Independent strategy modules can be updated for different operating conditions.

04

HVAC decisions

Coordinated actions reduce conflicts and produce reviewable operating evidence.

05Project outcome

A commercial product that could evolve beyond the OEM stage

The published case reports that the upgraded control strategy resolved energy conflicts and reduced operating costs by 25% while preserving the installed device layer.

Controllable product layer

The customer could shape workflows and permissions around its own commercial HVAC offering.

Faster strategy updates

MiniApps separated high-change operating logic from the main application release cycle.

Scalable operations

Building-level state and coordinated actions replaced isolated device control.

Engineering boundary

Savings depend on building type, equipment, climate, control policy, occupancy, baseline, and commissioning; each deployment requires its own acceptance evidence.

FAQ

Tuya HVAC OEM-to-SDK migration questions

What did ZedIoT deliver for this tuya hvac oem-to-sdk migration project?

ZedIoT moved the product to a custom Tuya SDK application, used the Ray Framework for native product experiences, and decoupled frequently changing strategies into MiniApps. The final scope depended on the customer's devices, interfaces, operating workflow, and acceptance criteria.

Can this project pattern be adapted to another product or site?

Yes. The reusable pattern is the way tuya devices, sdk app, miniapps are connected. Device protocols, deployment topology, data ownership, and operating rules are validated for each new project.

What should be confirmed before starting a pilot?

A useful pilot starts with representative hardware, interface documentation, real operating conditions, expected users, failure cases, and measurable acceptance criteria. Savings depend on building type, equipment, climate, control policy, occupancy, baseline, and commissioning; each deployment requires its own acceptance evidence.

Talk to ZedIoT

Planning a related AI + IoT project?

Share the current device or system, the operating problem, available interfaces, intended users, and the result you need to validate. ZedIoT can help define a focused prototype and production path.

  • AI + IoT product architecture review
  • Hardware, firmware, cloud, and application integration
  • Prototype planning and production support