Air-conditioner automation sounds simple: if the room exceeds 26°C, cool harder.
A controller that reacts to each individual sample, however, can end up chasing sensor noise and repeatedly sending infrared commands.
Scope: The 25–26°C band and 18°C software floor are experimental settings for one room, not universal health, comfort, or manufacturer recommendations. Occupant condition, humidity, WBGT, sensor faults, and the model manual take precedence.
The defined control policy treats 25–26°C as a band and adjusts the setpoint one degree at a time according to the temperature trend.
Implementation and physical operation of that automatic policy remain unverified; it is not a fully verified end-to-end installation.
In the July 21, 2026 live check, the software's known air-conditioner state was equivalent to cooling at 24°C.
Automatic sensor linkage, physical infrared reception, and the resulting room-temperature change were not verified end to end.
Closed control loop connecting temperature sensing, trend analysis, one-degree control, infrared transmission, and verification
*Diagram: sense, evaluate the trend, make one bounded adjustment, transmit, and verify before repeating.*
Known state is not room truth
On July 21, 2026, the API reported the software-known state cool_24, equivalent to cooling at 24°C.
The API records this known state after the latest successful complete-state transmission.
It still does not prove that the unit received the signal, began cooling, or brought the room to 24°C.
Infrared remotes usually provide no network-style acknowledgement.
The send operation can succeed even when the signal does not arrive because of an obstruction, poor alignment, excessive distance, or the appliance's temporary state.
At minimum, keep three records separate.
Record
Content
Decision
Which temperature and trend caused the action
Transmission
Which complete state signal was sent and when
Observation
How temperature or another independent sensor changed afterward
The first safety rule is never to equate “transmission succeeded” with “cooling succeeded.”
Treat 25–26°C as a band, not a point
The target range is 25–26°C.
Rather than switching frequently around a narrow 0.2°C threshold, the controller checks whether the room is within, above, or below the band.
The intended policy is:
Within 25–26°C, keep the current setting, including while temperature is already falling.
Above 26°C, lower the cooling setpoint by one degree only when temperature is flat or rising.
Never lower the setpoint below 18°C.
Below 25°C, raise the cooling setpoint by one degree per decision.
Once the setpoint has reached cooling at 26°C, stopping is allowed if the room is still below 25°C; do not stop earlier.
The policy deliberately avoids urgent reactions.
If the room is slightly above 26°C but already cooling, wait.
At the same 26.5°C, a flat or rising trend justifies one stronger step.
Why move one degree at a time
Room temperature does not react immediately after a setpoint change.
Room size, sunlight, people, electronics, and air mixing create delay.
Changing several degrees at once can stack new actions before the effect of the first action is visible.
One-degree steps make it easier to connect a decision with the later trend.
One-degree steps are not sufficient by themselves.
The controller needs a cooldown after each command and a lock against repeating the same decision rapidly.
If a sensor reading is missing, stale, or implausibly discontinuous, the safe response is to preserve the previous setting and alert.
Send a complete state signal
An air-conditioner infrared command is safer when treated as a complete state—mode, temperature, fan settings—rather than a blind power toggle.
Sending “cooling at 24°C” avoids guessing the previous state and simulating a series of temperature-button presses.
A complete state signal still does not prove physical reception.
After transmission, use at least one independent observation—such as the room-temperature trend, power use, or outlet-air temperature—and choose only observations that can be obtained safely without modifying the appliance.
Attach notifications to decisions and results
A useful notification includes the reason and verification state, not only the requested setpoint.
Examples include:
Temperature is within the band and falling, so cooling at 24°C is unchanged.
Temperature is above 26°C and rising, so a signal one degree lower was sent.
The signal was sent, but physical reception has not been verified.
The sensor value is invalid, so no action was taken.
Send alerts through a place that will actually be noticed in the home, and group repeated notifications for the same unchanged decision.
The purpose of automation is not to create more alerts; it is to reserve attention for exceptions that need human intervention.
Current status and the next test
We verified that the API recorded cool_24 as the latest successful complete-state transmission.
The automatic decision-to-send path, physical reception, and appliance operation remain unverified.
What remains incomplete is one trace that links room sensing, decision, infrared transmission, physical reception, temperature response, and notification.
That test needs separate cases for inside the band, above 26°C while falling, above 26°C while rising, below 25°C, and missing sensor data.
The intelligence of air-conditioner automation is not measured by how often it acts.
It is measured by whether it waits when waiting is correct, moves only one degree when action is needed, and observes the result before claiming completion.
An infrared command history does not prove physical appliance state. The model manual, WBGT, humidity, and occupant condition take priority over this room-specific experiment.
