Turn Almost Any IR Air Conditioner into a HomeKit Thermostat with Tuya and Homebridge

A small Wi-Fi IR controller can make an old air conditioner appear in Apple Home as a proper thermostat-style accessory—with power, cooling and heating modes, temperature, and fan speed. The AC itself does not need Wi-Fi.

I have a perfectly good air conditioner that predates HomeKit. It uses an ordinary infrared remote, and replacing the AC merely to add app control would be wasteful. I wanted something better than a collection of on/off scenes: one native-looking tile in Apple Home that behaved like a HeaterCooler service.

The working chain is a Tuya-compatible Smart AC Controller, a Tuya IoT cloud project, Homebridge, and the @homebridge-plugins/homebridge-tuya plugin. Homebridge translates the virtual AC created by Tuya into HomeKit's thermostat-style model, while the Tuya controller transmits the infrared command that the AC already understands.

This works surprisingly well, but the word thermostat needs a qualification. The controller can send structured AC commands, and some models include a room-temperature sensor, but infrared is normally one-way. If somebody uses the original remote, HomeKit may not know that the physical AC changed state.

The short answer: will it work with any AC?

It can work with almost any IR-controlled AC whose remote profile is available in Tuya's IR database. The combination is especially useful for older split, window, and portable AC units that have no network connection of their own.

For the best HomeKit experience, the Tuya profile must expose structured AC controls such as:

Power
Cooling, heating, and auto modes
Target temperature
Fan speed
Optionally, dry and fan-only modes

A generic learned remote made from individual buttons is different. Homebridge can expose those buttons as switches, but it cannot infer a thermostat model from unrelated learned codes. The virtual remote should appear in Tuya as an air conditioner, not merely as a DIY remote.

How the pieces fit together

The control path crosses two different worlds:

Layer	Responsibility
Apple Home	Presents the AC as a `HeaterCooler` with mode, temperature, and fan speed
Homebridge	Translates HomeKit characteristics into Tuya IR AC commands
Tuya cloud	Resolves the virtual AC profile and delivers the structured command
Wi-Fi IR controller	Converts the command into an infrared signal
Existing AC	Receives the same kind of IR message as it would from its original remote

Apple Home communicates locally with Homebridge. The Tuya plugin used here communicates with the Tuya cloud; it does not use Tuya's LAN protocol. The IR controller and Homebridge therefore need working internet access even though HomeKit discovery and pairing happen on the local network.

What I used

An AC controlled by an infrared remote
A Tuya-compatible Wi-Fi Smart AC Controller / IR blaster
The Tuya Smart app or Smart Life app
A free Tuya IoT developer project
Homebridge 2 running in Docker
@homebridge-plugins/homebridge-tuya
An Apple home hub for remote access and automations, if required

My Homebridge instance runs as a Docker container on a homelab VM. The same design works on a Raspberry Pi, a mini PC, a NAS, or another supported Homebridge host.

Step 1: create the AC remote in Tuya

Add the physical IR controller to Tuya Smart or Smart Life. In the controller's device page, add an appliance, select Air Conditioner, choose the manufacturer, and complete Tuya's remote-matching process.

Before involving Homebridge, confirm in the Tuya app that the chosen profile represents the functions the AC actually supports. A mismatched profile may turn the unit on but send the wrong temperature, mode, or fan code.

Tuya will now appear to contain the same hardware twice:

The physical IR hub, commonly reported with a category such as wnykq.
A virtual AC remote, which is a child of that hub.

This is intentional. The physical device supplies Wi-Fi and the IR transmitter. The virtual child stores the appliance type, remote index, supported modes, temperature range, and key definitions. Homebridge needs the virtual child for the thermostat UI and its parent hub for command delivery.

Do not delete the hub just because the AC child is the accessory you want to see in Apple Home.

Step 2: create and authorize a Tuya IoT project

Sign in to the Tuya IoT Development Platform and create a cloud project. For a normal personal Tuya Smart or Smart Life account, select the Smart Home development method and choose the data center matching the app account's region.

Under Service API, authorize at least:

Authorization Token Management
Device Status Notification
IoT Core
IR Control Hub Open Service

Then open Devices → Link Tuya App Account, add an app account, and scan the QR code with Tuya Smart or Smart Life. Both the IR hub and its virtual AC remote should become visible to the project.

