Aircon IR Blaster: What It Imitates and What It Misses

An IR blaster copies your handset. It sits in the room, joins your home network, and puts out the pulses your handset would have sent whenever the app asks. The aircon treats them exactly as it would a hand across the room, and nothing on the machine changes.

Getting that pulse right is fiddlier than a product page suggests. The receiver behind the indoor unit's display panel is tuned to one carrier frequency. Receiver modules come in versions centred on 30, 33, 36, 38, 40 and 56 kHz, and a signal on the wrong one goes unheard. The pattern on top of the carrier belongs to the manufacturer, changing by brand and often by series.

Aircon commands are shaped differently from television commands. A television handset sends one instruction per press. An aircon handset almost always sends every setting it holds in a single message: power, mode, setpoint, fan speed, swing and timer. The indoor board does not build a picture from a run of presses; it receives the whole picture and adopts it.

That single design choice explains almost everything below. Setup becomes a matching job. A bad match fails oddly instead of failing cleanly. And app drift heals itself on some units, never on others.

The command path runs one way. The blaster transmits, the indoor unit receives, and nothing travels back. So the app never reports the aircon; it replays the last instruction it sent, and the difference stays invisible until the two disagree.

A wifi module on the indoor board changes that arrangement. There the command arrives over the network, the board answers back, and the app displays something the machine actually confirmed. An infrared blaster sits on the blind side of that difference, and no amount of software on the phone can cross it.

The aircon does acknowledge a command, just to the wrong audience. Daikin's wall-mounted manual sets out three beeps: two short ones when operation starts, one short beep when a setting changes, and a long beep when operation stops. That is a genuine confirmation carrying real information about what the unit did. It goes into the room as sound, and the box on the shelf has no ear for it.

Four ordinary events push the app's picture away from the machine. Three of them leave no mark on the phone at all.

Two kinds of aircon handset exist, and they recover from drift very differently. Most wall-mounted splits in Singapore flats carry the forgiving kind, which is worth confirming before anything is bought.

Display handsets hold the full state and transmit all of it, so one instruction from the app overwrites whatever the machine was doing. The screen can be wrong for hours, and a single press puts machine and app back in agreement. That self-correction falls out of how the protocol was built; nobody designed it as a feature.

A handset with no display works by stepping instead. Each press moves one setting to its next value, so a command means up one, never set to this. Window and portable units are commonly built this way. Once the app has lost count, it cannot know how many steps to send, and no run of commands lands reliably.

Controller makers state this openly, which is unusual enough to notice. At least one restricts support to aircon with a full-state display handset. It says sync can be lost when the original handset is used, leaving the controller unable to work out how many steps to send. The published fix for the stepping kind is manual: set the machine by hand to match the app, then leave the buttons alone.

The blaster has to see the indoor unit's receiver window. Infrared is light and obeys light's rules. Daikin's manual tells owners to aim the transmitter at the indoor unit, warning that anything blocking the path, such as a curtain, stops the unit responding. It gives a working range of roughly seven metres for the handset.

Angle matters as much as distance. A receiver's sensitivity falls away to the side, and for common modules the angle at which usable range halves is around forty-five degrees off centre. A blaster on a side shelf, firing across the room at a slant, works with a fraction of the reach it would have head-on. That arrangement usually passes the install-day test, then drops commands once furniture moves.

Light in the room competes with the signal. Receiver modules reject steady light from bulbs and daylight, along with the flicker from fluorescent fittings with electronic ballasts, and rejection is never free: every bit costs sensitivity. Daikin warns that communication may be disabled outright when an electronic-starter fluorescent lamp is in the room. A blaster parked in afternoon sun fights the same fight.

Dust on that window does the same thing quietly. Manuals note that dust on either the transmitter or the receiver reduces sensitivity, and mounted near the ceiling, the window collects the same film as everything around it. A setup that has slowly turned unreliable is sometimes a cleaning job at the aircon end.

• •Can the box see the receiver window with the door in every position it normally sits in?
• •Is it roughly square on to the indoor unit, or slanted across the room from a corner?
• •What gets put down on that surface. A bag, folded laundry, a standing fan
• •Does direct sun or a fluorescent fitting cross the path for part of the day?
• •Is that small window on the aircon itself clean?

This is a cheap retrofit and frequently a sensible one. It reaches a working aircon that was never built for a network and leaves the machine alone: nothing gets opened, wired into, or fitted to the indoor board. For a healthy unit with years left, that is a fair trade.

Remote switch-on is the feature people buy, and the one to hold most lightly. The app can send the command but cannot confirm the aircon acted, because nothing comes back. If the path was blocked at that moment, the phone shows a cooling room and you walk into a warm one. Treat it as a request that usually lands.

Adding a temperature sensor changes what the system knows, not what it knows about the machine. Some controllers carry a thermometer and humidity sensor and act on a threshold you set. Published behaviour is straightforward: the controller samples the room roughly every ninety seconds and sends a command when the reading crosses your line.

That closes a loop, and the loop goes around the room. A room reading tells you whether the space is cooling, not why. If the temperature climbs, the controller keeps firing commands at a machine that might be shut down on a fault, might be missing every pulse, or might be running perfectly and losing to the heat.

One dependency deserves a mention and no more. The box belongs to a company, reaches your aircon through that company's app, and carries whatever lifespan the company decides to give it.

Everything else follows from what the thing is. A blaster is a long-range finger on the handset, with a perfect memory of what it pressed and no way to check what happened next. Bought on that description it earns its money. Bought as a readout of the machine, it will mislead you on the day that matters.