The home office has a 49-inch monitor. It hangs off a Mac mini over DisplayPort and nothing else, and when it is on it does two things: it shows a picture, and it heats the room. In September the second of these stopped being a feature. We wanted it asleep whenever nobody was in the office, which sounds like the kind of request a house full of automations should be able to grant before lunch.
It took a day and a metering plug, which for this house is about average.
Do not talk to the monitor
The obvious move is to talk to the monitor. DDC/CI over DisplayPort can indeed tell a screen to switch off. What it is much worse at is telling it to switch back on, because a sleeping monitor tends to put its own DDC circuit to sleep along with everything else, and a device that cannot hear you is difficult to persuade. So we talk to the Mac instead.
Over SSH, with a key kept for this one purpose, pmset displaysleepnow stops the picture; the monitor notices the silence and drops into its own power-saving standby, DPMS, which is the monitor's side of the handshake. caffeinate -u -t 1 pretends to be a user for one second, the picture returns, and the monitor wakes because it was never really asked to do anything. It works with any monitor, needs no DDC and no USB, and its one fragility is that Remote Login has to stay switched on in the Mac's sharing settings, which we have written down twice, in capitals.
What it was costing
We borrowed a metering plug for an afternoon rather than guess. Awake, the monitor draws 84.3 W. In standby, 1.2 W, at a power factor of 0.07, which is the electrical equivalent of a shrug, for the reasons on derived signals. The difference is 83.1 W, about 1.7 cents an hour at our 0.20 EUR/kWh, and roughly the heat output of a seated person. So an office with one of us and a lit monitor is, thermally, an office with two of us. That was the whole complaint.
Our earlier estimate of "under half a watt" for standby was optimistic by a factor of two and a bit. We keep saying we will stop estimating things we can measure. The plug is on loan to the office, not a fixture, and nothing permanent is built on it.
Who decides the room is empty
The office has an mmWave radar with three detection tiers: large motion to 3 m, small motion to 3 m, and static presence, meaning breathing, to 2 m. It is mounted directly above the monitor, so a person at the desk sits well inside the 2 m static band. Four days of history contained zero cases of "no presence while the Mac was active", which is the number we wanted before letting it switch off anything in anyone's face. Wake is on the edge of presence, the radar going from off to on, so the screen is lit as you walk in, before you reach the keyboard. The reasoning is on level versus edge.
Sleep is more cautious. The radar has its own fading time of 300 s before it will admit a room is empty; the automation then waits a further two minutes on top. We started with five, which added up to about ten minutes of a lit screen in an empty room; two brings the total to about seven. And even then the Mac must report itself idle, the camera must not be in use and the audio output must not be in use, because a radar will eventually lose a person who has stopped moving altogether, as the living room has already demonstrated, and losing you mid-call would be the wrong way to save 1.7 cents.
The idle guard could in principle block sleep forever, so we checked: the Mac's activity sensor was off for 88.9 of 96 hours. It does not stand in the way.
Knowing whether it worked
Switching the monitor off turned out to be the easy half. Knowing that it was off was harder. The Mac is Apple Silicon, and the display-power object every forum answer says to query, IODisplayWrangler, does not exist there; asking pmset for its power state returns "Internal failure", which is at least honest. The companion app on the Mac offers a "Screen Off" attribute, and we watched it stay False through a real sleep from start to finish. It was measuring something, presumably; not this.
The only source that told the truth was pmset -g log, which records "Display is turned off" and "Display is turned on" with timestamps, a few seconds after the fact. So a sensor built on a shell command reads the last such line over SSH every 60 s and becomes Display - pisarna. When SSH fails, the sensor goes unavailable rather than a confident, fictional "off", in the spirit of failing visibly. The first night's review caught the obvious gap: a failed SSH returns no text at all, and a template asked to read the last line of nothing falls over. The sensor now checks that it has a string before reading one.
We could have had the sensor mirror our own commands, "we sent sleep, therefore it sleeps", and it would have looked perfect on the dashboard forever. See verified wrong for how that ends.
The test that kept failing
The first three tests were discouraging. The log showed the display turned off and turned on again within the same second, every time, which looked very much like a monitor bouncing back awake and a plan that had not survived contact with hardware.
The same log keeps a list of "assertions", the reasons macOS thinks it should stay awake, and in each case there was one: a HID event, which is to say keyboard-or-mouse input, from the wireless USB receiver. Which is to say, one of us was sitting at the desk running the test and, being a person, moved the mouse. The Mac did exactly what it should do when someone moves the mouse. With hands kept off everything, the screen went dark and stayed dark for 28 s with no "turned on" in sight, and the wake command lit it at 17:07:55, confirmed by the only sensor we fully trust, someone looking at it.
The office tab now has a bar chart of hours per day the screen was on. The history database keeps a week and the sensor is a day old, so for now the chart is mostly a promise. It will fill in.