Tuya's free IoT Core authorization expires periodically. At the time of writing, it must be extended every six months. A Homebridge integration that suddenly stops working after months of stability may simply have an expired Tuya cloud subscription.

When the device schema is incomplete

Some products expose non-standard data points. In the Tuya project, open Devices → All Devices → View Devices by Product, edit the control instruction mode, and select DP Instruction. This makes the raw device data points available for custom schema mapping.

Do not invent a schema before reading the saved device information or Homebridge logs. Data-point names, enum values, temperature scaling, and writable modes vary between products.

Step 3: install and configure the Homebridge plugin

Install Homebridge Tuya by @homebridge-plugins/homebridge-tuya from the Homebridge plugin page.

A Smart Home project uses a configuration shaped like this:

{
  "platform": "TuyaPlatform",
  "name": "Tuya",
  "options": {
    "projectType": 2,
    "accessId": "TUYA_ACCESS_ID",
    "accessKey": "TUYA_ACCESS_SECRET",
    "countryCode": "YOUR_COUNTRY_CODE",
    "username": "TUYA_APP_USERNAME",
    "password": "TUYA_APP_PASSWORD",
    "appSchema": "tuyaSmart"
  }
}

Use smartlife for appSchema when the devices are paired through the Smart Life app. Keep the Access Secret and app password private. Never paste an unredacted Homebridge configuration into an issue, forum post, or public repository.

After restarting Homebridge, the plugin fetches the physical IR hub and the virtual remotes linked to it. A virtual remote with Tuya IR category ID 5 is handled as an IR air conditioner and can be represented by HomeKit's HeaterCooler service.

Why the AC may initially appear as a switch

The plugin can only create the right HomeKit service when it can identify both the device type and the required control data. A generic switch usually means one of these is true:

Homebridge found the physical hub but not the virtual AC child.
The Tuya project does not have IR Control Hub Open Service authorization.
The app account was linked to the wrong Tuya data center.
The remote was created as a generic DIY remote rather than an AC profile.
The product uses non-standard data points and needs DP Instruction mode or a schema override.
A stale cached accessory was created before the device was recognized correctly.

The important distinction is that changing the icon of a switch does not make it a thermostat. The accessory must be handled as an IR AC and expose HomeKit characteristics for active state, target mode, current temperature, target temperature, and rotation speed.

Device overrides: rename, remap, and hide

The plugin's options.deviceOverrides array can convert non-standard Tuya schemas into the standard codes expected by its accessory handlers. It can also hide devices that should not be published to HomeKit.

For example, unrelated Tuya devices can be hidden by ID while retaining only the AC integration:

{
  "options": {
    "deviceOverrides": [
      {
        "id": "UNWANTED_DEVICE_ID",
        "category": "hidden"
      }
    ]
  }
}

Schema overrides can rename a non-standard data point with newCode, correct its type, define enum ranges, or transform values with onGet and onSet. These mappings must come from the actual device schema. Copying another product's mapping blindly can create controls that look correct but transmit invalid commands.

When troubleshooting, change one device at a time and retain a backup of config.json. On a live Homebridge installation, restart and inspect the logs before operating any accessory.

One thermostat tile instead of separate AC, fan, and dry tiles

The stock IR AC handler can create three HomeKit services when the Tuya remote says those modes are available:

HeaterCooler for auto, heat, and cool
Fanv2 for fan-only mode
HumidifierDehumidifier for dry mode

That behavior is technically correct because Apple's standard HeaterCooler target-state characteristic only defines Auto, Heat, and Cool. It has no standard target values for fan-only or dry mode.

I preferred one clean AC tile. My installation therefore keeps the HeaterCooler service, omits the separate fan and dehumidifier services, and attaches fan speed to the heater/cooler's RotationSpeed characteristic.

Tuya's IR profile reports fan speed as small integer steps, while HomeKit expects a percentage. The useful normalization is:

Tuya wind value	Meaning	HomeKit presentation
`0`	Auto	Automatic/default behavior
`1`	Low	About 33%
`2`	Medium	About 67%
`3`	High	100%

This is a small source-level customization rather than a standard deviceOverrides option. A plugin update can overwrite it, so I keep a dated backup and revalidate the change after every update. A future plugin option that suppresses the extra services would be preferable to maintaining a patch.

If dry and fan-only modes are important, keeping the stock separate services is the more standards-compliant choice.

What the HomeKit thermostat can control

With a compatible structured IR profile, the single tile can provide:

