Following one sensor sounds simple; the thermostat quietly refused for a day

Cooling for the server room is driven by a smart thermostat, and the whole point of the setup is that it should decide from a remote sensor placed by the racks rather than from its own built-in sensor somewhere else. The setting for that exists. It was applied through the home-automation integration. It reported success. The thermostat ignored it for most of a day.

The detection problem is what makes this worth writing down. In the automation layer, “following the remote sensor” and “following its own sensor” present as the same underlying characteristic, so there is nothing to read back that distinguishes them. The change was accepted, appeared to apply, and was never persisted by the device, with no error surfaced anywhere in the chain. Two more benign explanations were investigated and ruled out first, a temperature hold retaining an older sensor selection and the active comfort period not reloading a changed setting, both of which cost real time. The actual fix was a physical power cycle of the thermostat, and the only place the truth was ever visible was the device’s own screen.

A second trap surfaced the same day and is the longer-term risk. The firmware has a built-in behaviour that overrides the remote sensor with no visible sign, whenever the remote and built-in readings differ by more than a threshold. On a hot day, a rack warming until it matches the other reading looks, from the automation side, exactly like the remote sensor catching up, not like a safety override engaging.

The general warning is this. If you build automation on a device that has its own undocumented internal safety logic, assume that logic can activate invisibly. Build a way to positively confirm which mode the device is actually in, rather than trusting what was last commanded.