On and off
Auto, cooling, and heating modes supported by the remote profile
Target temperature within the profile's allowed range
Fan speed through the HomeKit rotation-speed slider
Current room temperature when the IR hub exposes a temperature sensor
Siri commands and Apple Home automations

For example, an automation can turn on cooling when a room sensor exceeds a threshold, or Siri can set the bedroom AC to a specific temperature.

Remember that an IR controller sends a complete command state. Homebridge combines the desired power, mode, temperature, and wind values, then asks Tuya to transmit the matching IR code. This is more reliable than replaying unrelated button presses because each command describes the intended AC state.

The important limitation: IR state is optimistic

Most consumer AC remotes do not receive status from the indoor unit. The HomeKit state is therefore based on the last command sent through Homebridge, not a confirmed response from the AC.

This creates several practical consequences:

Using the original remote can make HomeKit's displayed state stale.
An obstructed IR signal may fail even though HomeKit reports success.
A power cut can reset the AC without updating Homebridge.
The hub's room-temperature sensor is not necessarily the AC's internal sensor.
Target temperature is the last commanded setpoint, not a value read back from the unit.

Place the IR controller where it has a reliable line of sight to the AC. For safety-critical or energy-critical automation, use an independent temperature or power sensor as confirmation instead of trusting optimistic IR state alone.

Docker, VLANs, and Apple Home stuck on “Connecting”

Tuya cloud access and HomeKit pairing are separate network paths. The Tuya integration can be healthy while Apple Home remains stuck on Connecting because the iPhone cannot reach the Homebridge HAP service advertised over mDNS.

In a Docker and VLAN environment, verify the following:

Homebridge advertises the VM or host's real LAN address, not a Docker bridge address.
The Homebridge bridge.bind option selects the correct physical interface, such as ens19.
The iPhone VLAN can route to the Homebridge VLAN.
mDNS is reflected between the required VLANs, or both devices share the same multicast domain.
The firewall permits the main bridge and child-bridge HAP ports.
An old interface or previous VLAN address is no longer being advertised.

A representative bridge section is:

{
  "bridge": {
    "name": "Homebridge",
    "username": "REDACTED",
    "port": 51826,
    "pin": "REDACTED",
    "bind": "ens19"
  }
}

Use the interface name that actually owns the LAN address reachable from the iPhone. Do not copy ens19 without checking the container or VM.

When a plugin runs as a Homebridge child bridge, it has its own HAP identity and listening port. Pairing will fail if mDNS advertises that child bridge on one address while the firewall or container publishes it on another.

Is a fully local Tuya version possible?

There are LAN-first Homebridge plugins such as homebridge-tuya-plus, and they are attractive for Tuya devices that expose ordinary local data points. Direct Wi-Fi air conditioners can often use that model.

The virtual AC behind a Tuya IR hub is different. Its structured remote metadata and IR command delivery normally rely on Tuya's IR Control Hub Open Service. The physical hub may answer on the LAN, but that does not automatically make Tuya's cloud IR library and virtual child protocol locally available.

For this specific architecture, I treat the integration as cloud-controlled with a local HomeKit bridge, not as a fully local AC controller. If cloud independence is a hard requirement, choose IR hardware with a documented local API or firmware designed for local home-automation platforms.

Maintenance checklist

Keep a redacted backup of the Homebridge configuration.
Record which device ID is the physical hub and which is the virtual AC child.
Extend the Tuya IoT Core authorization before it expires.
Recheck custom source patches after plugin upgrades.
Reserve the IR controller's DHCP address for easier network diagnosis.
Keep the Homebridge UI private; expose HomeKit remotely through an Apple home hub, not by forwarding the UI.
After changing VLANs or Docker networking, verify the address advertised by every child bridge.
Do not remove the physical hub from the Tuya project when hiding its HomeKit accessory.

Was it worth doing?

Yes. A small IR controller gave an older AC the parts of a modern smart thermostat that matter day to day: a proper Apple Home tile, temperature selection, operating mode, fan speed, Siri, scenes, and automations.

The result is not magic and it is not fully local. Tuya provides the remote intelligence, Homebridge supplies the HomeKit model, and the AC still receives one-way infrared commands. Once those boundaries are understood, it is a practical way to modernize a reliable appliance without replacing it.

The most important lesson is to model the virtual AC child, not the physical IR hub. That is the difference between a mysterious switch in Apple Home and a useful thermostat-style controller.